Two Years of Emacs Solo

I would fault nginx here instead. Tilde-suffixed backups is an old convention used by vim and emacs among others. Definitely older than nginx.

Surprised to hear people told you not to change that - one of the earliest bits of advice I got on using emacs is to set the location of those files to a hidden directory in your home folder.

I raise you my .DS_store

I also set create-lockfiles to nil. I think you can theoretically keep the lockfiles and the clean directory by using lock-file-name-transforms to place the lockfiles somewhere sensible but I didn't bother.

Without this I had to be careful not to acciddentally commit stuff like ".#filename.txt".

(setq backup-directory-alist '(("." . "~/.emacs.d/backups/")))

First thing I do any time I install emacs.

Note that tramp will kvetch if you do this, but it still works fine.

Been using gnu emacs since the 80s and it’s one of the first things I changed. Did you figure it out? If not I can dig up the answer tomorrow.

emacs users who are hostile to you configuring things, aren't really getting the point IMO :)

there's pros and cons

using the same directory drastically reduces the amount of assumptions about your system's permissions and your own installation (or lack thereof)

old school *nix editors typically do something like emacs and vi typically do, whereas old WinDOS/Mac single-user systems would have an installation file and a cache system-wide, and post NT and OS-X they have roughly the same but in a centralised user directory that is not system-wide, but is located as if it were (different evolution path)

This was one of the very first things I added to my config over a decade ago:

    (setq backup-directory-alist '(("." . ".~")))

I won't defend the automatic backup file, because it annoyed me, too.

But it's easy to disable or have them created somewhere else, which is more than you can say for most software lately.

I always disable those auto-backup-files features in any editor I use. Never understood why that was the default-on for so many editors.

Sometimes it's 15 repetitions of one year.

Interesting story, but I'm surprised the OP would disable Cmd-z because that is used all the time with vim

I know you might prefer to run a shell on emacs (or vim) but something only the full terminal can do what you need it to do

> I imagine an LLM would be very good at writing Elisp to leverage EMacs’ strong core functionality

Yes, they are pretty good. I have set up GPTel (an excellent Emacs package for interacting with LLMs) with some tools allowing it to run Elisp, inspect files (Elisp functions know what file they were defined in, so it's easy to find stuff) and read Emacs documentation. LLMs use this to good effect, and iterate on my config very nicely.

Emacs would be a pretty badass "OS" for LLM agents to use... has anyone explored and written something up on that yet? Perhaps emacs commands would give agents even more power than just shell commands ?

It’s interesting how your comment did not talk about anything that’s unique to emacs.

> "w" to select what Vim considers a lowercase-w word

?!? Wtf does this mean and how did vi come up

> Absolutely not. Reading a language is crucial.

I don't think the post implied that this package writing activity was a write-only activity where reading and learning is strictly forbidden.

> You can find open source licensed packages, read them to understand them, and then copy them into your config. Doing everything from scratch is a waste of time unless you enjoy the process (in which case go nuts).

The post clearly indicates the relatively large set of open source packages they looked at and understood before doing their own packages. The author graciously acknowledges them and their influence on the work:

"Emacs Solo doesn't install external packages, it is deeply influenced by them. diff-hl, ace-window, olivetti, doom-modeline, exec-path-from-shell, eldoc-box, rainbow-delimiters, sudo-edit, and many others showed me what was possible and set the bar for what a good Emacs experience looks like. Where specific credit is due, it's noted in the source code itself."

It's nothing like rediscovering everything. Not only is it only Emacs, but it's also been designed by people with a goal of being straightforward to use by people. And whatever you create just needs to be useful to you personally anyway.

I think of it more like building stuff out of Lego without following any instructions.

> The "why" is kinda sketchy

It seems pretty clear that the "why" is "because it's there"

I’m not sure how you missed it, but the “why” was clearly a challenge to better learn and understand Emacs. And because it was fun.

> There's also no reason why you have to literally write everything yourself either.

> It's roughly equivalent to trying to discover all of our scientific knowledge yourself from scratch vs taking "for granted" the knowledge discovered by your forebears.

The author do have another config with all the bells and whistles. But Emacs does come with a lot of packages and tweaking them isn't that much work compared to building a full suite like Helm, especially with the awesome documentation system. Getting a v0.x of anything can be a matter of minutes. And then you wake up one day and you've built a whole OS for your workflows.

You have to sign the FSF's CLA (and clear your contributions with your employer) to contribute to Emacs itself. To ship a separate package to ELPA you need not do this.

> I’m a GUI guy though. As soon as I try delving in, I abort when I see things like “just type c-C dingle bob to do x thing.” I’m happy these people found something that works with their brains. I just want a GUI that works like what they use.

You do have that somewhat with packages like which-key that will show you a menu of options every time you press a key. You then learn the keybinds that you use the most. You can also search for them by name and see the keybind like you do with VS Code etc..

Here's what doom-emacs looks like when I press space and then space-t:

https://files.catbox.moe/szfcif.png

https://files.catbox.moe/2kgrai.png

> I just want a GUI that works like what they use.

I don't think this is really possible. The thing that makes it special is that there are key binds for all the 100s of things you could want to do. So it becomes sort of like playing a instrument where you use your muscle memory instead of thinking specifically about the keys. If you make a bunch of menus and buttons to do the things it would be a mess and probably not very nice to use. Emacs actually has buttons and GUI controls for lots of the functionality, but it kind of sucks to use it that way.

These setups are impressive specifically because the creator has put in the time and effort to become an expert at using their editor. There is just no way to hand that over to someone else as-is without any investment from the recipient in skill development.

A nice way to get quickly familiar with how to use emacs/(neo)vi(m), understand how keybindings work and how to uncover new ones, is to go through reading/practicing the built-in tutorial. It almost plays like games.

When opening a freshly installed emacs, there should be a "Emacs Tutorial" link that can be clicked; also the keyboard shortcut `C-h t` (which is «Control + `h`, then `t`»).

There is a similar feature in `neovim`, when opened type `:Tutor` (which is «`:` to open the command prompt, with command `Tutor`»).

>I abort when I see things like “just type c-C dingle bob to do x thing.”

I used nothing but emacs for several years (well, xemacs, but close enough), because I was using an old Thinkpad, and long-term use of the trackpoint gave me RSI in my finger. Being able to use nothing but the keyboard was nice.

Eventually I went back to BBEdit and have remained there. You can make it mostly keyboard oriented if you want, but sometimes using the mouse is easier/faster, and I have a lot of reps inside of BBEdit. It just seems more like home to me. A nice balance between GUI and keyboard-focussed IMO.

The Zed fork sounds interesting!

What was the Apple Dev account needed for? Previously I remember it was only needed for submitting apps to the App Store, not running Dev builds locally.

> I just want a GUI that works like what they use.

TL;DR: Emacs is a GUI app and has lots of GUI-related functionality, but it tends to be slightly neglected by the majority of users. You can easily build your ideal GUI using the provided building blocks; the problem is, you have to build it, since most other users are not interested in doing so.

Both Emacs and Vim/NeoVIM have GUIs. I can't even run my Emacs in a terminal without `-q` (omit user config) - I never feel the need, and my config would be much more complex if I tried to make it terminal-friendly.

You don't need baroque keybinds, either. Both Emacs and Vim have always had "Command Palette" - Alt+x in Emacs, : in Vim - and with a few plugins[1], you get fuzzy matching, inline docs, icons showing what type of command you're looking at, etc. Both editors also have GUI buttons and mode-specific (on top of generic) menus (including context menus on click). This provides unmatched discoverability of available functions - you can then bind them to any key combination you find easy to remember. You don't have to, though, since with a few other plugins (Orderless), the frequently used commands bubble to the top of the list.

There are two things Emacs handles a bit poorly: mouse and popups. The former stems from existing users largely ignoring the issue, but the hooks for clicks and even gestures are there. The latter is an unfortunate consequence of wanting TUI to remain first class. There is functionality for creating Emacs "frames" (GUI windows) with given dimensions and a specified position, but it's basically GUI-only. Things like auto-completion popups default to something that can be emulated in the terminal, with frame/window-based implementations provided as extensions. That means that you can have a pop-up with method names starting with a few characters you typed, you can even have another pop-up beside that with docs for a given method, but you generally won't get that doc displayed as rendered markdown (you can't display headers with a bigger font in a terminal). It's 100% social and not a technical limitation - if you accept that you're only going to use Emacs in a GUI, you can get an IntelliJ-level of mouse and popup handling... Though it takes some effort.

That's the real problem, I think. You need to craft many of those features yourself out of available functionality. And it's not even a matter of some (even obscure) configuration, you will need to write your own Lisp to get the most out of Emacs. That's much more of a pain point and a respectable reason for not wanting to touch it. Technically, though, Emacs is not anti-GUI, and there are many packages that make Emacs pretty. Less so with mouse-friendliness, unfortunately, but you can configure it into something half-decent without much effort.

The only environment I know of that is (at least) equally powerful and flexible, but which handles GUI better is GToolkit[2] (VisualWorks was nice before the license change; now it's impossible to use) - a Smalltalk-derived system that uses the host OS (Linux/Windows/Mac) GUI directly through Rust bindings. A step down from there, but still respectable, is Pharo and the browser/Electron. Other than that, you have pre-written GUIs that you can't really change beyond what the developers planned.

[1] Vertico + Marginalia + Embark in my case

[2] https://gtoolkit.com/

I'd say most people run Emacs in the GUI mode, not in a terminal. So these days, you're pretty much on the same level as most rivals.

Sadly, "these days" is a low bar. The days of consistent platform-specific "Human Interface Guidelines" are over, it's all just a browser wrapped in a top-level window or something that simulates that, with most interaction patterns being a cargo cult of how it's remembered from the 90s. So "GUI" means that some unique overlays can be drawn without a fixed width character grid and that you might get the original file requester now and then.

Emacs solo actually contains functionality for just that, the below snippet which allows exporting xref buffers to grep format by pressing 'E'. You can then use wgrep etc.

  ;; Makes any xref buffer "exportable" to a grep buffer with "E" so you can edit it with "e".
    (defun emacs-solo/xref-to-grep-compilation ()
      "Export the current Xref results to a grep-like buffer (Emacs 30+)."
      (interactive)
      (unless (derived-mode-p 'xref--xref-buffer-mode)
        (user-error "Not in an Xref buffer"))

      (let* ((items (and (boundp 'xref--fetcher)
                         (funcall xref--fetcher)))
             (buf-name "*xref→grep*")
             (grep-buf (get-buffer-create buf-name)))
        (unless items
          (user-error "No xref items found"))

        (with-current-buffer grep-buf
          (let ((inhibit-read-only t))
            (erase-buffer)
            (insert (format "-*- mode: grep; default-directory: %S -*-\n\n"
                            default-directory))
            (dolist (item items)
              (let* ((loc (xref-item-location item))
                     (file (xref-file-location-file loc))
                     (line (xref-file-location-line loc))
                     (summary (xref-item-summary item)))
                (insert (format "%s:%d:%s\n" file line summary)))))
          (grep-mode))
        (pop-to-buffer grep-buf)))
    (with-eval-after-load 'xref
      (define-key xref--xref-buffer-mode-map (kbd "E")
                  #'emacs-solo/xref-to-grep-compilation))

Interesting. I use ELPA/MELPA all the time and find things pretty stable for my own uses. Surprisingly so, in fact. I honestly expected more hiccups. I wonder whether it’s differences between the packages that we use or the complexity of the configuration or what. Mostly I spend my time in Clojure mode with CIDER and Magit. I’m not trying to run email and calendar in Emacs.

Pretty much yes. I switched to eglot from emacs-lsp because of some frequent random errors ("document not added") that required me to frequently kill clangd; might be a PEBCAK problem, but went away with eglot.

Everything mostly worked out of the box.

I use it that way. It requires less setup than lsp-mode. Just try it – add `:disabled t` to your use-package lsp-mode, restart emacs and type `M-x eglot` in a C++ buffer.

The UX will be different and is a matter of preference. The performance depends solely on your LSP. So long as your LSP is the same and configured the same, it will give you the same results for navigation/completion.

Yep, me too. That’s the eternal trade-off. I’m always pretty sure that there’s a specific Emacs function or mode that does exactly what I want, but I mostly can’t be bothered to find it beyond a quick guessing search via apropos (C-h a). I brute-force my way through a lot of tasks using keyboard macros that might otherwise be solved more elegantly if I had the time.

Unjustified huge assumption by someone who has AI living free in their head incoming!

That's the beauty of open source

For me it’s org-mode. Although now that I think of it, there’s a Neovim implementation I’ve been meaning to try.

Perhaps these poor guys possess a secret wealth beyond your wildest imagination. I wouldn't give up Emacs for anything.

"a weapon from a more civilized age".

Not specifically superior for text editing, but it has some specific capabilities that make it ideal for making an editing environment. Specifically, it’s great at incremental, dynamic loading of small code snippets. This allows development of Emacs code without having to recompile and restart all the time. In fact, the low-level core of Emacs (buffer manipulation code, regex execution, redisplay, etc.) is all in C. But then those C routines are strung together with Lisp to make up all the high level functionality. Having a dynamic, incremental language is really handy for that. Does it have to be Lisp? No, not necessarily. But Lisp is a great choice.

The Lem editor[0] and LispWorks IDE's[1] are implemented in Common Lisp.

Still, the reason for choosing a language for whatever are always more social and path-dependent than technical (reason 1: initial developer of whatever really likes the language, reason 2: language is seen as hip within some crowd, reason 3 (later in the game): management feels language is safe). Technical reasons for choosing a language typically tend to be post-hoc rationalizations. (I mean, no sane person would choose Javascript for an editor based on technical reasons alone, yet here we are.)

[0] https://lem-project.github.io/ [1] https://www.lispworks.com/products/lispworks.html

It's a product of its time. In the mid 70s when Emacs was originally created, the MIT Lisp Machine Project had already been going for a few years, and Lisp was kind of a big deal at MIT's AI Lab, where it was created. When Stallman started GNU Emacs in '85 or so, he took lots of inspiration from Lisp and those systems.

You can think of Emacs as a kind of software Lisp machine with an emphasis on editing. Although that analogy only works well if you squint or if you don't know a lot about Lisp machines.

As someone who first learned Lisp through Emacs Lisp, I found it fun, well-documented, and powerful. Once you grok the basics of how the system is dynamically glued together, infinitely hackable, and self-documenting it's kind of mind-blowing.

A good reason is that Lisp has almost no syntax. So it can act as a neutral language that is easy to learn for developers from other languages.

Consider Lugaru Epsilon - an Emacs style editor that has a C based extension language.

Because it's very easy to generate lisp code. It's meant for metaprogramming

>Is there some reason Lisp is superior to any other general-purpose programming language for text editing?

purely for text editing? No. But that's not what distinguishes Emacs, it's famously very mediocre at it. The point of Emacs is to be a fully transparent, inspectable, dynamic and changeable environment. In spirit similar to Smalltalk systems like Pharo. And for that a Lisp is not the only choice but a very good one.

There's very few languages and environments that facilitate jumping into any place, making a change, compiling or evaluating a block of code or treating it as data and continuing seamlessly.

Lisp calls c in emacs. What would be a better language? The code-as-data, data-as-code paradigm fits nicely imo with everything-is-a-buffer. Things like global namespace, hooks, defadvice, would all feel very wrong in other interpreter, and yet seem to make sense in elisp.

But if you were implementing it in 1976 you would have.

This article isn't about reimplementing emacs.

BTW emacs is written in C.