After watching this year’s EmacsConf and seeing Guile Emacs being resurrected I thought to myself - why limit ourselves to Guile? Sure, Guile isn’t just a Scheme implementation, thanks to its compiler-tower-based design. Other languages exist for Guile VM, such as Emacs Lisp, and Guile manual lists the following languages with various stages of completeness:
Categories / emacs
There was a weird thought going over and over in my head, regarding my Emacs configuration, and it extends to the other projects I do both at home and at work. You see, my configuration is riddled with custom code, and up until recently I had mixed feelings about that.
Tree-sitter became more widespread and Emacs took notice and included a bunch of <lang>-ts-mode as alternatives to <lang>-mode into the core. This is good news and a welcome change, but I have some concerns about the approach.
When I first saw the Tree-sitter talk by Max Brunsfeld I was concerned that the language highlighting “fix” they’re talking about is too much.
…if you’re an Emacs user, that is.
You know, it’s funny, because people have opinions on why you don’t need a terminal on entirely different ends of a spectrum. It’s like that IQ chart meme:
Figure 1: *That’s Visual Studio on the left, not VS Code
In the previous post on the subject I’ve described how one can create a custom compilation mode for any language. In the Dynamically extracting filenames from compiler output section I’m talking about various issues with how Clojure reports problem locations. The main problem is when the problem is inside of a dependency, and be it your own library, or a third-party one it’s equally tedious to go and look into it because the dependency usually is a jar file somewhere in the ~/.
Recently I’ve stumbled upon a video about Kakoune, a code editor: Idiot user tries to use Kakoune (for notes? Also Helix?). Funnily enough, I was mentioned in this video, which was a surprise, and made me laugh for quite a while:
Let’s go back to the official plugins page.
Recently, I decided to try the now inbuilt LSP client called Eglot. I’ve been using the lsp-mode package for some years and while I don’t have any problems with it, I decided to try the in-house solution. Though, I already tried Eglot in the past, and it didn’t work for me, due to some complications with the language I’ve tried to use it with.
Lately, my Magit buffer broke once again because of something weird going on with major mode, and I couldn’t stash or commit hunks unless the point was at the beginning of the line. That once again reminded me that Emacs UI is not really a UI, all of it is mere text with a bunch of properties slapped on top.
Lately, I’ve been reflecting on why I’ve settled with Emacs of all other text editors. You may remember my old post where I go into lots of different code editors, and I list Emacs among them too. That post itself was written in Emacs, like everything else in this blog, but I can’t say that I understood the main point of Emacs back then.
In the previous post I’ve described how to define a simple protocol, upgrade the stock Fennel REPL with it, and create a simple client that works with this setup. And at the end, I mentioned that I was working on a proper client implementation and a more robust protocol as part of the fennel-mode package.