While working on my previous post I was mainly using Emacs, because it has the best support for Lisp languages. It has great integration with the REPL, can run server for my application in background and so on. And actually, I use this a lot while working on this blog - I run hugo process in background to see how my page is looking.
Ray casting is quite old technique, that was heavily used in the early days of game development in a lot of games to create illusion of 3D space. Most known example, and perhaps first widely successful game that used this technique, was Wolfenstein 3D, made by ID Software in 1992.
This is yet another follow up post in Emacs configuration series, that is also about Tabs. Previous post was about how tabs behave when you close them, and how I think the algorithm can be improved. This post is more about visuals and horizontal space management.
Another little piece from my Emacs config that I’ve decided to turn into a small post, following up on previous one. This time, we’re going to make tabs work as in most graphical editors. Tabs were added with global-tab-line-mode in Emacs 27, and are pretty simple tabs, that are being displayed on the top of a window, and by default their semantics are not very useful in my opinion.
Thought that I can share snippets of my Emacs config from time to time here, just like @clemera does on with-emacs.com. I highly recommend you to check it out, there are many great recipes and articles. A while ago I’ve added static Treemacs title to Treemacs buffer for aesthetic purposes - it adds good alignment with tabs in other window.
As software engineers, programmers, we mostly work with text, so obviously we’re all using some sort of a text related program. Editing and navigating text is huge part of our daily job, so good text editor is like a good set of tools for blacksmith.
Today I’ve decided that I want to write a little rant on the topic of language design. Since I’m a C programmer, and I use it on a daily basis, I’ve had many thoughts about C syntax over past few years. I like C, and it is a good language, that defined modern operating systems and software.
At the end of the Part 2 I’ve mentioned that quasiquoting was problematic in GRScheme, due to some of the internal representations and algorithms, but now it is not an issue (I hope). I’ve figured out correct way to maintain list invariant, splice one tree into another tree, and so on.
Good things happened since my previous post! I’ve finished rewriting of interpreter from recursive to iterative, which means that there will be no stack overflows when traversing deep trees. I’ve also simplified name binding and lookup systems, added support for arbitrary-sized integers, fractions, and 64-bit floating point numbers, but most importantly figured out tail call elimination and closures.
At the end of my previous post I’ve mentioned that I will write more about GRScheme - language that I’m working on. As of this moment I’m rewriting it to be more robust and to fix some design flaws that make it impossible to do such things as tail call elimination.