So I had been using Wayland (sway) for two years or so, and I finally decided to ditch it and switch back to X11 (i3). This blog post serves as an explanation for the decision and a reminder for the future me trying out Wayland the second third time.
Please note that the following complaints are from a frustrated user who really doesn’t bother to look under the carpet.
So I’ve long been puzzled by this behavior of my Emacs config: sometimes when I open a file in the terminal with Emacs, it adds a pair of square brackets around the current line/word/expression. After some digging, I’ve come to the conclusion that, I absolutely don’t want to work with ANSI escape codes.
Mandelbort benchmark: Emacs (native-comp) runs 10x slower than Java or Truffle implementation 1
So I’ve been working on an interpreter for Emacs Lisp using the GraalVM Truffle framework for a while now. As I’ve just completed its AST interpreter and a bytecode interpreter, I guess its time to give it a little write-up (or rather, some random babbling of various tricks).
Although the Truffle interpreter covered here is for Emacs Lisp only, most of the following should also be applicable to other Lisp dialects and maybe other Truffle-based language implementations.
There have been quite a few attempts to re-implement (part of) Emacs’ functionalities in languages other than C, like JEmacs, remacs, and lem. And we are seeing new efforts in EmacsConf 2024: rune 1, schemacs 2, and the revived Guilemacs 3. (Strictly speaking, Guilemacs is more a fork than a total rewrite, but anyway.)
However, a complete rewrite of (GNU) Emacs 4 has always seemed like an insurmountable task, not just because writing editors is hard. This article aims to look into some of these difficulties and the Emacs designs (that of course have been exposed in some Emacs Lisp API) that lead to them.