SL / EN

The Comfort Trap
EmacsCarnival: Mistakes and Misconceptions

Submission to the Emacs Carnival theme of March 2026: Mistakes and Misconceptions hosted by Philip Kaluđerčić.

I'm first going to sweep before my own door and start with my own mistakes and misconceptions. I've definitely misjudged the learning curve of Emacs, Emacs lisp and the ecosystem and I haven't been thorough enough reading and understanding the documentation. But I've been driven by utility more than with a knowledge of deeper insight into this all-powerful lisp system. Well, I'm working on that (I read the Emacs Lisp An Introduction) and plan to work on it more by reading the Prot's Emacs Lisp Elements. But if I'd have to say anything to my younger self it would be to take more effort in trying to understand Emacs than just take for granted that there's a module for everything and make it work (configure correctly), often through trial and error. My shortcomings are biting me now, that I'm trying to improve/work on my blog functionality.

It's not that I wouldn't be using Emacs if I'd had a better understanding of the learning curve, It's by far my favorite piece of software for ideological reasons - GPL was based on the license that was used to protect Emacs from the corporate appropriation, but I would definitely change my approach towards usage, configuration, and learning the inner workings. I'd take it more seriously.

Along these lines I often doubt my decision to use Spacemacs, a battery included distribution of Emacs. It came quite naturally. My trial and error workflow maintaining my init.el seemed ineffective and while studying physics it also meant that time wasn't spent for studying. So it seemed like a relief when I was just able to find a suitable layer and not bother investigating which set packages would suit my use case best. The friend that introduced me to Spacemacs already moved on. First he moved to Doom Emacs and now he's maintaining his own literate Emacs config in Org Mode (which is also my long term goal). I stayed with Spacemacs mainly due to the lack of time.

Spacemacs is not a black box but still a box I don't look into that often (which, as I'll point in the last part of this blog post) defeats its purpose. While preparing for writing this post I already read through the Spacemacs documentation. I've also quickly compiled a list of my layers (without the accompanying configuration): auto-completion, clojure, csv, dap, denote, emacs-lisp, epub, git, helm, html, json, languagetool, lsp, markdown, mu4e, multiple-cursors, org, php, python, restclient, scheme, shell, spell-checking, syntax-checking, treemacs, w3m, yaml. It's quite a list and I think converting this to my own config would represent a substantial amount of time. And all these layers are maintained by community, which I trust more than myself, and community also outpaces me in the available time.

A reason why I'm softly inclining towards my own configuration is that Spacemacs is not compatible with the Guix Operating System that is highly integrated with Emacs but is installing Emacs packages on the OS level and is not compatible with the Spacemacs way of installing packages.

My inability (mainly due to lack of time) to migrate away from Spacemacs shows how some decision have unforeseen consequences that are hard to revert or divert. Still, I don't feel I'm in a bad spot with Spacemacs. I just have to be more mindful of understanding it, rather than just making it work, which I'd be forced to if I'd be maintaining my own config. And I guess I'm already pass the point where this is needed.

I'd like to finish my blog with expanding on the issue of "not being forced" to learn and understand. Ludovic's toot - criticism of Neoemacs - AI generated Emacs rewrite in Rust - sums it up nicely.

Post by @civodul@toot.aquilenet.fr
View on Mastodon

If you can't read the toot:

I find it ironic given that Emacs was designed with the idea that it would empower people by allowing them to learn programming “without noticing”. https://dspace.mit.edu/bitstream/handle/1721.1/5736/AIM-519A.pdf

8.3. Blue Sky

The programmable editor is an outstanding opportunity to learn to program! A beginner can see the effect of his simple program on the text he is editing; this feedback is fast and in an easily understood form. Educators have found display programming to be very suited for children experimenting with programming, for just this reason (see LOGO).

Programming editor commands has the additional advantage that a program need not be very large to be tangibly useful in editing. A first project can be very simple. One can thus slide very smoothly from using the editor to edit into learning to program with it.

When large numbers of nontechnical workers are using a programmable editor, they will be tempted constantly to begin programming in the course of their day-to-day lives. This should contribute greatly to computer literacy, especially because many of the people thus exposed will be secretaries taught by society that they are incapable of doing mathematics, and unable to imagine for a moment that they can learn to Program. But that won't stop them from learning it if they don't know that it is Programming that they are learning! According to Bernard Greenberg, this is already happening with Multics EMACS.