Comment by yoyohello13
12 hours ago
I’ve also never been able to get over the hump from “configuration” to “extending” (if that makes sense). This was a really interesting read.
12 hours ago
I’ve also never been able to get over the hump from “configuration” to “extending” (if that makes sense). This was a really interesting read.
You already have - configuring is extending in emacs :) there is no magic, like in other editors - the same function calls, hooks, (re)definitions all the way down, to the c-core.
I think the distinction for me is getting from the mindset of "I'll look for a package for this" as opposed to "let me write some elisp for this."
My advice is to use a LLM for that - they are often surprisingly good at producing decent elisp. Maybe not in "publish on ELPA/MELPA" quality, but it can absolutely cover user needs. I know the ecosystem and can read elisp as a coincidence of playing with common lisp - it is enough for glueing things together. The most complicated code I have is around org agenda and export of org tasks - there I needed some LLM help, but I was able to identify and fix performance bottlenecks in some packages and write a config from scratch on my own.
Prot has an intro book on elisp[1] which I want to go through, because some specifics of text processing and buffer usage are a bit unique - it is a lisp for a text editor, after all! But it is still just a lisp, and it even has a lot of common lisp functions in cl-* namespace!
[1] https://protesilaos.com/emacs/emacs-lisp-elements