I think I’ll take my REPL neat
My parens black and bed at three
CIDER’s too sweet for me…

– Bozier

Last week I announced Port, a small prepl client for Emacs. Today I’m following it up with another small Emacs package. Meet neat, a tiny, deliberately language-agnostic nREPL client.

Why?

For years I’ve been hearing some version of the same request: “could CIDER work with my non-Clojure nREPL server?”. Babashka, Basilisp, nREPL-CLR, even some homegrown servers people built on top of nREPL for languages I’d never heard of.¹ The answer was always the same kind of squishy “sort of, in theory, with caveats”, because while bare nREPL is genuinely language-agnostic, CIDER is not. CIDER was built for Clojure and assumes Clojure pretty much everywhere.

I always thought the right answer was “let’s gradually make CIDER more language-agnostic.” That’s the kind of plan that sounds reasonable until you actually try it.

The thing that pushed me over the edge was, oddly enough, building Port. Port is small, focused, and doesn’t try to be CIDER. Working on it for a couple of weeks reminded me how (deceptively) productive it is to start from a clean slate when the new requirements don’t match the assumptions baked into a mature codebase. Trying to retrofit CIDER into a language-agnostic shape would have meant fighting with every helper that ever assumed clojure.repl exists, every middleware contract cider-nrepl defines, every project-type heuristic that knows about deps.edn and project.clj and nothing else. A whole lot of “is the server Clojure, or is it the other thing?” branches. The Port experience reaffirmed that the right move for a genuinely different client is a new project, not a thousand cuts to an existing one.

So neat was born. The name is short, says what it does (it’s neat, both in the small-and-tidy sense and in the “no deps, no special assumptions, just the protocol” sense), and conveniently leaves room for puns I haven’t fully committed to yet. I might land on a backronym one day. For now it’s just “neat”.

What neat actually is

neat is a small Emacs nREPL client. The code is split across four files:

• neat-bencode.el: bencode encode/decode.
• neat-client.el: TCP connections, request dispatch, the standard nREPL ops.
• neat-repl.el: a comint-derived REPL buffer.
• neat.el: the entry point, customization group, and neat-mode minor mode for source buffers.

It only uses Emacs builtins. There are no external runtime dependencies, not even on clojure-mode, because neat doesn’t assume Clojure on the other end. If you write clojure-mode, fennel-mode, hy-mode, or anything else that talks nREPL, you turn on neat-mode in that buffer and it just works.

The connection routing is also intentionally library-friendly. There’s a buffer-local neat-current-connection override so downstream packages can implement their own routing logic, plus a global default for the simple “one server at a time” case that most people will want.

Capability discovery is done at connect time via the nREPL describe op. neat doesn’t hardcode “this server has completions, this one doesn’t” assumptions. If the server reports a completions op, the CAPF backend lights up (with type annotations next to each candidate, when the server provides them). If it reports lookup, eldoc starts working and M-. jumps to definitions via an xref backend. If neither is there, you still get a perfectly serviceable raw REPL.

Basic usage

Start an nREPL server. Anything that speaks the protocol will do. For a Clojure server:

1
2
3
4
5
clj -M:nrepl
# or
bb nrepl-server :port 7888
# or
lein repl :headless :port 7888

Then in Emacs:

1
M-x neat RET localhost RET 7888 RET

A REPL buffer pops up, the prompt follows the server’s reported namespace, and you can type expressions at it. Multi-line input works because RET only submits when the form parses as balanced under neat-repl-input-syntax-table (Emacs Lisp syntax by default, which is close enough for any Lisp). Input history is persisted across sessions.

If there’s a .nrepl-port file in the project, the prompt defaults to its contents, so M-x neat RET RET is enough to connect.

To evaluate from a source buffer, turn on the minor mode:

1
M-x neat-mode

The familiar bindings are there, intentionally compatible with what CIDER users expect:

neat-eval-buffer ships the buffer contents as an eval op; neat-load-buffer-file uses the standard load-file op instead, so the server can attribute file and line numbers to errors. Use the latter when you’re actually loading a file from disk and care about good diagnostics.

neat-set-ns sets the buffer-local neat-ns, which gets sent as the ns field on every eval op from that buffer. For languages where the namespace is declared in the source (Clojure’s (ns foo.bar), etc.), swap in a parser via neat-buffer-ns-function.

For juggling multiple connections, M-x neat-list-connections opens a tabulated-list buffer with one row per live connection, where you can set the default or disconnect interactively.

That’s roughly the whole user-facing surface today. There’s no jack-in command, no inspector, no debugger, no test runner. Likely there will never be, but if you need those you should probably be using CIDER anyways…

Should you use it?

If you write Clojure and CIDER works for you, keep using CIDER. It’s mature, full-featured, and supported, and I’m going to keep working on it for as long as people use it. Nothing about neat changes that.

But if you find yourself in one of these situations:

• you write a non-Clojure language whose runtime ships an nREPL server, and you’ve been muddling through with a half-supported CIDER setup,
• you write Clojure but you value minimalism and don’t need the full CIDER feature set,
• you’re building an Emacs package that needs to talk nREPL and you want a small, dependency-free library to build on,²

then neat might be a better fit. It’s small enough that you can read the whole thing in an afternoon, and the library/UI split (neat-bencode and neat-client are perfectly usable from other packages) is genuinely designed for downstream consumers.

The bigger picture

neat is part of a broader push I’ve been chewing on for a while now: making nREPL a healthy multi-language ecosystem rather than a Clojure-only protocol. That push has three legs:

1. An actual nREPL specification. The spec.nrepl.org draft is (will be) the formal version of what today is “whatever nREPL the project does”.
2. Reference clients. neat is one. The point of building a deliberately Clojure-free client is that it stress-tests the spec. Anywhere neat ends up needing to special-case the server, the spec has a gap.
3. A compatibility test suite. The parameterised integration suite in neat already runs the same assertions against multiple servers and surfaces real divergences (Clojure batching (println "hi") into a single out message where Basilisp emits two, for example). I’d like to grow this into a portable suite that any nREPL server can self-check against.

This is also why I keep teasing a “reference CLI client” in conversations. An editor client is one thing, but a small command-line nREPL client written in a non-Lisp language would be a much sharper test of how language-agnostic the protocol really is. neat is plausibly a precursor to that. Time will tell how far I push this; for now I just wanted to get the Emacs side moving.

Thanks

As always, big thanks to Clojurists Together and everyone supporting my open source work. You make it possible for me to keep tweaking and improving CIDER, nREPL, clj-refactor, and friends, and occasionally try something “neat” on the side. neat isn’t replacing any of the existing Clojure tooling for Emacs. It’s just another tool in the box for the people who want it.

Feedback, ideas, and contributions are most welcome over at the issue tracker.

Keep hacking!

Pretty much every project that I actively maintain on my GitHub account has a change log of some description. For a long time now, whenever I add a new entry to the log, I'll include a link to the PR that implements that change. Inevitably, this results in me adding the ChangeLog entry, creating the PR, then doing a follow-up change and commit now that I know the PR number, which allows me to add the link.

So I've created next-gh-pr.el to save me just a little time and let me be just a little more lazy. Inside it I've currently got a next-gh-pr-insert-markdown-link command which, when run, as you might imagine, inserts a link to the next likely PR URL as Markdown.

Working out the next URL is simple enough: get the latest issue and PR number, take whichever is the highest, and add 1. There is the wrinkle that discussions also cause this number to bump, and getting the latest discussion number is a little extra faff that I can't be bothered with right now, but my projects very seldom have discussions taking place anyway.

Marcin Borkowski (mbork) really likes all the ways you can mark files in Dired but noticed that an easy way to mark recently modified files was missing. He knows quite a bit about writing Elisp so it was an easy decision to decide to write some code to implement the missing feature.

The code, which you can see at his post, is pretty simple and easy to follow. What wasn’t so easy were some annoying design decisions. For example, what constitutes the current day? Is it 24 hours ago until now or is it the previous midnight until now? And by the way, should that be UTC or local time?

The natural interface is to specify the number of previous days you want to mark as a prefix argument but that leaves open the question of how to unmark the last n days. The natural solution—and the one mbork chose—is to use a negative n to mean “unmark the last n days”. So positive n, mark files modified in the last n days; negative n unmark file modified in the last n days. What about 0? Mbork made the arbitrary decision to have that mean mark files modified in the last 60 minutes.

There are a couple of other nuances that you can read about in mbork’s post. The real takeaway for me is how tricky it can be to get the small details right. That seems especially true when you’re dealing with time calculations. Questions like, “What, exactly, does ‘yesterday’ mean” turn out to be a lot harder to answer than they first seem. Take a look at mbork’s post to see what I mean.

I haven't been very active on this blog for the last few months. I've recently started a new job, and part of what I've been doing in my spare time is adding to my Emacs configuration to make some of the daily chores easier (or to remove them entirely).

If you know me, you know I'm not a fan of WebUIs, or just mouse-focused GUIs in general. Jira is no exception. Previously, I've had to deal with Jira's annoying click and drag nonsense and sort of dealt with it, but I've always wanted to be able to use it from within Emacs. Not just because that means no mouse-based WebUI, but also because it potentially means making custom automations around tickets. Enter the new job, where I'm able to make myself an API token, and therefore make use of org-jira for the first time.

You can see the config I've written around it here. This works basically exactly as expected, although I have had to do something a bit hacky to keep the API token properly stored. Storing the key on MacOS as recommended in the readme wasn't working for me, so instead I've stored it as a generic password. When launching Jira, this password is fetched into the kill ring to be pasted into the prompt if needed. This is kind of terrible, but it does work well enough.

(when (equal system-type 'darwin)
  (kill-new
   (string-trim-right (shell-command-to-string (concat "security find-generic-password -a \""
                                                     jiralib-user "\" -s \"jira\" -w")))))

You should be careful when storing the API token with add-generic-password, make sure you write it in the command with -w "<token>" and don't copy it into the prompt. When I was copying it into the prompt, the token was getting cut off, which was a pain to debug because Jira cloud doesn't have 401 errors for this sort of thing on the JQL search. You may also notice string-trim-right here: the output of shell-command-to-string includes the trailing newline, which will mess up the auth.

I'm also using my org projects space as the Jira workspace locally, which means I can use all the same organisation helpers as I do with my personal project files.

In terms of automations, org-jira already provides useful enough keybinds for progressing tickets, leaving comments, etc., and at the moment I don't feel like I need to improve there. However, since this Jira instance is integrated with Bitbucket, it's convention to use the ticket number when opening a new branch for work related to that ticket. That way Jira can show things like PR status, etc.

Because each Jira board or project only has one repository associated, I'm assuming that there will be only one directory for that project work, and that can be a customizable variable.

(defcustom jira-key-directory-alist '()
  "Directories associated with a particular project --- git repositories.
For example, (\"CBM\" . \"~/build/etc\") will use ~/build/etc for ticket-specific commands in the CBM project."
  :type 'alist
  :group 'jira
  :group 'theurgy)

Then this simple function fetches the Jira issue ID under the cursor, opens a magit status buffer in the appropriate directory, and starts branch creation.

(defun jira-branch-ticket ()
  "Create a branch from the current ticket, in the repository specified by `jira-key-directory-alist'."
  (interactive)
  (let* ((issue-key (progn
                    (org-jira-copy-current-issue-key)
                    (substring-no-properties (car kill-ring))))
       (project-code (car (split-string
                           issue-key
                           "-")))
       (project-dir (cdr (assoc project-code jira-key-directory-alist))))
    (magit-status project-dir)
    (kill-new issue-key)
    (call-interactively #'magit-branch-create)))

I'm not pre-selecting main/master as the origin here because it's possible that I may want to branch off something else. Nor am I pre-populating the branch name, just killing the ticket number, in case I need multiple branches per ticket.

Ideally, I would like to pre-populate the magit branch prompt with some editable default values, but I'm not actually sure how to do that, so this will do for now.

The next blog will look at the AWS CLI customisations I've built up, so stay tuned.

My favourite post this week was oantolin's tip about using Eww. It's always interesting to see what people can do when they apply Emacs's power and composability to all sorts of things, including evaluating code snippets from webpages. Outside Emacs, there was a lively conversation on HN about personal software. Enjoy!

• Upcoming events (iCal file, Org):
  • M-x Research: TBA https://m-x-research.github.io/ Wed May 20 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/GMT - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
  • Emacs APAC: Emacs APAC meetup (virtual) https://emacs-apac.gitlab.io/announcements/ Sat May 23 0130 America/Vancouver - 0330 America/Chicago - 0430 America/Toronto - 0830 Etc/GMT - 1030 Europe/Berlin - 1400 Asia/Kolkata - 1630 Asia/Singapore
  • Emacs Berlin: Emacs-Berlin Hybrid Meetup https://emacs-berlin.org/ Wed May 27 1000 America/Vancouver - 1200 America/Chicago - 1300 America/Toronto - 1700 Etc/GMT - 1900 Europe/Berlin - 2230 Asia/Kolkata – Thu May 28 0100 Asia/Singapore
  • Emacs.si (in person): Emacs.si meetup #6 2026 (v #živo) https://dogodki.kompot.si/events/67d716c3-6c04-4530-9c1a-f67aa44d31bc Mon Jun 1 1900 CET
• Upcoming events:
  • Sacha Chua: May 29: Emacs Chat with Omar Antolin Camarena
• Emacs configuration:
  • dotfiles/emacs/windows/.emacs.d at main · scovl/dotfiles · GitHub (@lobocode@hachyderm.io)
  • May I recommend… to only add items to your init files you understand and document | Martin's Blog
  • May I recommend declaring bankruptcy from time to time | acdw.net
• Emacs Lisp:
  • Charles Choi: Enhancing Elisp Development with Context Menus (Reddit, Irreal)
  • Amin Bandali: FFS code review and Emacs extensibility with Protesilaos (Prot)
  • Elisp Cheatsheet for Python Programmers - updated (@kickingvegas@sfba.social)
• Appearance:
  • How to automatically scale emacs to a larger font on startup (on Raspberry Pi) (22:22)
• Navigation:
  • fastctags 0.0.1 — Blazing-fast code nav & completion with Universal Ctags (Reddit)
  • purr.el - a lightweight project dashboard for emacs. (Reddit)
• Writing:
  • hesampakdaman/typst-overlay · GitHub
• Org Mode:
  • Org Mode requests: [RFC] LaTeX survey
  • Org Mode requests: [RFC] Round priorities in iCalendar export
  • Org Mode requests: [RFC] org-colview: Where should a new COLUMNS keyword be inserted?
  • Rezeptsammlung mit Emacs | Jan Iversen (@razorback@nerdculture.de)
  • Navi – Obsidian-style org-roam graph viewer – native window – reads your DB directly
  • Amy Pillow: Added notification actions in Org yaap - yet another alert package
  • Org Social for iOS: A decentralized microblog where your whole timeline lives in a plain-text Org Mode file you host yourself
  • #orgmode #emacs w/ its developer Ihor Radchenko, also screwlisp and JLamothe #lispyGopherClimate - toobnix (@screwtape@toobnix.org)
  • Import, export, and integration:
    • Blogging mit Emacs - Howto | Jan Iversen (@razorback@nerdculture.de)
    • orgfs – A FUSE filesystem for org files (r/emacs, r/orgmode)
    • [ANN] Starter template for your own blog in Emacs Lisp (Reddit)
    • ox-html-file-embedding 0.3.0, embed scrollable CSVs with PapaParse/Tabulator, postprocess with monolith
  • Org development:
    • org-agenda-clock-goto: Jump to closest entry and respect filtering
    • Feature requests:
      • Org Mode requests: [FR] ox-md: Export custom-id search strings (::#) as anchors
      • Org Mode requests: [FR] ox-md: Verbatim link export
      • Org Mode requests: [FR] Re: [FR] Tracking numerical habits
      • Org Mode requests: [FR] Tracking Habits with Alternate Calendar
• Coding:
  • Dave Pearson: Stopping an accidental push
  • James Dyer: VC-Mode Meets Magit - or Why I Finally Gave In!
  • Moving from lsp-mode in GNU Emacs to Eglot (lobste.rs)
  • aardsoft/lempo: Emacs protocol analysis framework · GitHub
  • Dave's blog: Remote Linux kernel development with Emacs
  • Bozhidar Batsov: Port: a minimalist prepl client for Emacs
• Web:
  • May I recommend eww for Emacs's innovative UI? (Reddit, Irreal, lobste.rs)
• Mail, news, and chat:
  • Check for missing body, subject, or attachments before sending (@jameshowell@fediscience.org)
  • Minimail version 0.5, with OAuth and more (Reddit)
  • Elfeed release & Elfeed sqlite database · emacs-elfeed/elfeed · Discussion #586 · GitHub (@minad@mastodon.world)
• AI:
  • Agent-Shell permission system (Reddit)
• Community:
  • What's So Special About Emacs? - YouTube
  • May I recommend… understanding Emacs's patterns (Reddit, Irreal, HN)
  • Emacs Carnival: May I recommend… stop messing around and get work done by Curtis McHale
  • The Most Emacs Bzr Saga (Reddit, lobste.rs, Irreal)
  • Sacha Chua: YE29: Sacha, Prot, and Philip Kaludercic Talk Emacs: Newcomer Experience (YouTube 01:24:16)
  • The Emacsification of Software — Quarrelsome (HN)
• Other:
  • Charles Choi: Using the Mouse for Emacs Rectangle Commands
  • Exam minimal Emacs, 42KL, try not to buy Armageddon Psychsparrow, what am I doing. (22:43, Reddit)
  • Some functions to make it easier to check for unexpected Unicode shenanigans (@zrzz@fosstodon.org)
  • hexmode/mediawiki-el: Emacs interface to edit any mediawiki site · GitHub (@katafrakt@genserver.social) - recently updated
  • James Dyer: A Tiny Nohup: Keeping Media Alive When Emacs Exits
  • r2r0/legion.el: Emacs mode for the Zammad help desk software - Codeberg.org (@r2r0@chaos.social) - vibecoded
  • Emacs Internal Part 04: Balancing Lisp_String Interval Trees by Text Length (Reddit)
  • Compiling Emacs for High Performance on Linux and Unix Systems (Reddit)
  • Tip for improving keyboard input latency by setting GTK_IM_MODULE=none (Linux, standard ASCII) (@jamescherti)
• Emacs development:
  • emacs-devel: Challenges of opaque objects
  • Allow child processes to continue after EPIPE
  • Copy changes from tarballs when installing VC packages
• New packages:
  • rare-words: Highlight your rare words! (MELPA)

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!

You can e-mail me at sacha@sachachua.com.

Of all the built-in editing commands in Emacs, the commands that work with rectangles delight me the most. Once understood, they can save effort in many situations.

That said, the biggest downside to rectangles is the amount of setup it takes to use them. As with many things Emacs, by default you have to memorize a bunch of keybindings to get anything done with them.

In Casual, I addressed the above downside by providing a Transient menu for rectangle commands. Since building that, I've come to use rectangle commands routinely. But even then, there is ceremony to set up a rectangle selection.

With my recent work on mouse-driven interactions in Anju, I’ve learned that rectangle selection is trivial via C-M-<mouse-1> dragging. Once selected, having a menu of rectangle commands makes working with them even easier. So I made one for the latest v1.4.0 update for Anju, now on MELPA.

The “Rectangle” sub-menu is available via the main menu bar “Edit” menu (as shown in the screenshot above) or via context menu. Using rectangle commands in conjunction with the align-regexp (“Edit › Align Regexp…”) and whitespace-cleanup (“Edit › Delete › Whitespace Cleanup”) can make short work of editing text that is laid out in columns. Anju makes both of these commands available from the main menu.

Side note: on using C-M-<mouse-1>, sometimes Emacs will only read M-<mouse-1> and do a secondary selection, leaving an unwanted highlight. Enter M-<mouse-1> to dismiss the highlight.

If you find Anju to be useful, please support its development by buying me a coffee. I’ve got a number of new features planned for it.

I have been a VC-mode loyalist for years, it is built in, it is simple, it covers the basics - commit, push, pull, diff, all there with C-x v bindings. I never really felt the need for Magit, honestly. VC-mode just works, right?

Until it does not. Or rather, until you need something that is not quite available. As vc-mode is source code control agnostic then there were always going to be some limitations and my git usage is now starting to become a little more advanced.

Recently I hit a divergent branch situation, remote had moved on, I had local commits, and git refused to push, I reached for C-x v m (vc-merge) to pull in the upstream changes, and that worked fine as a merge. But what if I wanted a rebase instead? Clean linear history, no merge commits?

Turns out there is no vc-rebase at all in Emacs! You can use vc-pull and it will rebase if pull.rebase is set in your git config (I think, although I haven't tried it), but there is no interactive vc-rebase command to invoke directly. And vc-merge only merges, If you want a rebase, you have to drop to shell or configure git to default to it. I wanted something more cohesive, more discoverable, and #sigh, here enters magit, I used it a few years ago so I still had a residue of muscle memory, but that said, I am not abandoning VC-mode entirely. For quick operations, a single file commit, a blame, a quick diff – C-x v I still like vc-mode. Magit is great for repo-level operations; VC-mode is great for file-level ones. They complement each other nicely, and there is no reason to pick one over the other, this is Emacs!

I added use-package magit to my config with a C-x g binding, full-frame status display, word-granular diff refining, and also released C-w in the magit status map so my window-management prefix still works (small things, but they matter):

(use-package magit
  :bind ("C-x g" . magit-status)
  :config
  (setq magit-display-buffer-function
        #'magit-display-buffer-same-window-except-diff-v1)
  (setq magit-refresh-status-buffer t)
  (setq magit-section-initial-visibility-alist
        '((untracked . show)
          (stashes . hide)))
  (setq magit-diff-refine-hunk 'all)
  (define-key magit-status-mode-map (kbd "C-w") nil))

On May 29, I'll chat with Omar Antolín Camarena about Emacs and Life.

<2026-05-29 Fri 10:30>–<2026-05-29 Fri 11:30> (America/Toronto) = Fri May 29 1030H EDT / 0930H CDT / 0830H MDT / 0730H PDT / 1430H UTC / 1630H CEST / 1730H EEST / 2000H IST / 2230H +08 / 2330H JST

Related links:

• Omar Antolín Camarena: a researcher at Instituto de Matemáticas, UNAM in Mexico City
• M-x apropos Emacs
• oantolin/emacs-config: My personal Emacs configuration · GitHub
• oantolin (Omar Antolín Camarena) · GitHub
• Omar Antolín (@oantolin@mathstodon.xyz) - Mathstodon
• u/oantolin on Reddit

This session will be recorded, and I'll update this blog post with notes: https://sachachua.com/blog/2026/05/may-29-emacs-chat-with-omar-antolin-camarena/

You can add the iCal for upcoming Emacs Chat episodes to your calendar. https://sachachua.com/topic/upcoming-emacs-chats.ics

Find more Emacs Chats or join the fun: https://sachachua.com/emacs-chat

You can e-mail me at sacha@sachachua.com.

I see a lot of blog posts recommending EWW. Sometimes I even write about them. The common theme is something along the lines of, “No, you can’t really replace a full-fledged browser with EWW but you can do a lot and a ”real“ browser is only a keystroke away.”

In another May Emacs Carnival entry, Omar Antolín Camarena offers his reasons for using EWW. He agrees with the conventional wisdom that EWW isn’t a replacement for a normal browser but that it is useful in many situations and even has some advantages over your default buffer.

He believes that one of the chief advantages of EWW is that it doesn’t run JavaScript. That’s ironic, of course, because EWW’s lack of support for JavaScript is one of its most oft cited shortcomings. But Camarena says that lack is often an advantage because JavaScript is often used to load ads or a paywall or to reconfigure your display preferences often choosing low contrast colors that are hard for anyone but the young to read.

His second reason for using EWW is that it brings the power of Emacs to your Web browsing. Among the advantages he lists are:

• You can easily resize images without changing font and other sizes.
• You can read the Web site content in multiple columns using follow-mode.
• You can use occur for a search and keep a list of results and easily navigate among them.
• You can evaluate ELISP directly in the EWW buffer and many other language as well with a bit of plumbing.
• You can use eww-readable to eliminate a lot of the junk that comes with many Web pages.

And, as Camarena stresses, you can always escape to a normal buffer with eww-browse-with-external-browser, bound to & by default.

Philip Kaludercic wanted to continue the conversation from YE24: Sacha and Prot Talk Emacs - Newbies/Starter Kits. He's spent a lot of time thinking about this as one of the main contributors to newcomers-presets. We talked about newcomers-presets, the idea of a "reset theme" that lets experienced users pin defaults to a specific version of Emacs, upcoming changes, and working with emacs-devel.

View in the Internet Archive, watch or comment on YouTube, read the transcript online, download the transcript, or e-mail me.

Transcript

Expand this to read the transcript

0:00 Opening

Sacha: I'm going to start recording. I'm going to do the thing. I'll let you know. Okay. Let's do this. Yeah.

Prot: Yeah.

Sacha: Yeah. Okay. Hang on a second. Starting, going live. Okay. So, hello, everyone. This is Yay Emacs 29. And today I am here with Prot and Philip Kaludercic. We're having this conversation about Emacs newcomer experience, which started off with an Emacs carnival last month about newbies and starter kits, which Cena started and you fleshed out with more questions. And now this is snowballing to, okay, let's figure out what we can do to make Emacs easier for newbies who are coming in, maybe they're non-developers who have heard good things about Org Mode, or maybe they're developers who want to try out what this Emacs thing is and what's all the fuss about having an editor that's been around for so long. Or maybe they're actually still VS Code or Vim fans, but they really just want to use Magit, so they're coming in just for that. A lot of different paths to coming into Emacs. We do have this live stream, so if people have questions, I will at some point figure out where the chat is on my screen so I can read them out to you. But my plan here is I'll just be in the background taking notes most of the time and interjecting with occasional questions. And maybe Philip and Prot, you can go brain dump all the wonderful things you've been thinking about the Emacs newcomer experience.

Philip: At this point, regret not having written down any notes from the last video or from your last recording of YouTube, because I noticed I had a few things I wanted to add or intersperse. But I guess we can take a look at two things. So first one is the state of introducing people to Emacs now. And the question there is, who are we introducing Emacs to? Just like you said, you sketched out a few different profiles of people who presumably have entirely different interests, motivations, like if someone wants to just use Magit like Emacs is there. It's the tool, it's the GUI that implements Magit, then these people have an entirely different motivation than someone who actually says, well, I'm coming at it from, I heard it's an interesting tool for free software development. Build your own or understand free software in a different sense, where you can actually do find-function and open the definition of the function you just used. I think malleable is the current catch word that people like to use in that context. So there's some issue in that sense.

2:59 newcomers-presets user option theme; would be nice to explain what the changes are

Philip: And then the specific comment from the last discussion which caught my attention was We were talking about Emacs 31, there's this preset theme, the newcomers-presets theme, which is implemented as a user option theme, or that's how I like to refer to it. And I probably should just briefly stop and say that everything I'm saying is from my own perspective. I don't feel comfortable saying that this is the Emacs-devel perspective or that any other of the Emacs developers necessarily have to agree with me. I just think that I might have a few things.

Prot: Sorry, I lost your audio. Just to say I lost your audio, Philip. Excuse me. Sorry, I lost your audio for a second. You could hear it fine. I will hear it in the recording.

Sacha: Okay, so basically, you can repeat it, I guess. Go ahead.

Philip: What did I say? So you were saying that... I'm not representing emacs-devel. These are my views which are informed by the discussions that we had in emacs-devel that I hope will be represented. I think I'm the maintainer of the preset theme, but of course other people are also contributing to it and adding other options. Specific points I had like the target audience of the preset theme was not people who would be particularly interested. What the options are. I think that was a discussion point last time. I admit it's a technical deficiency currently. There's no pretty way. I think it would be nice if we extended describe theme to actually list the options that are modified with hyperlinks so that you could look into these options. That's currently not there. We didn't add it in time for the feature cut for Emacs 31, but I think for Emacs 32 that's going to be an interesting Feature to have at some point.

5:00 finding a balance between "it's fine the way it is" and "just use Doom Emacs"

Philip: And actually the idea had been floating around I think like every time there was like there's a periodic, periodical discussions like how should we make Emacs more user-friendly on Emacs level and people say we have to like say the extremist position is what do you mean not user-friendly. It's perfect the way it is. It's God-given configuration. And the other people who say, well, why don't we just install Doom Emacs and make that the default then? Somewhere in between, I think there is a reasonable position to be had. But in these discussions, one of the reasons this came... I participated maybe in four or five of them, and then this point came up: why don't we have a theme, like a collection of user options, which you can toggle in one switch, which enable all the options from which we would not find, which existing users would not find interesting, which are always the bulk of the users. Most people are already existing users. They don't come in and... One of the things is, lots of existing users, I'm thinking of like a 60-year-old professor who has been using Emacs for 30 years, or a software engineer who's using it, and maybe consciously or unconsciously appreciates the fact that it doesn't change every few years. You don't have a graphic designer. This is, of course, me against graphic designers and UI designers who have a need to reinvent the UI interface every few years and then things change. And how do I save now? What's the... What's the button to do this? And the UI changes.

6:37 people value stability, but also conventions have shifted.

Philip: The people who value the stability. But of course, the common conventions have grown apart. What Emacs does and what people are used to from other programs.

6:50 ways Emacs does things differently: ex: terminal vs eshell, output is editable; new users want to edit the previous prompt; sometimes goes against people's intuitions

Philip: Now, at this point, we also have to distinguish that there are things which Emacs doesn't do the way other programs do, which are... Which I would argue are actually sensible. For example, I think one issue I remember was when I first started using Emacs, I had a terminal emulator. I wanted to have a terminal emulator within Emacs. Nowadays I use Emacs Shell, which to me seems like a more truer Emacs experience. It's an opinion, a strong opinion maybe. And it's also influenced by a history of using Plan 9 and that kind of terminal where actually the output is just as editable. You can just search it. You can edit it. You can cut it. You can interact with the output any way you would use a normal text, which is not something you can do with a terminal for purely historical reasons. At my university, the university where I studied computer science, I frequently helped people in the introductory Linux course. One thing you notice there, these are real newcomers. These are people who have never used Linux or a terminal or anything like that before. The first thing they do when they want to, like, they use the arrow keys expecting or click on, they use the mouse and click on the previous prompt. And they want to modify the previous prompt. Of course, that doesn't work because that's not how terminal emulators work. All the previous output, that's fixed. You don't touch that anymore. Everyone, I guess even people who we describe as newcomers, talking about Emacs, obviously know of course you don't touch the previous prompt in the terminal. These are some expectations you have, if you use Eclipse, if you use VS Code, if you use... I'm not sure how the NeoVim terminal emulator works. I know they have a built-in one. I think Vim also, but I'm guessing right now. So there are some accumulated intuitions which Emacs actually intentionally doesn't want to give, doesn't want to give in all purpose, because I'd argue that one of the strengths of Emacs is really having this uniform text interface where I can use isearch, I can use occur, I can use the highlighting commands, I can just select a region and write it out to a buffer, and stuff like that. That shell buffer is no different than anything else in that respect. Please interrupt me by the way. This is not supposed to be a monologue.

Prot: No, no, no. Go ahead.

Sacha: So it sounds like there's an interesting challenge here.

Philip: Breaking some of these intuitions is legitimate.

Sacha: Yeah.

9:21 How do people develop Emacs intuition? Immersion

Sacha: How do we help people develop the Emacs intuitions?

Philip: To some degree, it really feels like it has to be something that you immerse yourself in. The issue, I guess, is, well, I know, I mean, I knew people who actually used Emacs. I mean, you can help them in a face-to-face setting or like Prot does in his teaching settings. Then you communicate certain things, which I don't want to say they're ineffable. It's not like you couldn't write them down in a manual, but it's also... Like the mentality that people have.

9:55 example: dabbrev, there's no undo? Ah, it's just the regular undo.

Philip: A different example I have, like, I remember I was using daabrev for the first time or something. For a while I was irritated. There was no undo. Like, how do I go back to the previous text expansion? Until at some point I realized, oh wait, it's just regular undo. That's just the way you undo it. But somehow writing this down in a manual is... It's not an easy thing to always think of these things. For me it seems obvious now, but at that point I specifically remember it was unintuitive. I had this accumulated expectation from other programmers if I have a text expansion in this case that I'm actually cycling through some special sort of menu, not thinking of it as just regular text buffer operations. Just text editing in some fancy way. But that's one We should keep in mind. This was all related to the preset theme in some way, right? You're writing this down.

Sacha: Yes, I'm writing this down. That's why we have notes.

11:00 newcomers presets: smooth over the intuition-disrupting things that are not actually necessary/beneficial; ex: enable which-key

Sacha: So what I'm thinking is you wanted the idea behind the newcomers presets is to kind of smooth over some of those intuition disrupting things where people are coming in with maybe expectations of how stuff should work in a modern editor.

Philip: Specifically, the intuition. Specifically, the intuition-disrupting things which are not necessary, in some sense. Like, we wouldn't want to be an intuition disrupt... like you could probably... Like Cua mode or something, that would be something where people if they would start using... If you would enable Cua-mode by default, that would inhibit further development, because then it might be confusing with using C-c, like if you... because suddenly Delay becomes a user input, which is usually not the case with Emacs. I know which-key is an exception in that case, because which-key pausing actually is an action and displays a pop-up buffer. And we do enable which-key due to popular requests and the preset theme. I personally was a bit hesitant about that one, but it seems to be something. where you have to really weigh it on a case-to-case basis. But, Sacha, do you have the... What version of Emacs do you have running there? I can't make it out.

Sacha: Yeah, this is Emacs 31, so I do have...

Philip: So you can open the preset theme, right?

Sacha: Yeah, yeah. Hang on a second. Let me bring up a... I have now a terminal, so I can... Let me bring up a completely fresh Emacs.

Philip: No, I just want you to open the file. Because in the file there is a prelude. There's a commentary section that actually explains the curve. It's not a library. That's exactly the joke with the...

Prot: Yeah, that's part of the problem with those themes.

Philip: That's the problem. Themes are not libraries.

Prot: It would be easier if they were all there. It's a kind of an implementation detail that from a user, it doesn't really make a difference.

Sacha: All right, newcomers-presets.

Philip: If I remember correctly...

Prot: Yeah, yeah, exactly.

Philip: Yeah, and you see up there the commentary section?

Sacha: Yeah.

Philip: If you scroll up a bit, it's above line 37. The theme configures which we can reasonably expect the average user to want to enable, but would otherwise be unlikely to discover on their own. That's sort of the overall guide of what options we want to add. That's why it's also an option on the splash screen. You just tick it, and then the user options enabled in the theme should be activated by default. That's sort of the idea.

Sacha: It is available on the splash screen. So if I say display-splash... Oh my goodness, how do I get to the splash screen?

Prot: It's C-h C-a or not? I forgot. C-h a maybe?

Philip: There are two things. There's a splash screen and there's the...

Sacha: Hang on a second. I'm just going to start a new Emacs.

Prot: Yeah, I haven't done that in, like, I don't know...

Philip: That's the about Emacs screen. But you have a display splash screen.

Prot: C-h C-a on mine. About Emacs. M-x about-emacs.

Sacha: No, I have a better idea. I'm going to start this new Emacs person. Okay, here we go. New Emacs. Fresh person.

Sacha: So we click on this, right? And it turns on a bunch of things including the tab bar.

14:32 newcomers-presets choice is not saved at the moment

Sacha: I wasn't entirely sure how people would save that so that it happens again next time. Is the idea that they just keep checking that box?

Philip: That's not done currently. That's something we haven't simply decided on. The current presentation is you enable it in that mode and then you'd have to, which is of course saying it out loud makes it sound stupid, but you'd have to persistently save the themes. So then I think it's optional to save themes and then...

Sacha: It is possible for people to get to it if we leave them a breadcrumb. But it's not going to occur to them because it would never occur to them to say customize Emacs, custom themes, and then I can pick newcomers themes from here.

Philip: It's a point that I at least intended to mention at some point on emacs-devel, whether we want to make this, because currently it just loads the theme, but it doesn't persist the choice, but it could just as well persist the choice. There's a discussion to be had which of these two behaviors is more intuitive, because of course, if you persist the option, then you have the disadvantage that someone might enable it, but doesn't actually want it, but now somehow their Emacs is broken from their perspective. I don't want tabs or whatever they say, or I don't want which-key, and they don't know how to disable it. So this is... I wouldn't say it's an obvious decision in either direction.

Prot: Like if there is an enable button or save, there should be a disable and unsave, like remove.

Philip: Yeah, that's the checkbox idea in that case.

Prot: That would be the tricky part. And especially, finding the place on the splash screen so that this actually works for everyone... Because if you open it in a TUI mode, I think then initially, if I remember correctly, we had this button or this new to Emacs line was underneath the copyrights. No, no, that was a different thing.

Prot: If you click on newcomers preset, for example, then you are redirected to the manual entry. And I think we had some, yeah, there's this, the top line. If you got here by clicking the link on the splash screen, that was on the bottom. That was on the bottom of the manual entry. But if you open it up in an 80x24 terminal, you wouldn't see this line.

Sacha: You can't see it and you don't know how to... These are the complications that you have to keep in mind in that case.

Philip: You might not have the intuition that SPC is scroll, which I think that's the case in less. But yes, again, you have this accumulated intuition from using Unix tools. Which is one of the points I wanted to bring up.

17:08 newcomers without much computing experience might even find it easier (no C-c expectations, C-v etc)

Philip: Who is this mythical newcomer? What's their actual background? Because I claim, and this might be controversial, that if someone's actually new to using computers at all, which is something I have seen, like people who have never programmed, people who have never used Unix, people who have never used more than a web browser, to exaggerate, they appear to do fine with Emacs because they have no expectation of using C-c, C-v, C-c, and so on. They know that they have to use the buttons up there. So in that sense, they're fine. There's an optimization loop when you're used to these shortcuts and a few of these conventions how to move around, that Emacs defaults appear to be inconvenient. So that's also a distinction you have to make in that setting.

Prot: Exactly, exactly. Plus you cannot optimize for everybody. Eventually you just have to make some assumptions.

Philip: Exactly. But what these assumptions are is the controversial...

Prot: I think the way you approached it makes sense. This is the reasonable way, I think, to do it. You have to assume that they have this background knowledge. And if they don't, it's what you said. They don't have to relearn something because they didn't know it to begin with. So they start from a good basis.

18:30 Focus group?

Sacha: Is there interest in having some kind of focus group or something like that so that if we come across newbies, we can say, hey, you know, the developers would like to be able to float some questions once in a while to see what actual newbies would think of this?

Philip: I have actually tried this once. I was in a hacker... what's it called? There's this computer club in Germany and they have local events on a regular basis and I was going to one anyway because a few friends of mine were going there and then I did an introduction to Emacs course there and printed out a survey basically, a questionnaire for Emacs neophytes. I think if you search for that string on the Emacs development list, you're going to find that. And I gave a few people these texts. I printed it out. It was actually pieces of paper, so it wouldn't be personally identified. There wouldn't be any information there. And one of the things I thought was interesting in the results was that the main thing people were saying was it's overwhelming. Like the amount of things... Just the default Emacs. No configuration, no options, no auto-completion, no fido, whatever. It was just so many new things, so many differences that they lost an overview, basically. This was a group of people who, I think there were questions, and they were like, how long have you been using computers? Because, of course, it was so generic. What previous UIs have you had experience with? Most people use Eclipse or Vi, NeoVim and even reasonably complex Vim configurations. Of course, this is a bias due to the setting in which I was asking these questions. I'm actually planning to repeat this experiment because I'm going to another one of these congresses or these meetups in a month or so. I wanted to offer this again to people, specifically seeing if these newcomer presets are valuable or if they help people or not. But of course, doing this in a properly scientific setting would be much more difficult. Yeah, of course. We need money. Difficult steps of doing this.

Sacha: Maybe even like a mailing list. We can say, hey, you know, you're new to Emacs, but you kind of want to make it better. Email this person. And every so often when developers have a question, they can say like, does this make sense to you? Here's a screenshot. Or would you prefer this versus this?

Philip: As in, we would send an email to all the people, but then I think, I mean, the big question, difficulty in that sense is then data protection, I think. That's what I was trying to avoid with having this just printed out and no personal identification, because then we have to store email addresses.

Sacha: Okay, all right. That's fine. That's fair.

Philip: So, sounds like an excuse. Partially it is, but something like, I mean... I'm not saying that my approach, what I was doing was unbiased. There are people who would be more willing to answer these things and people who are less willing. I know the bias in this case because I actually saw the people and I had a feeling for what kind of people they were. So I think I'm in a better position to factor it out. But if it's actually properly, if you just have people who you send emails to

22:15 Emacs survey before

Philip: I'm not sure if it remains represented because there have been these Emacs surveys in the past. I remember at least two generations. And they're of course the ones which are circulated on Reddit, on Hacker News, on IRC, which I still think is a bubble of maybe 200 people. Like mainly 200 people and some people who are Surrounding these groups. So I'm always sort of dubious because these are the people.

22:48 people's backgrounds influence their responses

Philip: I mean, these are people who are much more likely to have heard of, what's it called, Evil Mode or something like that, or had some experience with other editors. And these things all influence their responses. always taints the results. Every time these discussions are brought up on Emacs devel, people have some level of doubts as to how reliable the results are.

Prot: Correct, correct. It's hard to get reliable results, though some data is still better than nothing. But granted, you don't want to base decisions on those results, of course not.

Philip: Yeah, that shouldn't be the last decision-making factor. You should just have a function where the input is whatever the data is, and then the output is mechanically determined by that. Yes?

23:46 Hypothetical: Reset themes, to reset things back to the defaults of a specific Emacs version

Philip: Now, related to the preset theme, there's also been a discussion (I don't think this has been mentioned much online) of so-called reset themes. I'm not sure if you've heard of these. So the idea would be, additionally to having preset themes of options, which we have changed, which we would recommend because the newcomer preset theme makes no real assumption that the options will be stable, so we might change them from version to version, this gives us some flexibility to say we have a new option. Like, for example, if the preset theme had existed since Emacs 29, and now in Emacs...

24:22 package-autosuggest-mode suggests based on file extension

Philip: That was actually the reason this entire discussion started when Emacs 31, that's the current release... to be released, there's this package-autosuggest-mode so that's a little prompt, when it's enabled, a little prompt in the mode line. You can click on it, Emacs installs the package which it believes to be the right one for the current file.

Prot: The major mode, right?

Philip: No, it's a minor mode. It's a global minor mode.

Prot: No, no, I mean, but it installs based on the major mode, right?

Philip: Ah, yes, yes, yes. It installs a major mode package, which matches the current file format being used based on auto-mode-alist or the magic, what's it called, magic file alist and all these things, and it can... We didn't want to enable this by default, but we wanted to enable it for newcomers. That was actually the first option in the newcomers preset. If the preset had been older, we would have still wanted to add this to the preset theme. It's not supposed to be set in stone. Now the idea with the reset theme is, and this is still hypothetical since we haven't implemented it, is to have reset themes for specific Emacs versions. So we, in Emacs 32, we might have an Emacs 31 reset theme for all the options that we have changed in Emacs 31, in Emacs 32, so that we could reset them to the previous option. So that in this sense too, if the discussion, if the question is really just, we don't want to annoy people who have... When upgrading, of course, it's still a minor inconvenience because they have to write load-theme emacs31-reset in their configuration, but it would be easier for them to actually undo any changes. And in future versions of Emacs, hopefully also persist these changes so that you can really sort of like pinning your version of Emacs, a soft pinning of options. So this is something for the future. Consider as well, which would be reusing the theme approach, which is another reason why I hope that the notion of user option themes will become more, because it's been there from the beginning. The Customize system has always supported user options to be added, but people have always only customized, not only... I'm not sure no one has ever done it, but it has not been a popular approach to use the user options, even though the technical facilities have been there all the time. That's also going to be interesting if the reset theme would be forwards compatible. But that's another discussion that makes it even more complicated. So that you could add them hypothetically to ELPA as a core package.

Prot: Nice. Yeah. Of course, the reset themes, if you implement them, that's great because it opens up the possibility to be a little bit more ambitious with the defaults and break.

Philip: Yeah. Because that's exactly... Every core... Every default discussion boils down to: if we break this, people won't understand what changed. If we change this, people won't understand what broke. But on the other side, people like all new... Can we reasonably assume that all new people would actually want this theme? Then we want to give us some sort of more flexibility in this sense without actually the support, because I think that the value proposition of having a stable interface where you can expect the appearance of the theme to be somewhat stable over time, how Emacs behaves, that's actually a positive thing.

27:52 Emacs 32: bundled versions of Emacs (Big Emacs - distributions that include more packages)

Philip: And finally, in Emacs 32, this is also a finally. For now, one thing I just thought of, which I was reminded of, there's a big plan for Emacs 31. This is one of, I've never pronounced his name, Sean Whitton, I think it should be pronounced. He said that one of his plans as a maintainer will be to work on the bundled version of Emacs, which some people, including myself, have been calling Fat Emacs. So adding, selecting certain packages from ELPA, from GNU ELPA, and bundle a secondary distribution of Emacs which would include additional packages, Which are currently, so for example, one example would be org-tex. And then you could, when you install Emacs, you could install, I don't know, big or fat or whatever... Big Emacs with all these packages pre-installed, which would be pinned to the right version which we would have hopefully ensured that they're actually compatible with one another. And then you have the normal Emacs, which would be the thinner one. And an interesting corollary of all of this would also be that if the way from ELPA into the core would be made easier, that the way out of the core into ELPA would also be made easier. Because that would mean it's more easier to deprecate packages over time since you can install it. This protective layer, let's say, protective layer, protected merely by inconvenience and the annoyance of moving these packages in and out, would fade away over time. Some cruft within Emacs itself, within core Emacs, could be moved to ELPA. So we could actually thin down Emacs. That's one possibility. Oh, that's big. Yeah. One strand of commentary in that direction. That's something that I'm planning to help in the Emacs 32 development cycle. Because these options then could also be in... Any options related to this could also be added to the newcomers preset theme.

29:54 Selection versus multiple completion

Philip: So one could of course... Vertico or these interactive selection packages... I think I've commented that before there is a certain controversy there. I think that there's a certain controversy that selection is not always the same as text expansion, which is sometimes like... There are, I think, the certain... skeleton, or there's this insert... what's it called, auto-insert command... It's not auto-insert, something like that, that prompts the user for multiple things, but it's not written using [completing-read-multiple], but it's written in a way that there's a manual loop, which waits for an empty input to occur. But if you're using vertico or fido, by default, if you just press RET, you don't actually have an empty input. You just select the default option. There's settings like these which where these sort of these two kinds of completion diverge from one another which which is also something I've been talking about for a few years but never came around to implementing that there should be an API distinction between actually selecting user options from a list and the completion interface which we have for files or commands currently. These are semantically two different things, which would be interesting to see if it would be worth distinguishing the two in a technical sense, because that would mean that in certain settings, we could enable Fido. I totally admit that Fido and Vertico have their advantages when it comes to discoverability over standard text completion. The compromise now was that in Emacs 31 there's this option, I think it's eager completion updating or something. It's a combination, it's a permutation of these words in some sense. So that's if the completions buffer pops up. No, you don't have to... It doesn't matter. You don't have to visualize it. Yeah, where they update as you type. Updates as you type, yeah. But that doesn't occur down there, but it only occurs in the completions buffer. That's sort of a compromise. That's Fido, right?

Prot: But the generic completions has had a lot of improvements over the last few years. And in Emacs 31, it's in a very good state, all things considered.

Philip: Which was also partially driven by your MCT package?

Prot: MCT, yeah. Which was an experiment, of course. But yeah, it's basically that idea. Because I have used this in earnest, like the default like this, I have used it for a long time in earnest, like just defaults. It's very good. It's for sure very good. Whereas Fido and Vertico are better if you are just getting started and you don't know that there is a completion on the mini buffer and somehow there is a distinction between the two. Like, for somebody who is getting started especially, I think this interface is not good. But if you know what you are doing, I think this interface actually works perfectly. And it has a lot of options. So, Sacha, what you are showing there is the absolute default, but it has so many options that you can make it look actually quite different from this and very similar to Vertico, for example, in terms of the user experience. I just realized that...

Sacha: Oh, I just realized that if you do the TAB TAB, if you do the TAB TAB, it now goes to that one, which is great, but you can't filter it from there. You can't type into it and have stuff happen.

Philip: Yeah, it's not down there. If you're down there in the mini-buffer, you type. There you have just a regular text buffer, so you can search or you can select stuff out of there.

Prot: And that's also an option, by the way. So what happens on the second tab, for example, so you can configure that.

Sacha: Right, so that was the second tab behavior from newcomer-presets.

Philip: That's the option I proposed and then objected to.

Sacha: Yes, work in progress. So basically, you have these newcomers. We're trying to figure out how to get them through their learning journey. The newcomer presets can smooth over some of the edges. It can get over that "Yes, there are a lot of options, but at least M-x with tab completion will show you the things so that you don't have to memorize the names as much." You can recognize them from the list. You can narrow it down.

Philip: The behavior is supposed to actually be similar to Bash, the way Bash does completion.

34:39 Manuals

Sacha: It's probably still... we're going to need them to read the tutorial, and we're going to need them to use a lot of patience as they get used to Emacs. I am not quite sure yet if we can get them all the way to, all right, here's how you open your config file and define your own keyboard shortcuts, for example. Bit of a journey.

35:08 More examples?

Prot: I think that one way to do that is to have more examples in the manual. Like, here is how you do this, here is how you do that.

Philip: Or there's this other manual, the Emacs FAQ.

Prot: I don't mind where it would be, like FAQ is totally fine. I don't mind exactly where it would be, but somewhere in the documentation, like common patterns of Emacs configuration kind of thing. Maybe it already exists, so if it exists, then of course even better.

Philip: Emacs FAQ has some things on finding related packages, common requsts, bug reports, but maybe it was... I remember there's something. If I link to it...

Prot: Where is the FAQ?

Philip: It's a separate manual.

Sacha: We do not have it from here, not from the splash screen, but it is available from the Help menu.

Philip: I think it's not been that thoroughly maintained.

36:22 find-user-init-file?

Sacha: I'm going to take advantage of the fact that you've actually been reading emacs-devel. Has there already been a long discussion about whether a M-x visit-user-init-file makes sense? An interactive command that you can use to open... I was trying to find it, but even with Yhetil's search, I was like, okay, there are four threads. One of them was a long time ago, and the other one was from even longer than that, so I didn't know whether it was some other discussion.

Philip: I don't recall any such discussion recently, but I also don't think that anybody Objection to it. So it's really just a matter of someone writing it down and adding the documentation.

Sacha: I would like to do that.

Philip: It would be quite likely 24 hours.

Sacha: Okay.

Philip: On the master branch and not Emacs 31 branch, which would be slightly... It's fine. Yeah, but even having a button...

Sacha: If it makes it in someday, it doesn't have to be in the splash screen. It just has to start off being available through... And then we don't have to keep telling people, oh yeah, do a describe-variable on the init file just in case your init file is actually .emacs instead of the .emacs.d/init.el that other people are telling you to use instead. It's a bit of a mess, right?

Philip: I think some people have been recommending doing M-: and then calling the [find-file] function with the user init... What's the name of the variable again?

Sacha: user-init-file.

Prot: User Emacs file.

Sacha: Here we go. user-init-file. Here we go. That's the thing. Yeah, exactly.

Philip: And if you do M-: (find-file user-init-file), then it would basically do the same thing. That's why I'm saying it's such a minor function that I don't expect any objections.

Sacha: Okay, okay. So I'm going to suggest that to Emacs Devel at some point.

Philip: I've had the same idea many times myself, but the transience of memory has thrown its way before I actually ended up doing it.

38:38 Getting over the reverence for Emacs's history

Sacha: Sometimes I am reluctant to suggest things because I figure Emacs is such a long history. Probably someone has thought of this already, and it's probably been discussed and bike-shedded. But I think there are little things that we can do.

Philip: Yeah, but then in that case, Yeah, but I think that's actually related to another thing I wanted to talk about. There's a certain sort of reverence that people have for Emacs, because it's such a historical project. But I mean, the preset theme was something that was discussed for many times, and there were basically no objections. No one said, no, we shouldn't do this, this is a bad idea. I hope it's not only because I proposed it or something, or like the package also suggests that. Most of the things I've been working on for Emacs 31, no one objected to. And there's two sides to this. There's some people who actually go overboard with this and try and reinvent. Like when reviewing packages, you see this a lot of people try and reinvent functionality, which is basically just giving a new name Combining two things and giving it a new name which isn't always necessary but might be useful and then it's some discussion like can we actually make more out of this and that's a different thing but then there's the people who I probably lean more towards that side when I think to myself the way I'm doing this is stupid or this is not as efficient people have been using Emacs for 40 years of course there probably has to be a better way to do this

40:11 Changes are more likely to happen when someone puts in the work to make a patch

Philip: And sometimes it turns out it simply hasn't been implemented and no one has simply done this actually small effort of preparing a patch and ironing out the details just some people don't like discussions of course and it's understandable but you can I mean there's really no harm in sending a patch and then saying I'm sorry I don't have It's annoying, of course, from a maintainer's perspective. I don't recommend doing it, because if you prepare a patch but don't have the time to finish it up, then if it's a useful thing and you actually get someone to be interested in maintaining it, then bringing the patch to completion, then it's well worth just sending a feature. Even sending a feature request, you don't even have to... I mentioned the idea of this preset theme many times. I wish people would be more conscious of this mentality, but I totally understand people who think otherwise, because when the first time I sent a patch to a mailing list, I was, I don't want to say I was sweaty, but I was really nervous because I don't know what if they insult me or they say, "you fool, you didn't format the test properly, [??] secret handshake you have to do every time you send a patch. Begone." Whatever. Which is of course not the case. Which is not to say that there are no unpleasant people on mailing lists but I think that there is especially the GNU Kind Communication Guidelines, which are supposed to give some sort of goodwill, good faith, attention to how people should behave on mailing lists, how they should treat each other. Lots of these preconceptions turn out to be false in there. That's why I also wanted to participate in this, so that people see, oh, the people maintaining Emacs aren't wizards locked up in a tower, but just, I hope, normal people who happen to spend more time with Emacs.

Prot: Yeah, that's a very good point.

Philip: Which is why they're valuable, these discussions.

Prot: And I think, Philip, just to add to this, your example of leading with a patch, I think, is also key here for someone who can write a patch, of course, because it cuts out a lot of that noise, that initial discussion of, well, maybe yes, maybe no, because it frames minds. It focuses the attention on something concrete. And that can also... Yeah.

Philip: Yeah. And... I mean, having a patch is useful, but getting someone interested is also helpful. Like the discussion when we merged which-key, I helped with that process. And I'm not, I think it was, I don't remember his last name, Jeremy, who actually did most of the work. And I was reviewing his patches. I was helping along, but I wasn't actually writing most of the code. I was just going over the proposals and helping along and basically pushing the... Stunning the process whenever it got stuck so that we actually made the necessary changes for it to get merged.

44:03 Preserving Git history of packages absorbed into the core

Philip: And then I did the last finishing touches of merging, because that was also something... Every time... We'd like to preserve the Git history of packages we merge upstream, which is probably something we won't be doing in that way when we do the Fat Emacs releases. But the entire history of Eglot and the entire history of which-key is actually preserved in the Emacs Git repository. So if you open the file, you have, it's not anymore a tree in a computer science sense, but it's actually a proper DAG, because suddenly you have multiple roots of the project which come together with the history preserved. And that's an annoying thing to do with Git, but you can do it. And not everyone knows how to do it, but a few people have the commands written down somewhere or look it up on a mailing list, as I do. Then that goes through, but that's...

Prot: So they are wizards after all.

Philip: Wizards just reading pre-written down spells.

Sacha: It'll be interesting to see if some of the starter kits move to using that kind of fat Emacs infrastructure once that's in place. Because a lot of times the starter kits are there to package together. Okay, here's a list of the packages that it uses. Here's the configuration that makes them play nice together. And then here's some kind of Documentation or videos or a demonstration on how to use it to help people get started.

Philip: So I'm curious to see, I mean, I went reviewing the options to add to the preset theme. I actually went through a number of these starter kits to see the options they suggested. Selected those out which seemed reasonable to me. And of course, this was discussed and people objected or added other things. But I am curious to see how the starter kits will evolve in the future, because that's also something we should mention.

46:00 Dealing with multiple types of Emacs

Philip: I mean, there is a big problem with the fat Emacs approach and suddenly you have two versions of Emacs. You can write a package which appears to work fine in fat Emacs, but it depends on a package which is not in the core Emacs release, and then that's something we will have to deal with in the future as well. Yeah, that's a tricky part indeed. Yeah, but another thing relating... Yeah, the sort of fragmentation of what core Emacs is. It might be a showstopper, so maybe everything I'm telling here is just a wishlist. It doesn't end up actualizing. And that fragmentation of the setup is one of the things... Because it's not actually really difficult to solve. I mean, if you have a package that depends on something from Fat Emacs who just added to the package requires lines, you explicitly state the dependency. But if people are sloppy, then they might not notice this immediately. And you have runtime issues when people are slow.

Sacha: It's a little bit more than that, right? So for example, if you have a newbie asking a question, because they're using a starter kit or in the future, a fat Emacs thing with different packages installed and different configuration things that they have not personally set up. And they don't have the experience to know, oh yeah, this is going to be related to that. So I should mention it in the help message. I mean, large starter communities like, like Doom Emacs and Spacemacs will have their own Discord or mailing list where people can go and ask for help. And so people will say, okay, I think I kind of know which starting point you're coming from because it's the base. But if we're, you know, with the smaller starter kits, they don't even know how to ask for help. And everyone is like, on the regular Emacs communities, there's a lot of back and forth if you want to dig into, okay, what do you have enabled? What is affecting your setup? Fat Emacs is going to run into that problem.

48:09 Fat Emacs is just about bundling more packages from ELPA, not changing the configuration for them

Philip: To be fair, my understanding currently is that it wouldn't enable any other options. It would just bundle more packages.

Sacha: I see.

Prot: So it would be more of an issue for package authors.

Philip: Yeah, for package options. The idea is, I mean, I've used Emacs in offline settings where it's like, really inconvenient or impossible to install additional packages, and just having more functionality out of the box which ELPA provides and you don't have to install additionally, is basically the idea. Because this has been a project which has been ongoing for years. I think this is ever since the conception of ELPA itself, which is precisely the reason why GNU ELPA requires all packages to be signed or to be covered by the copyright assignments, while NonGNU ELPA does not: so that this is possible. It's just that finally it looks like we're starting to move somewhere in that direction. It would be interesting if a decision were to be made that we're going to give up on this sort of bundling, what decisions that were made for the legal status of GNU ELPA, if we would merge GNU ELPA and NonGNU ELPA together, which is unlikely currently. This is just pure speculation at this point, but it's something that might be a discussion, which will be had in the future.

Sacha: Okay, so it dispenses with a package install part, and so people don't have to worry about, okay, how do I make sure The package archives are set up, and how do I install the packages? All that stuff will be pre-installed. The auto-mode-alist will be... Oh, sorry, go ahead.

Philip: The package archives wouldn't matter that much, since we are just talking about the GNU ELPA packages, which are installed by default. It's really just that you don't have to install additional packages. You don't need a network connection. You don't need to know about the package existence. It would be registered in the auto-mode-alist anyway. So if you open a, I don't know, what's the package, some major mode that's not going to open, which is not in the core.

Prot: I think you might [??] earlier. I think that would qualify. I think you mentioned auctex earlier, which is on ELPA, but not in Core.

Philip: The tricky thing there is that Emacs already has a LaTeX mode by default, and that already applies, but auctex extends it. That's why I was looking for another example. Okay, that's the idea, but it wouldn't only be major modes, I assume. There's going to be some discussion as to what packages we want to add. Currently, it's not certain. Because we're working on finishing up Emacs 31. That's where most of the bug fixing efforts are going in right now before we progress to any further developments. But that also includes proposals. That includes proposals as to the preset theme, which I am still interested in reading.

51:23 Customize

Sacha: I want to come back to something Prot mentioned in my conversation with him about newcomers, and that is the Customize interface versus getting people to the Emacs Lisp directly. And I think, Prot, you were not very keen on Customize.

Prot: Yeah, basically if I say it in one sentence is: I think the earlier they get into Emacs Lisp, like seeing it and interacting with it, the better it is for them long term. Granted, I am making the assumption that this is a user that will be there long term, right?

Philip: Of course. And this is specifically about the Customize UI, right?

Prot: Yeah, yeah, not the underlying functionality, like, yeah.

Sacha: It's great for simple options like, yes, we can check the checkbox, or we can select from the drop-down list or whatever, but browsing it is, as you mentioned, overwhelming in the general sense of Emacs being overwhelming, and when you start wanting to do something slightly more sophisticated like you know, let's add some more capture templates, then it's challenging for people to do. So I'm wondering whether, in general, we should be... Is our general strategy to be guiding people to, yes, Customize is there, but really you want to be doing Emacs Lisp as quickly as possible. Let's make it easier for you to get your init file. Let's make it easier for you to test your init file and not fall apart when you miss a parenthesis and all, things like that. Do we want to guide people that way?

Philip: One question I think we should distinguish is the idea of a UI the problem or is it really... Because I personally I have a new Emacs configuration at my day job, and I do everything using Customize. I don't even care about using use-package or whatever. Just customize the stuff using... There's a big blob of user options which I've modified, and that goes through, and I don't care about it, but I claim to have some understanding of what's going on, and the rest of the function is just some defuns which I find convenient. But for me, it's okay, because I have some sort of intuition of how the Customize UI works. If there were a better UI for Customize, would you still say that if it were written in an intuitive way, say using Fido modes. So that's, it would use interactive narrowing and it would somehow work in a build on existing intuitions because the current Customize, the Customize UI, the easy customization interface I think is a technical term to use is based around this widget library interface and sort of make replicating a TUI menu but not... And then you have to... And yeah, of course, the intuition... Like, if you click on things, it doesn't always behave the same thing you would expect from a regular settings menu, which is by the way also something that CUA specifies.

54:41 CUA - Common User Access

Philip: I recently looked into what CUA lists. Like, if you look at the Wikipedia page, CUA specifies that every application has to have these settings menu with tabs on the bottom on the top where it lists all the options you can specify and interestingly C-c and C-v is not listed as...

55:00 ini file format? https://sdf.org/~pkal//blog/emacs/ini-init.html

Philip: Apparently not CUA, but Shift Insert and Control Insert... I might be misunderstanding this, but this seems to be a misnomer.

55:10 Emacs configuration generator

Philip: But if we had some sort of a UI like this CUA configuration UI, would that be something where you'd say as an intermediate stage for just setting options? Because that was part of my thought process with Emacs Configuration Generator. Just configuring Emacs is such a subset of Lisp as it's actually not programming Lisp. You can easily get by by just using add-hook, set up or setq, and add to list or stuff like that. But you don't really have to understand. It's just a peculiar syntax for how to program Lisp.

55:54 INI-style configuration

Philip: I'm not sure if either of you have seen, I wrote a blog post last March, no, not March, what's the name of the month? November, October or something, where I gave a prototype for a INI-like configuration syntax.

Prot: I must have read it, but I don't remember it. You must have read it. Yeah, yeah, yeah, because I always read my feeds, but now it doesn't ring a bell.

Philip: Exactly. You see there's this basically a simplified syntax, which should be... The idea was it should follow a conventional configuration-like format, and each of these lines gets translated directly to an Emacs Lisp expression. And due to this, I don't want to call it an isomorphism, but the easy translation in both directions, I think that the expectation of saying write Emacs Lisp... There has to be some defun or something if you're writing Emacs Lisp. That's to exaggerate. If you're just writing setq, set, add-hook, add-to-list, these common configuration patterns, which are well worth documenting in the manual, to understand what are the patterns that you have to use to configure a package, even understanding the signature... The distinction between add-to-list and add-hook is that hooks are lists which can have mode-local extensions but also inherit from global settings. Not obvious from the beginning to everyone. This is not list programming.

Prot: Yeah, fair enough. Though even then, they start to see the parentheses, get used to the syntax. They have to remember to quote stuff. Even though it's not really programming, I see what you're saying. They put themselves in the situation.

Philip: One of the ideas precisely in the config syntax is that if you have an option like set, you see the first line, set mode line compact long. Long is a symbol. I just use regular read to read this, and it's not evaluated. There's an option down there somewhere, I think, eval set, where the format expression is an S expression that's evaluated to a string. So you have to opt into evaluation. which seems more intuitive to me for a regular configuration when you're writing it, because all these things... Like, I have to think about quoting. Then there's the issue like with with-eval-after-load... Can I customize this variable before the package is loaded, after the package is loaded? If it has, like... If you're adding something to a list and the list has a default value that you don't want to set the value of the default, don't want to add it to the list because then it's not loaded, and it could trigger a undefined variable signal. So these are other inconveniences that I don't, I personally do not see any value in teaching people or having people to deal with these sorts of issues before they have any broader intuition. Which is a very idiosyncratic take perhaps, but...

Prot: No, no, it's fair.

Philip: What I'm trying to get at is this sort of any configuration syntax would be something that a UI could generate a lot easier and in a way that wouldn't have this artificial split between your own personal handcrafted configuration and the generated part of the configuration. Mechanically changing this, finding the section package avy, because it has all of these primitives which didn't exist early on in Emacs, like packages and features exist and so on. The sort of structure which use-package usually provides.

Sacha: I have about one minute before the kiddo starts on lunch break, so I'm going to interrupt a little bit and do a quick summary. But the two of you are welcome to keep hanging out and chatting. I'll leave the Big Blue Button room open. And if you want, I can set it up so people can join you, depending on your time, et cetera, et cetera.

1:00:21 Quick summary

Sacha: But basically, what I'm getting for a quick summary of the conversation: Emacs 31: the newcomer presets is work in progress. People are definitely open to improvements, ideas, other suggestions for other features. The kiddo is just running out now. I will put the chat in the thing.

Prot: Yeah, of course, of course. That's fun. So, what's happened?

Sacha: Do you want me to open up the chat to everybody? Or do you have other things?

Prot: Me, I can stay for another 20 minutes. Just to say I can stay for another 20 minutes because then I have to take the dog.

Sacha: Yeah, and Phil? Oh, you have to leave.

Philip: 20 minutes is fine. 20 minutes is fine for me as well.

Sacha: Okay, okay. I will put the thing in the chat and people can continue because the kiddo was like, ah! Okay, yes.

Prot: Okay, okay, okay. Good. So, yeah, of course, there is a chat going. Yeah, let's see. So, Sacha, you will link it there. Ah, nice.

Philip: So, I presume there has been an idea of people watching this.

Prot: So this is live.

Sacha: And I can copy the chat thus far since we didn't even get to any other questions. Hang on a second. Where am I even?

Prot: We're trying to deal with those, right? Yeah, yeah, yeah. Well, eventually to have a discussion and also take questions, eventually you need to have more time, I guess.

Sacha: Yeah, yeah. But thank you all so much.

Prot: Yeah, yeah, yeah. That's good. Yeah, yeah. Thank you, Sacha. Thank you very much. And of course, the kiddo overrides all.

1:02:27 Continuing with INI

Prot: That thing with the INI, I think it's very promising. I mean, if you flesh that out. Because the other thing is, yeah, with the INI configuration, because what would be, though, the fate of what is now added, you know, when you modify something and it adds this, you know, this has been set by Custom, do not touch it kind of thing. You know what I'm talking about, right?

Philip: Yeah, you mean the generated user glob. Well, my idea, or if I were, if I had the time /motivation/whatever to flesh this out, because currently it works... Currently it's an actually existing Elisp file which you could use, but I think it would be most interesting if it would be upstreamed. It would sort of be like, if you don't have a .el file, Emacs would look for it .ini file, or emacs.ini file or something like that. Then, of course, you can check, like, does the INI file exist or does the .el file exist? Probably there would be a user option to select into which it would inject the new options. And by default, it would select, for example, if the INI file exists, then it would use the INI file. But there is some controversy to this, because I totally understand the sentiment we're coming from with... You're using Emacs, so you have to learn Lisp. But for me, the bar is a bit higher than just the inconvenience of writing out this more or less. It's, as Joel Sussman referred to it, this ritualistic Lisp. You always have to repeat the same stuff all over again, like with eval, afterload, set. add-to-list, then you have to quote the option in one case. And if you change something in a map, then you don't have to add it. And of course, if you know Lisp, then you know that in one case, a keymap is a cons cell, so you're actually modifying the rest of the cons cell. That's why you don't need to quote it. But in the other case, you're accessing it via symbols, so you need to quote it. But this is all technical details. There's no necessity in it. It doesn't have to be that way.

Prot: Yeah, yeah, yeah, that's fair, that's fair, of course.

1:04:42 Motivation

Philip: One thing I wanted to bring up in the discussion when we were talking about reverence was there is, I mean, one part of the thing that gave me the motivation to go through with learning Emacs, even though I didn't use the tutorial initially, was sort of a reputation I heard about Emacs. And the videos I saw, wow, you can do these cool things. And this motivation, this image I had of Emacs help me go through, but if you overshoot this approach, then people expect too much in the beginning and are disappointed in the end and don't pull through. There's this question of having, how's it called, the ??... How to motivate people enough to be interested in Emacs, to actually learn it, but not to oversell it. If you give some sort of a demo of using Emacs, which is simply not representative of how it actually works, then that's something which would backfire. But I guess we can take a look at the questions, right? Yeah, let's see. Let's see.

Prot: Yeah, yeah, yeah. So yeah, I didn't read them. I had the chat open, but I didn't have the time to read them. Sorry? I'm not sure how to parse these. Is this from top to bottom? I guess from top to bottom is how they arrived in the chat. The top is the earliest.

Philip: The usernames are mentioned below.

Prot: I guess that's a copy-paste thing. Yeah, yeah, yeah. So there are some...

Sacha: I gave the kiddo some packed lunch, so I'm back.

Prot: Oh, hello there!

Philip: We were just wondering about how to read the comments you posted. Maybe you have a better UI.

Sacha: I pasted them into the chat. So in the Big Blue Button...

Philip: But that's the order of occurrence?

Sacha: That's order of occurrence. It's totally not very... It's just like a big paste.

1:06:50 Politics and philosophy

Prot: While you read it, let me... Yeah, there is a comment there from LC2000 about the splash screen having a lot of emphasis on the legal side, which is a fair comment. I think the legal side is important though, because of course, free software and all that, but of course, it could be rearranged. So maybe you don't want to have it at the top front and center, you want to have it further down. Maybe. I don't know. I don't have a strong opinion, but I think the legal side is it should be there at some point. I feel like it's a political minefield though.

Sacha: Just leave that alone. Otherwise: 200 comments on emacs-devel, one of those really long threads.

Philip: I cannot under-emphasize how surprised I was when my suggestion to add a checkbox on the splash screen just went through. Because I expected people to object, no, we can't add it there because of some system. It wouldn't look the way it should look and that would be confusing or whatever. But apparently change is possible. You have to be careful and be patient.

Prot: And I guess here there is an assumption, right? There is also an assumption that people will attack you or be unreasonable. And I think this is not true. You mentioned it earlier as well. Eventually you have to get on the mailing list because people, if they don't hear the opinion, the counterpoint, they will never know what to do with it.

Philip: But it's not entirely unreasonable because there are discussions that can be... There are people on emacs-devel, it's sad to admit it, but there are people who voice strong opinions, like strong opinions, with no power behind them, which can scare people away because there's no... There are no tags. There's no index of people on emacs-devel, so you don't know if some John Doe responding to your message, if he's actually responsible for this and makes a decision, or if it's if Eli is sending a message and his decision on the discussion actually weighs a lot more than other matters.

1:09:23 Experimenting with things outside core

Sacha: I feel like sometimes experimenting with newbie-focused resources, like the unofficial ones that are around... At least we can try the ideas out and then say, hey, here's the patch and also here's what people have been using it for, so you can see it a bit more concretely, than dropping an idea into the discussion and then having the whole bike-shedding happening without as much data.

Philip: That's seriously my main recommendation. If you want to propose something, add a prototype, add a patch, add something to narrow down the discussion. That's something people would take away from this discussion, from my experience.

Prot: I 100% agree. I think that's the way to go. Just implement something so that it focuses the attention. Otherwise, you will get those endless discussions very quickly.

Sacha: Or try it as a package first, and then it can be core.

Philip: Excuse me?

Sacha: Oh, I was thinking if it's possible to prototype something as a package, now that Emacs has made it a lot easier for people to install packages, then at least it can be tested before having all the conversations about whether it should be as part of core or part of the splash screen or everything else.

1:10:42 Extending the core

Philip: The counter tendency I feel obliged to mention is that many times proposing something as a package or as an extension to the core can actually simplify the implementation vastly. Especially if you need to make one or two twists upstream and you need something like an additional hook or something to exist upstream. If it's a package in the core, then it's a lot easier to explain why you have to make this change than having to deal with some sort of advice and changing a lot of things. There was a certain tendency during the mid-2010s, which I only know from history, was to re-implement a lot of stuff in logs, in packages, instead of working on them upstream. That created a lot of divergence between packages, and in my opinion, complicated things because it introduces this entire choice fatigue. Should I use Flymake? Should I use Flycheck? Should I use LSP mode? Should I use Eglot? Which is not a historically accurate example in the stats that I'm given, But I'm certainly in favor of at least considering upstream contributions.

1:11:52 Guide to contributing to ELPA

Philip: Even like packages, of course, it's the way we recently published these guidelines, or not guidelines, this contribution guide to publishing packages on ELPA, which is on, if you want to open it in the browser, it's on the ELPA homepage, which lists sort of these hard criteria which we require from ELPA. Just elpa.gnu.org, yeah, it's... That's going to be a link to the page.

Sacha: Yeah, this is pretty recent.

Philip: This is recent, and then there's a list of suggestions. But this is getting off the actual point. I'm just saying that relating to the general point, my experience is that proposing something concrete but also be open to hearing the opinions of other people These are the two necessary but maybe not always sufficient ingredients to making the changing stuff. Because if you just say, I want this to be different but don't put in the work, then everyone's going to forget it. But if you propose something and then insist that it has to be exactly this way, then you're just creating social tension. Maybe missing out on interesting things.

1:13:11 Making the newcomer experience better

Sacha: And especially since people are using Emacs for so many different reasons and coming from so many different backgrounds, what you are very firmly committed to might very well work for one set of people, but will run into these issues for all these other people. So if we want to bring it back to this, you know, how do we make the newcomer experience better? It's great that in core, there's starting to be a little bit more infrastructure for supporting things like sets of reasonable defaults for people. And maybe we as a community need to figure out, all right, how do we write documentation around it? How do we make tutorial videos? How do we encapsulate, okay, this is what this typical newcomer experience is like for this set of people and maybe these options or packages or a glue code might be helpful for this group? Maybe.

Prot: Yeah, like in theory, you can imagine something like, if you are a Python developer, here is your Python presets theme. If you are doing Org or whatever, here is your LaTeX and friends, right, and you could also have extensions like that in the future.

Philip: I mean nothing about the idea is... It could have been used as a package people can load otherwise.

1:14:30 "user option themes" versus "appearance themes"

Philip: And hopefully, as I said, there is certainly additional work which can be put in to support making user option themes better supported. I think one of the things that will be useful is actually referring to them just in nomenclature points as user option themes to distinguish them from.

Sacha: From themes.

Prot: From color themes, yeah.

Philip: Color themes, yeah. We even introduced the distinction that themes have kinds since like Emacs 20.

Prot: 29, I think.

Philip: 29.

Prot: I think you did that, right?

Philip: I think I worked on a patch. But that was exactly, I mean, that was already where the seeds for the current theme were started, because we wanted to distinguish between these different kinds of things. Were there any other questions?

Prot: I don't think so.

1:15:24 find-library

Prot: But yeah, as we saw now with the find-library that Sacha did in the beginning, it would be nice to also eventually be able to find the theme or whatever. Maybe it's a different find-theme, if for whatever reason it cannot be find-library.

Philip: That's actually no reason why that shouldn't be the case. I mean, you could just extend the logic to not only consider the load-list, but also the... Whatever the variable is for the list, then it should be able to find that as well, even though it's strictly speaking, that's a library. But that's a decision that someone has to make at some point or convince someone.

Sacha: I think find-library does work for it. Like, find-library will find it only if it's loaded. And then since I can't, like, undo it...

Prot: If it's a package...

Sacha: Yeah, yeah.

Prot: If you install it as a package, yes.

Philip: Because then the theme is in a directory which package.el has added to a load list. I think the preset, if my memory serves me correct, then find library only looks through load-path.

Sacha: I see, I see. And etc/themes is not in the load-path.

Philip: Exactly. Because these aren't, this is, I don't know why. It's not...

Sacha: Okay, all right. That's another message to emacs-devel.

1:16:49 configuration generator in Emacs? maybe more wizards?

Philip: It's the sort of annoyance which from my perspective is so inconvenient that I forget it every time and then you don't change it.

1:16:59 Starter kits

Sacha: @brongulus says the Doom Emacs module approach is very nice for beginners and entices them to get into things more. People interested in a certain common set of functionality can get an opinionated starting point in Emacs, rather than worrying about what to install. And someone else in the previous That's sort of like the theme approach, isn't it? Sort of, yeah. It's not just, hey, these are the packages and you can comment and uncomment lines that load the different modules, but also here's the glue to sort of start to make some of them work better together or to change them to reasonable defaults.

1:17:39 Configuration generator in Emacs Lisp?

Sacha: I was wondering, actually, along those lines, any thoughts about making your configuration generator type thing in Emacs?

Philip: The reason I, in the configuration generator, did not implement it in Emacs was precisely due to if it were in Emacs and would use, for example, something like the widget library and there would be these fine UI discrepancies which people wouldn't expect to behave the way they do, then scrolling doesn't behave exactly the way they expect it to do. But there has been an idea, I think, when I mentioned the configuration generator the first time. It was the notion of having actually a shared file format behind it, just some S expression, which could be loaded by both the configuration generator and a generic configuration wizard, which could also be used like every package could define their own configuration wizard for asking the user selected options and configuring these.

1:18:40 extending the archive format

Philip: That's also another thing in Emacs 32 which I plan to work on, to extend the package archive format. Among other things, allowing for multiple packages to be listed in it, because GNU ELPA and NonGNU ELPA both store multiple versions of all packages, but you can only install the most recent one. That's why pinning doesn't work. Absolutely no technical reason why this shouldn't also list other versions as well. And then you could have pinning without having to use Git. Packages as well. And there are a few others. There was a thread I think earlier this year where I collected a number of these extensions for the archive formats which could be extended. And now I forgot my thread. Now I lost my thread of those.

Prot: But basically extending package.el and the archive, yeah.

Philip: Specifically the archive, so that...

Prot: Showing the previous versions which are already listed, like you said.

Philip: Yeah, so that you could pin the version so you could install the version. I honestly do not remember what I was saying just a few seconds ago, which is embarrassing. Okay, that's another problem.

Prot: Things happen, no worries.

Philip: You were talking about Doom Emacs?

Prot: There was a comment about the Doom Emacs and specifically the fact that there are these modules and you can load the module without thinking specifically about the packages. But then Sacha told you about your package configurator wizard.

Philip: Package configurator wizard and then extending the metadata could also include this sort of configuration option. So that packages, in some sense, could specify what options the user would primarily be interested in and what order they should be traversed. And you could have some sort of dependency, of course. This is some effort which has to be put in, but it's not something that's unreasonable, from a technical perspective, from implementing this. And it would make, I think, it could make, if you have the infrastructure for that, that would make installing and using packages a lot nicer. It sounds very promising, for sure.

1:20:56 User interfaces

Philip: The UI question remains the thing. Do you want to reuse the Customize UI, which has its historical warts? Of course, can they be ironed out? That's a different question. Or do you reinvent something from scratch? And I'm usually not that big of a fan of reinventing the UI. I'm more in the reuse existing interfaces, just into the back end.

Prot: Plus, if you were to invent a new UI, you wouldn't have this new feature already because you have too many things that you need to implement. Whereas just using custom UI allows you to just implement the feature and then the interface, maybe it's something that somebody else will work on or you work on at the latest.

Philip: Yeah, but then, of course, that's... Even if that is the case, then you have to make sure that you don't make assumptions that depend on your own customizer in the future. It's a whole list of dependencies which is just complicated.

Sacha: That sounds like a newcomers presets to un-wartify Customize, a reset theme to put the warts back on as needed, and then we can use the slightly more modern interface for the things that we had wanted to do, maybe two or three years down the line.

Philip: Maybe something like that. A little long-term planning.

Prot: I think just to say this, but of course everything we have covered thus far, always we have to state it. Newcomers with an asterisk, right? With the caveat that you still have to put in the work, read the manual, be patient, all that, right?

Philip: Ideally, it would be nice if you could even start without it. I mean, I started without it, but it took me three or four years to actually write this one. I didn't want to write defun. I thought, what? I don't write my own functions. I just want to set options, which was wrong and appealing to this. That was the point from the beginning. But I think, Sacha, you wanted to close there.

Sacha: Oh, I just wanted to acknowledge that we are coming up in the 20 minutes that you said you were available for. Yeah, yeah, yeah, I need to go. Yeah, yeah, the dogs and everything.

Prot: Yeah, yeah, I have to take them for a walk because I have a meeting afterwards.

Sacha: Right. I wanted to thank both of you. I really like this conversation and the heads up and the interesting things coming down the pipeline. So thank you for that. We're going to continue, I think, working on the user experience for newcomers. which will probably be a mix of documentation and packages and other experiments and occasional email to emacs-devel suggesting things like the find-user-init-file and whatever. But thank you so much to you and to everyone who's tuned in.

Prot: You're welcome.

Philip: Thank you for hosting.

Prot: Thank you.

Philip: Thank you, Prot, for your comments as well.

Prot: Take care.

Philip: Bye-bye.

Prot: Goodbye, goodbye. Where do we close from here?

Philip: I'm just going to close the tab. Bye.

(bind-key "C-c r" 'org-capture)

Some screenshots of a fresh Emacs

Trying pkal's Emacs Configuration Generator

Emacs Configuration Generator - old source code, site is no longer live

sbcl --load ecg.lisp --eval "(ecg:start)"

Sample generated configuration:

;;; Personal configuration -*- lexical-binding: t -*-

;; Save the contents of this file under ~/.emacs.d/init.el
;; Do not forget to use Emacs' built-in help system:
;; Use C-h C-h to get an overview of all help commands.  All you
;; need to know about Emacs (what commands exist, what functions do,
;; what variables specify), the help system can provide.

;; Load a custom theme
(load-theme 'modus-operandi t)

;; Use whatever the default monospace font is
(setq font-use-system-font t)

;; Miscellaneous options
(setq-default major-mode
              (lambda () ; guess major mode from file name
                (unless buffer-file-name
                  (let ((buffer-file-name (buffer-name)))
                    (set-auto-mode)))))
(setq confirm-kill-emacs #'yes-or-no-p)
(setq window-resize-pixelwise t)
(setq frame-resize-pixelwise t)
(save-place-mode t)
(savehist-mode t)
(recentf-mode t)
(defalias 'yes-or-no #'y-or-n-p)

;; Store automatic customisation options elsewhere
(setq custom-file (locate-user-emacs-file "custom.el"))
(when (file-exists-p custom-file)
  (load custom-file))

You can comment on Mastodon or e-mail me at sacha@sachachua.com.

Charlie Holland has an interesting contribution to May’s Emacs Carnival, which this month is on the topic “If I may recommend…” His notion is that Emacs is an effortless bloom. The “effortless” part is because Emacs—contra conventional wisdom—is easy to use and can, in fact, significantly simplify your work flow by providing a uniform interface to several different computer programming languages and their environments. If you’ve ever had to negotiate such a collection, you know that this is not a trivial thing.

The “bloom” part is more nuanced. The idea is that like a rose whose roots “fan in” water and nutrients and whose flower “fans out” its petals and beauty to encourage pollination, Emacs has its own fanning in and out. The center of this action is the text buffer. Data from various sources can be fanned into a buffer from which it can be fanned out to various functions for processing. The altered text buffer can then be fanned out to other targets.

Holland’s post is a bit lyrical so you need to read it to get the full impact of his fan in, fan out metaphor. He considers whether any other editor could achieve the same power as Emacs. He concludes that any editor could, in theory, achieve the same power but in order to do so it would have to replicate the idea of the buffer as the single important data structure on which everything else operates.

It’s an interesting post worth a few minutes of your time.

Before we discuss Rewrite Bun in Rust, there's something that needs to be said, because no one is saying it.

Bun stands where it does today because of Zig.

Jarred chose Zig back then not because it was "cool," but because Zig enabled a small team to rapidly prototype a high-performance JS runtime without a GC, without a heavy runtime. Zig's low friction, direct memory manipulation, and straightforward C interop were the core reasons Bun could punch above its weight on performance with an extremely small team in its early days. The architecture, data structures, and low-level design of Bun that you see today – that was shaped by Zig.

In the recent weeks I've been engaging Prot as an Emacs coach to help with doing review passes over my upcoming ffs package as I work on polishing and documenting it in preparation for offering it for inclusion in GNU ELPA.

UPDATE 2026-05-15 08:50:10 -0400: Prot also published an article about our session on his website: https://protesilaos.com/codelog/2026-05-15-emacs-amin-bandali-ffs-display-buffer-org-capture/

Today we had our third session where we started by reviewing and talking about my recent changes to ffs, then ventured to other Emacs-related topics with the overarching theme of the flexibility and extensibility of GNU Emacs, including display-buffer-alist, keyboard macros, defining a custom ox-bhtml Org export backend derived from Org's ox-html for ultimate flexibility when exporting my site's pages from Org to HTML, Org capture, plain text files and Emacs's diary and how it compares to org-agenda, and keeping a journal with the help of Emacs.

Here is the video recording of our session, which I share with Prot's permission:

You can view or download the full-resolution video from the Internet Archive.

Lastly, here is the snippet Prot shared for having Isearch treat space as a wildcard, helpful for more easily matching multiple parts of a line:

(setq search-whitespace-regexp ".*?")
(setq isearch-lax-whitespace t)
(setq isearch-regexp-lax-whitespace nil)

Take care, and so long for now.

Yesterday I met with Amin Bandali to talk about Emacs. Amin asked me if he could record the session, which I agreed to. The video is available on Amin’s website: https://kelar.org/~bandali/gnu/emacs/ffs-emacs-ext-prot.html.

We started with a review of the latest changes to the ffs package that Amin has been developing. We had looked into it before and wanted to check on its current state.

Amin then asked me about the display-buffer-alist, which I had mentioned before. To me, this is the single most important variable for making Emacs feel more like your own. The reason is that it allows you to control the placement of buffers to match your expectations. I demonstrated some of the main ideas.

Another nice little feature is the built-in isearch. I explained how it is especially helpful while recording keyboard macros. Though it is nice to use in general. One tweak for it is to display a counter with its matches. Another is to change how it treats spaces, so that it can match any character in-between. This is not as flexible as, say, consult-line (from the consult package) when combined with vertico and orderless. Though it still has its uses.

[ I have lots of little extras for isearch, but those should be good for most users. ]

Amin told me about rediscovering the value of Org in the context of statically generating his website. He showed me the custom Org HTML export backend he has been working on. Org has so many nice features which can be used independent of each other. In this light, we also discussed the diary compared to the Org agenda.

Find all of Amin’s publications on his website: https://kelar.org/~bandali/.

Thanos Apollo has an interesting post about an almost forgotten Emacs battle: the choice between Bazaar and Git as the new version control system for Emacs. Twenty years ago, Emacs was still using CVS, a venerable RCS that was well past its sell date.. It was clear to everyone that a new system was needed. The question was which one. The two contenders were Bazaar and Git.

On the technical merits the choice was clear. Git was faster and more reliable and most, if not all, of the developers wanted to move to it. But there were political considerations. Bazaar was a GNU project and Git was not. RMS felt strongly that the GNU project should support its own applications and insisted that Bazaar be used and given a chance to improve. It was maintained by Canonical but they eventually abandoned the effort. Even though the development was stalled and error reports were piling up unresolved for years, RMS insisted on staying the course.

The saga would probably still be going on were it not for Eric Raymond (ESR). He had been working for some time on a utility to import various RCS systems into Git while maintaining whatever metadata the old system offered. At one point he decided to convert Emacs to Git. It was a particularly difficult problem because there was more than one source RCS in play and because some of the records were old and incomplete.

Nonetheless, ESR managed the conversion and in 2014 announced that he had the conversion scripts ready and was set to go. In November 2014 he ran his scripts and suddenly Emacs was available as a Git repo. The developers started using it and the battle was over.

After starting to make use of the GitLab/Codeberg sync approach for various repositories, I found that my muscle memory in Magit was getting the better of me and, on occasion, I'd push a new branch to backups when I wanted origin. I sensed there had to be a way round that.

Here's what I settled on:

(advice-add
 'magit-list-remotes
 :filter-return (lambda (remotes) (delete "backups" remotes)))

Now I never see backups in Magit and now I can keep using my muscle memory (rather than actually reading what is in front of me, it seems).

A few weeks ago, Bozhidar Batsov had a splendid post on cl-flet, cl-letf, and cl-labels. I didn’t get a chance to write about it then but his post is very useful for understanding these macros and how they differ.

The macros are the replacements for the now deprecated flet, which, in turn, was imported from Common Lisp with the added feature of having dynamic scope. As Batsov points out, making the scope dynamic conflates the notion of local and dynamic scope, which can be a bit confusing. This behavior is preserved by the cl-letf macro for those who need it.

The cl-flet macro is just like the flet macro from Common Lisp. It defines a local function whose definition is available only from within its scope. The salient fact is that its definition is not available from within the function definition so it can’t be called recursively.

The cl-labels macro is like labels from Common Lisp. It’s similar to cl-flet except that its definition is available from within the function definition so it is recursive.

Finally, the cl-letf macro largely replicates the behavior of the old (Elisp) flet macro with the addition that it can dynamically replace the definition of any setf-able definition. This can complicate its use a bit. See Batsov’s post for the details.

If you’re like me, you don’t use any of these macros that often so it’s easy to forget the details. For that reason it’s worthwhile bookmarking Batsov’s post so that you can refresh your memory whenever you need to.

This post is simply about some more yak shaving and there was this one niggle that I just kept putting off, because it never really annoyed me enough, but recently I started watching a lot more video content from within dired and it finally got to me.

The problem. I press W in dired, which is bound to dired-do-async-shell-command, type mpv (or accept the default guess that my dired-guess-shell-alist-user provides for video files), and the video starts playing. Great. But when I close Emacs, the video dies too. The whole point of an async command is that it runs in the background, right?, so why does it disappear when Emacs goes away?, this is most perplexing!

Now I should say, the answer is obvious in retrospect, but it took me a little while to actually stop and think about it properly. The command dired-do-async-shell-command adds a trailing & to the shell command and passes it to async-shell-command, which creates a shell process - Emacs is the parent of that shell, and the shell is the parent of mpv. When Emacs exits, it kills its child processes, the shell goes down, and mpv gets orphaned, which is fine actually, the problem is not being orphaned, the problem is that it receives a SIGHUP from the process group cleanup and dies before it can be reparented to init. So the media stops.

The solution is a single, tiny piece of advice. I just prepend nohup to the command string before dired-do-async-shell-command does anything with it. nohup makes the process ignore SIGHUP, so when the shell gets killed by Emacs, mpv is orphaned cleanly and keeps running.

(defun my/dired-async-shell-command-nohup (orig-fun command &optional arg file-list)
  "Wrap COMMAND with `nohup' so the process survives Emacs exit."
  (funcall orig-fun (concat "nohup " command) arg file-list))

(with-eval-after-load 'dired
  (advice-add 'dired-do-async-shell-command
              :around #'my/dired-async-shell-command-nohup))

That is it. Six lines of Elisp, five of which are boilerplate.

And yes, this works for any command you run through W, not just mpv. gimp, firefox, libreoffice - they all get the nohup treatment now. Which is fine, those programs usually detach themselves anyway, but it does not hurt to have it.

So that is the tweak. A tiny, one-function, one-advice change that finally stopped my videos from dying every time I closed Emacs. I suspect someone will tell me that there is a simply variable flag that I can set that enables this anyway, but hey ho!

Keyboard Commands

I ran out of keyboard commands.

OK, that sounds weird. Let me explain. In Alfred, I have the following keyboard assignments:

⇧⌃A: App Store
⇧⌃B: BBEdit
⇧⌃E: Emacs

I had covered the alphabet. Every letter had an application associated with it. I started a second layer. I assigned ⇧⌃⌥B to Better Finder Rename, ⇧⌃⌥E to EagleFiler and so on. Soon I was running out of choices again.

Over a period of almost 15 years, I made do. I loved Alfred, I also loved keyboard commands. I wanted to be able type a keyboard command and then choose from a list of applications which were tied to that keyboard command. I wanted to be able to type something small to be able to navigate this list and launch the application I wanted.

I didn’t know how to do this in Alfred. I had hacked together a solution in Keyboard Maestro, but I wanted to do it in Alfred. It was my launcher. So, I went to the Community for Alfred and asked, Choosing to launch particular programs with a shortcut - Workflow Help & Questions - Alfred App Community Forum. FireFingers21 answered with a workflow.

FireFingers21’s solution had two parts:

1. The ability to assign a keyboard command to a workflow which would give me a list of applications assigned to it. I could press the keyboard command and then choose from a list by typing the number corresponding to my choice. Hit ↵ to launch.
2. The ability to assign a keyboard command to a workflow which presented a similar list. This time the list could contain multiple applications grouped together.

This Is How It Helped

Outliners

Previously, I had ⇧⌃O assigned to open OmniOutliner. The same command now gives me the ability to launch OmniOutliner, Zavala, or Opal, depending on my needs. This is now the Outliner keyboard command.

Editors

⇧⌃E, opened Emacs. Not anymore, now it can open any of these programs. Don’t laugh. I am aware that I have too many editors installed.

Multi

I have Hyper-A assigned to multi-application launches. Every morning I used to start my workday by pressing Hyper-A and that would launch:

1. SpamSieve
2. Mail
3. Safari
4. Ghostty

Now it gives me a choice. I can also launch my updates group:

1. Applite
2. Mac App store
3. Latest
4. Wailbrew

One keyboard command, groups of multiple applications launched together.

Conclusion

1. I have keyboard commands to spare.
2. Alfred is a great product. I knew that.
3. The community around Alfred are helpful and informative.
4. Don’t hesitate to ask questions when you don’t know how to do something. There are helpful people around who might have the answers and they are willing and ready to help you.
5. Thanks to FireFingers21 and Vero for their help.

Note: Thanks to Darren Halos for the picture.

macosxguru at the gmail thingie.

Charles Choi is back with more menus. Most of you know that I generally eschew the use of Emacs menus but they definitely have a place in seldom used commands whose name or key shortcut are hard to remember. In most cases, it’s possible to play around with fuzzy command completion and find what you’re looking for but it’s a lot easier to simply use a menu if it’s there.

That’s where Choi’s latest update to Anju comes in. He says that the introduction of context-menu-mode in Emacs 28 made it possible to provide cotentxt sensitive menus for Elisp development and he has added it to the latest version of Anju.

His post has a couple of screen shots of his menus in action. In the first, the point is on a function definition and the menu, among other things, offers the choice to instrument that function. In the second, the function has been instrumented and now the (context sensitive) menu offers things you can do—such as step into, set a breakpoint, and others—with the function. Naturally all of this is dependent on where the point is. That’s the point: the menu is context sensitive.

Choi says that the use of the context menus has markedly improved his Elisp development. If you do some but not a lot of Emacs development, it may be a win for you. On the other hand, Choi certainly does do a lot of Emacs development and still finds it a win. Perhaps—no matter your normal workflow—you will too.

For ages I’ve had “add prepl support to CIDER” sitting somewhere in the back of my head. CIDER is built firmly around nREPL, but prepl ships with Clojure itself, and the appeal of dropping the external REPL server requirement is obvious. Recently, as part of a broader internals cleanup “mini-project” in CIDER, I finally sat down and put a prototype together: cider#3899.

The good news is that the prototype sort of worked. The bad news is that the more I poked at it, the more I kept running into the same pattern. CIDER assumes ops, sessions, request ids, and a whole structured protocol that prepl simply doesn’t have. The amount of CIDER code that would need to grow “is this nREPL or prepl?” branches added up quickly, and I’d be papering over prepl’s limitations in dozens of subtle places. The exercise was fun, but it ended up reaffirming my long-standing belief that nREPL is a much better fit for editor tooling than prepl is.

The exercise did leave me thinking though. What if, instead of bolting prepl onto CIDER, I built a small standalone client in the spirit of inf-clojure and monroe? Something tiny and focused that doesn’t have to pretend to be CIDER, and where prepl’s quirks would be the design rather than something to work around.

Conveniently, I was on vacation in Portugal at the time, where I spent a few days in Porto, and the name pretty much picked itself. Port was born. It kept us firmly in the land of fun, drink-inspired Clojure-on-editor names: CIDER, Calva (after Calvados, the apple brandy), and now Port (the famous fortified wine). The protocol Port talks to is prepl, over a TCP port, so the pun was hard to pass up.

This time around I didn’t manage to land on a backronym I love (at least not yet). The contenders so far:

• prepl omnipotent repl toolkit (my favorite so far)
• prepl-operated repl toolkit
• peak optimized repl toolkit

Naming is hard. I remain open to better suggestions. :D

Scope, or what Port isn’t

Port is a side project. I don’t plan to invest serious time in it past the point I consider it feature-complete, which won’t be far beyond what’s already there. The deliberate goal is to keep it simple and focused, and its feature set will stay close to inf-clojure and monroe. Port is not competing with CIDER. If you want the full feature set (debugger, inspector, test runner, profiler, structured stacktraces, refactor support), CIDER + cider-nrepl is, and will remain, the way.

What Port gives you today is a small, dependable Clojure REPL that you can hook into Emacs without any external dependencies, just a stock Clojure JVM with a prepl listening on a port.

A few architectural notes

If you’re up for the long version, doc/design.md goes deep. Here’s the short version of what prepl gives you compared to nREPL:

• No bencode. prepl emits EDN-tagged maps, one per line. This might be a feature or a problem, depending on your perspective.
• No middleware. Whatever the server prints is what you get. No interception, no extension surface.
• No sessions. There’s one thread per TCP connection.
• No ops. You send a Clojure form, the server evaluates it, and prints back tagged messages: :ret, :out, :err, :tap, plus an :exception true flag on errors.
• No request id. This is the main issue. Tags identify the kind of message, not which request produced it.

That last point is the central design constraint. If you want to issue a request and reliably read back its result without accidentally consuming output from an unrelated background future or tap>, you need to layer correlation on top of the protocol. Port does this with two tricks:

1. Two sockets per session. A user socket drives the REPL buffer with raw streaming output, and a separate tool socket carries helper-command requests. Background prints from future/agent on the user thread don’t bleed into the tool channel.
2. A bootstrap form. On connect, the tool socket evaluates a one-shot form that defines a port.tooling/-eval wrapper. Every subsequent helper call goes through it, which captures *out* / *err* and returns a tagged map containing the request id. The client matches the id against a pending-callback registry.

This is what nREPL provides via sessions and ops, just reinvented at the TCP layer. It’s a fair amount of work for something nREPL gives you for free, which only strengthens my view that nREPL is the better protocol for editor tooling. Still, it was an interesting and educational exercise.

Zero dependencies

One thing I’m fairly proud of: Port has no hard dependencies. You’ll want either clojure-mode or clojure-ts-mode installed for the source-buffer side of things, but Port itself only soft-depends on them via runtime fboundp checks. Hook it onto whichever one(s) you actually use. I intend to keep it that way. Dependency creep is a real problem in the Emacs (every?) ecosystem, and a small package should stay small.

What’s there in 0.1

I tagged v0.1.0 yesterday. It’s small but already perfectly usable:

• M-x port “jacks in” (bootstraps) (auto-detects deps.edn / project.clj / bb.edn, starts a server and connects to it)
• single-buffer REPL with persistent input history, completion, and eldoc at the prompt
• interactive evaluation from source buffers with pretty-printed results
• structured stacktrace buffer with cause chain and navigable frames
• M-. find-definition that follows into jar sources
• doc/source/apropos/macroexpand helpers

MELPA submission is queued up next. After that, expect Port to be in burst-driven maintenance mode like most of my smaller projects.

Feedback, ideas, and contributions are most welcome. The issue tracker is the right place.

Closing thoughts

Funny thing, I’d never actually written any code against prepl until I started this project. It was fun to spend some quality time with the “competition” of my beloved nREPL. Working with a different protocol always teaches you something about the one you’re used to, and I came away from this with a renewed appreciation for both: prepl is genuinely elegant for what it is, and nREPL is genuinely well-designed for what we use it for.

Big thanks to Clojurists Together and everyone else who supports my OSS Clojure work. You rock! Now if you’ll excuse me, I have new releases of CIDER, clj-refactor, and refactor-nrepl to get back to.

Keep hacking!

I work on developing features and fixing bugs in the Linux kernel in areas specific to IBM Power. I use a number of Emacs’ facilities to get my work done.

Magit

I use Magit extensively with clones of various Git repositories from https://git.kernel.org/. I keep learning new (to me) things about git and Magit and using them. I’ve found it useful to learn how things work with the command line before attempting to use them in Magit.

Compilation

This work being with C source code, I make heavy use of M-x compile. I’ve made my life easier by preloading a couple of items in compile-history. I don’t need this everywhere, just in my Linux trees, so I put all of my Linux repositories under ~/linux, and there I’ve created a .dir-locals.el for directory local variables:

((nil . ((compile-history 
	  . 
	  ("nice make -k ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- -j `nproc` all compile_commands.json gtags"
	   "nice make -k ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- -j `nproc` tarzst-pkg"
	   )
	  )
	 )
      )
 )

I do my work on my x86_64 laptop, and cross compile for the powerpc architecture in 64-bit little endian mode. I take advantage of all of the threads available on my laptop. I use nice to make it a bit easier to interactive things while compiling.

The first history item does the big work. I build the all target to build the kernel and modules. I build compile_commands.json to capture the information needed by clangd to use with Eglot. I also keep gtags databases up-to-date, though I should probably drop that since I’m completely using Eglot with clangd at this point.

The second history item creates a .tar.zst file from the kernel and modules, which I transfer to the remote Power partition.

C mode and Eglot

I use c-ts-mode with Eglot. Eglot is integrated with xref.

TRAMP

My test systems are remote, so I need to transfer the kernel and modules over to it. I initially use TRAMP with the scp method to transfer the compressed tar file. If I rebuild and create a new package with the same name, I switch to the rsync method to transfer. This saves several seconds each time.

In both of these cases, I’ve set up keys so I do passwordless authentication.

Non-Emacs things on the remote system

Once I have the tar file on the remote system, there are some non-Emacs things to do. I’m almost certain I can do them in Emacs, as they’re just command line things, but I’m just not used to that and haven’t pushed myself to try it.

• untar the tarball in / (as root)
• run dracut to create an init ramdisk
• optionally remove older kernels and modules
• run grub2-mkconfig to add the new kernel to the GRUB menu
• copy the new grub config file to the right place
• reboot

Since I had no interesting books to read today, nor interesting films to watch, I decided to scavenge for the most intriguing content one can find online. I ended up reading the Linux kernel mailing lists, but those discussions seemed to be 18+, so I settled for the comparatively civil emacs-devel.

For those unfamiliar, emacs-devel is the primary development discussion list for GNU Emacs – where design decisions get made, patches get reviewed, and occasionally where people spend 200 messages arguing about version control software. This is the story of that last one.

2008: “This question is over and decided”

In March 2008, Emacs was migrating from CVS (yes, CVS) to something more “modern”. The two contenders were Git and Bazaar.

• Git, created by Linus Torvalds for the Linux kernel.
• Bazaar was a GNU project, maintained by Canonical

A 236-message thread erupted on emacs-devel. People benchmarked both tools. The results were not subtle. Andreas Schwab, one of the core developers, reported his first impression:

My first impression is that bzr is slow, so slow that it is completely unusable. How can it come that a simple bzr log takes more than a minute to even start? Even cvs log is instantaneous in comparison, although it has to request the log from the server.

David Kastrup found it equally puzzling:

I find this surprising: “git log” is pretty much instantaneous, and git recalculates a code piece’s history in the process. In contrast, one has to tell Bazaar when one copies or moves or renames files, so it should have the information available right away.

The actual numbers:

• git log | head -1 0.012 seconds. The same command with Bazaar took 21.5 seconds.
• Committing a single-file change: 0.08 seconds with Git, 17 seconds with Bazaar.

The benchmarks kept coming. Stefan Monnier, the head maintainer, set the bar low:

I don’t care if Bzr is slower or faster than Git, but in order to switch to Bzr, we need it to be ‘fast enough’. Currently it is not. At the very least the ‘bzr diff’ should not take more than a couple seconds.

Meanwhile, Jonathan Lange, an actual Bazaar developer from Canonical, was in the thread doing tech support.

His recommended workflow for the initial checkout:

An even better way to do the initial download is this:

$ wget http://bzr.notengoamigos.org/emacs.tar.gz

$ tar xzf emacs.tar.gz

$ bzr init-repo emacs-bzr

$ cd emacs-bzr

$ bzr branch ../emacs trunk

$ cd trunk

$ bzr pull –remember http://bzr.notengoamigos.org/emacs/trunk/

Compare that to git clone!

Someone in the thread finally asked the obvious question:

To the emacs maintainers and decision makers: What more information is required to convince bzr is not the right tool at the present moment?

Richard Stallman’s reply:

This decision is not a decision for the present moment. It is a long term decision. So it would be better to wait a few months while Bzr developers improve it, than to make some other “temporary” decision that would probably be hard to reverse.

And in case anyone missed the point, in a separate message:

This question is over and decided. We will use GNU Bzr, because it is a GNU package.

When someone pointed out that this political decision was “wiping away all technical arguments,” RMS replied:

The rule that GNU packages should support each other helps make the GNU system as a whole work better.

Someone asked the obvious follow-up: “Why can’t we just make Git part of the GNU system?”

RMS:

We could include it in the GNU system, but its developers are not likely to want to make it a GNU package.

To be fair to RMS, there’s a real principle here. If the GNU project doesn’t use its own tools, it sends a message that those tools aren’t good enough, which undermines the whole idea of a self-sufficient free software ecosystem. He’d been making this argument for decades, and it had served the project well in many other cases. The problem wasn’t the principle. The problem was that Bazaar couldn’t live up to it.

The 236-message thread, the benchmarks, the Canonical employee’s workarounds; none of it changed the outcome. The decision was political, and the politics were settled.

2008-2012: The long tail

The rest of the world moved to Git. GitHub launched in 2008 and exploded. Emacs contributors, meanwhile, had to learn Bazaar, a tool they used nowhere else, just to submit patches.

Threads like “Help me unstick my bzr, please” and “Can NOT bzr the emacs repos (may be bzr has a memory leak)” became regular occurrences.

Then in 2012, Canonical laid off the Bazaar development team.

2013

In March 2013, a year after Bazaar’s development ceased, John Wiegley posted what everyone had been wanting to say:

We have often debated the merits of Git vs. Bazaar, and which one the GNU project should use for Emacs development. I think now is an appropriate time to revisit this decision.

My main reason for bringing this up again is that Bazaar development has effectively stalled. There are major bugs which have been in their bug-tracker for years now – bugs affecting Emacs development, such as the ELPA repository – which have been ignored all this time.

So, to Richard as the undisputed Czar of all things Emacs: can we now, pretty please, switch to Git?

200 messages followed.

RMS’s first response:

The maintainer says he is fixing some bugs, and I asked him just yesterday to fix the ELPA branch bug. I’d like to give him a reasonable time to do this.

The bug was 1.5 years old. Dmitry Gutov called it out:

Isn’t this a bit late? The bug is 1.5 years old. Was he not aware of it before?

Then RMS revealed his hand:

I am trying to determine whether Bzr is effectively maintained or not. I’d rather get a Yes answer than a No answer.

That’s a remarkably honest thing to say publicly. He wasn’t hiding his preference. He genuinely believed in the principle of GNU projects supporting each other, and he was hoping reality would cooperate.

Joakim Verona, a longtime Bazaar user and Emacs contributor, described the reality on the ground:

I have done my best to be a constructive user of the tool, and I have had many technical difficulties. When I try to find solutions to the issues I notice the following:

• The bzr community is very helpful. This is good.
• There are many well known bugs. There are also many well known patches for these, some of them provided by Emacs developers. They never enter upstream. By “never” I mean years. This is bad.

RMS replied:

I don’t have time to read the Bzr mailing list. Or any development mailing list. The only such list I am on is this one. You might as well tell me to fly to the moon as tell me to read something on the Bzr list.

And when asked whether the users of Bazaar should have a say in whether Bazaar is sufficiently maintained:

When I have to decide whether a maintainer is doing an adequate job or needs to be replaced, I pay attention to whatever relevant information I get. However, to give users “a say” in the decision seems improper, so I don’t do that.

Karl Fogel, a veteran open source developer (author of Producing Open Source Software and one of the original Subversion developers), delivered the sharpest critique in the thread:

Well, really, you don’t have time to pay close enough attention to Bzr development to competently decide whether it’s still a good choice for Emacs. That’s fine – no one has time to do every important thing, and you do many other important things.

But then why do you think you still have the time & mental bandwidth to make this decision well? Why not delegate it to the Emacs maintainers on the grounds that you no longer have time to do a good job of this evaluation?

He pointed out that asking one person about one bug is not a proxy for project health, and that others in the thread had already done more thorough research than RMS could, given his time constraints.

RMS’s reply:

Because more than Emacs is at stake here.

One line, but it’s the core of his worldview. If the flagship GNU project abandons a GNU tool, what signal does that send to every other GNU package? He wasn’t wrong about the stakes. He was wrong about the tool.

Karl pushed once more:

You should either devote enough time to evaluating Bzr’s maintenance state to get a reliable answer, or delegate to someone who can do so. Instead, you’re asking the maintainers to rely on your investigation… yet you clearly don’t have time to do a good job. This is a poor use of everyone’s time.

RMS:

I already have a plan for how to proceed on this, and I am doing it.

No details. No timeline. No delegation. Trust me.

Meanwhile, Stefan Monnier, posted exactly one substantive message in the entire 200-message thread:

Just like I didn’t fight Richard’s choice of Bazaar, I don’t care very much whether we keep using Bazaar or we change to Git, Monotone, Darcs, Mercurial, OpenCM, Fossil, younameit.

The only thing I care for now is to move away from Bazaar for the ’elpa’ branch because Bazaar can’t handle it properly.

Leo Liu summarized what everyone was thinking:

Most GNU projects aren’t using BZR as you might be aware.

While helping BZR fixing bugs might be a gain for BZR, it is a loss as a whole for GNU. Volunteers spend their spare time on GNU projects and if 20% of that time is taken up by wrestling with BZR, it becomes costly to the point discouraging people from joining.

For the greater good of GNU, move off BZR seems like the only sound choice.

The thread ended without a clear resolution. RMS had a plan. He was working on it. The 200 messages didn’t produce a decision, but they did make the community’s position unmistakable.

2013: The ELPA branch breaks

Later that year, Stefan made the practical move that set the stage for everything that followed. The ELPA branch was broken on Bazaar, a bug that crashed on checkout, with no one left to fix it. Stefan moved it to Git, and his announcement showed exactly the kind of careful leadership that had kept Emacs development running through all of this:

I’m not terribly happy about this change, since it means we’ll be using two different tools (Git for ’elpa’ and Bzr for ’trunk’), but I really see no other way out.

I don’t want this to be a discussion about the merits/pitfalls of Git vs Bzr, and this is not an occasion to discuss the use of Git for the ’trunk’ either.

He knew exactly what everyone was thinking “if Git is good enough for ELPA, why not for trunk?” and he headed it off. One problem at a time.

2014: ESR pushes the button

By August 2014, Eric S. Raymond had the conversion scripts ready.

He’d been working on it quietly:

You haven’t heard much about it because the hard work is all done. I have the scripts ready to go and need only about eight hours’ notice before pushing the button.

The actual migration happened in November 2014. On November 13th, ESR posted a six-word message:

Commits are open. Have at it.

Which some even described as heroic.

Six years of debate, 236 messages in the 2008 thread, 200 messages in the 2013 thread, Stefan’s years of quiet maintenance, countless “help me unstick my bzr” pleas, one dead version control system, and it ended with six words.

The aftermath

The days following the migration were educational. Half the core contributors had never used Git:

• “This Is The Git Help Mailing List”
• “git pull fails with merge conflicts. How can this possibly happen?”
• “A simple git workflow for the rest of us”
• “need help adjusting workflow to git”
• “Good book on Git”
• “Obscure error/warning/information message from git pull” (124 messages)

These were people who’d been developing one of the most important text editors in the world for years, asking basic Git questions, because they’d been stuck on Bazaar while the rest of the world moved on.

What a bzr saga! Anyway, better than any film I could have watched tonight.

As celebrated as Emacs is for its programmability, I find the actual process of developing Emacs Lisp (Elisp) to be quite underwhelming. Developing in Elisp has meant learning its libraries and idioms, which is to be expected. What I really don’t care for though are the arcane keybindings associated with doing basic things like evaluating, navigating (Xref), and debugging (especially debugging). While I’ve already committed to muscle memory most of said keybindings, I’d argue that having a mouse-based “point and click” interface is beneficial for both novice and experienced Elisp developers alike, as it lets one focus on the code and not on recalling the right key incantation all the time.

The addition of context-menu-mode in Emacs 28 has provided the opportunity to build a mouse-based UI for Elisp development and I’m happy to announce the availability of one in the latest v1.3.0 update to Anju, now on MELPA.

To get an idea of what’s available in the v1.3.0 update, here’s a screenshot of the context menu when normally editing an Elisp file where the point is on the symbol foo.

If foo is instrumented for debugging and run, the context menu is adjusted to provide Edebug commands as shown below.

The context menu enhancements provided by Anju take full advantage of built-in functions that identify context at point. Is the point on a symbol? In a function? In an ERT test? On a lambda? The menu items added by Anju take these factors into account to provide a relevant menu offering.

Users can read more about Anju’s context menu enhancements for Elisp development at Emacs Lisp Context Menu (Anju User Guide).

Some backstory with Edebug

Back in 2024, I did a deep dive into Edebug so as to give a presentation on it at the EmacsSF meetup. In doing so, I realized that all the core features for having an Elisp IDE were there, but no good UI to present it. I set upon prototyping one using Transient, with decidedly mixed results due to both Edebug and Transient fighting each other over window management.

A later Edebug UI prototype using the toolbar was attempted but it also had its issues, particularly with layout (or lack thereof) and toolbar-specific bugs in macOS. But a benefit of using the toolbar was that its UI interactions did not interfere with window management. The context menu also shares this benefit.

Closing Thoughts

The context menu has markedly improved my developer experience with Elisp, as I find myself using it more than typing out keybindings. Even with keybindings, I’ll use the Casual Elisp Transient to accomplish most Elisp interactions that don’t require Edebug.

That said, I’m not here to eschew keybindings. I still use them, when convenient. But in many circumstances they are not. The context menu can provide an easier way to achieve the same thing. Isn’t that a good thing?

I’ve been using ICanHazShortcut for years. I originally started using it to have an easy way to switch to Emacs from anywhere in my system. Eventually, I added Safari and HomeKit to the list of apps I can invoke with a simple keypress but most of my ICanHazShortcut shortcuts are Emacs related. For example, I have F9 mapped to Emacs capture so that I can invoke any Org capture template from anywhere on my system. That’s really handy and I use it several times a day. I also have a shortcut to invoke Emacs Everywhere so that I can escape into the comfort of Emacs when entering data in some other app.

Today (Sunday, as I write this) I received a notification that a new version of ICanHazShortcut was available. It’s completely rewritten in Swift from Basic and has some new capabilities. You can read about them at the above link. For me, not much has changed. The new version continues doing what ICanHazShortcut has always done.

ICanHazShortcut is a minimal app that simply provides a shortcut for any command that you can specify in the terminal. There are plenty of more full featured key mappers available that may be better for more complicated situations but I find ICanHazShortcut perfect. It’s light weight and easy to configure. I almost never mess with ICanHazShortcut’s configuration. The last time I changed it—to add HomeKit, I think—was years ago. It truly is a set it and forget it app.

If you want a simple app for invoking Emacs—or anything else—in various ways, take a look at ICanHazShortcut; it’s worked very well for me.

People are getting Emacs 31 ready for release. Looking forward to that! See emacs/etc/NEWS.31 for details.

Lots of posts for the Emacs Carnival theme of "May I recommend…", yay!

• Emacs 31:
  • The emacs-31 branch has been created! (Irreal)
  • openSUSE package for emacs-31 (@thaodan)
• Upcoming events (iCal file, Org):
  • London Emacs (in person): Emacs London meetup https://www.meetup.com/london-emacs-hacking/events/314540885/ Tue May 12 1800 Europe/London
  • Emacs Berlin: In-Person-Only Emacs-Berlin Stammtisch https://emacs-berlin.org/ Tue May 12 1900 Europe/Berlin
  • OrgMeetup (virtual) https://orgmode.org/worg/orgmeetup.html Wed May 13 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1800 Europe/Berlin - 2130 Asia/Kolkata – Thu May 14 0000 Asia/Singapore
  • M-x Research: TBA https://m-x-research.github.io/ Wed May 20 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/GMT - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
  • Emacs APAC: Emacs APAC meetup (virtual) https://emacs-apac.gitlab.io/announcements/ Sat May 23 0130 America/Vancouver - 0330 America/Chicago - 0430 America/Toronto - 0830 Etc/GMT - 1030 Europe/Berlin - 1400 Asia/Kolkata - 1630 Asia/Singapore
• Emacs configuration:
  • Marcin Borkowski: describe-personal-keybindings (Irreal)
  • My Dotfiles: macOS Bootstrap and an Emacs Distribution (Reddit)
  • Backpack Emacs hits version 0.5
• Emacs Lisp:
  • Amin Bandali: FFS code review with Protesilaos (Prot)
  • The Emacs's Gamegrid library #1, #2, #3, #4
• Appearance:
  • Recent Commits to emacs:master: Introduce 'margin' face for window margin background
  • Emacs theme that looks like v0.10+ Neovim's default dark theme (Reddit)
• Navigation:
  • TAGS, Etags and system headers
  • Emacs: writing a project.el backend
  • Emacs Buffer Comparison Made Easy With Ebuffers 2026 05 10 02:31:35 (05:31)
  • LIVE: bribing myself to work on async Rust TCP connections (02:35:52, Emacs navigation chapter at 2:00:15)
• TRAMP:
  • Notes on using GNU Emacs' Tramp system in an unusual shell environment (lobste.rs)
• Dired:
  • James Dyer: A Zoomed in vc dir for the Current Directory in dired
• Writing:
  • markdown-ts-mode got a major overhaul and is now part of Emacs 31
  • Dave Pearson: blogmore.el v4.5.0 - add blogmore-set-as-cover
    • v4.4.0 - blogmore-become-like
  • jw.el: Just Write, a microjournaling tool (uses external binary) (@liberty@mathstodon.xyz)
• Denote:
  • Organising Series with denote-sequence — Alex Carney (@alcarney)
• Org Mode:
  • Org Mode requests: [FR] ox-md: Export custom-id search strings (::#) as anchors
  • grove.el - an Obsidian-like note-taking mode for Emacs (r/emacs, r/orgmode, Irreal, HN, HN)
  • mon workflow emacs (18:31)
  • Spacemacs | Org-mode Table Spreadsheet Formula | Productivité (05:19)
  • Import, export, and integration:
    • Tiny package for org links which base64 embed files into HTML export for sharing (Reddit)
    • Note about needing to escape things in Org macros (@pabryan@mathstodon.xyz)
    • LuaLaTex y fontspec (Orgmode) - FediverseTV (@emacs_org@fediverse.tv)
    • Config for using multiple org-publish projects (@yugaego@fosstodon.org)
    • Blog-Umzug? | Jan Iversen (@razorback@nerdculture.de)
    • sync.el - sync Org files with git automatically (Reddit)
    • Andros Fenollosa: twtxt vs Org Social: the evolution of an idea
    • Descubriendo la red Org-social - FediverseTV (@emacs_org@fediverse.tv)
  • Org development:
    • ox-latex.el: New variable org-latex-descriptive-environment
    • ob-tangle: Make tangling from archived trees optional
• Completion:
  • Emacs Completion Showcase with VOMPECCC (video) (YouTube 01:08:43, Reddit, HN, lobste.rs)
  • Follow-up: vertico-buffer-frame, a child-frame experiment for vertico-buffer (Reddit)
  • fzf-async (Reddit)
  • Yuta.el: native fuzzy finder, Lsp Completion, and command palette for Emacs (uses external CLI tools) (Reddit)
• Coding:
  • My Doom Emacs setup for Rust development in less than two minutes (01:36)
  • emacs-forgejo | Thanos Apollo (@csantosb@sigmoid.social)
  • hprpl-mode for the HP-48G
  • Finally go-to-definition w/ Eglot on JVM languages (Kotlin and Java)! do you know how to improve it?
  • Using our new Lua debbuger: LuaProbe, we made an Emacs package for it (Reddit)
  • Configurando o Windows para Programar Jogos em C | Indie Game Dev (48:38)
  • Sweep: SWI-Prolog Embedded in Emacs (@PuercoPop)
  • jao: geiser moved to codeberg - Scheme interfaces
• Math:
  • The Simple Emacs Spreadsheet
• Shells:
  • Toggle an Emacs terminal with a single keystroke using shell-pop (Recently Refactored) (Reddit)
  • Just a quick "Eat" survey
  • termit: Terminal emulator for Emacs (@hajovonta@mastodon.online)
• Web:
  • Einar Mostad: Speed improvement hack for dired with EWW - browse-url-handlers
• Mail, news, and chat:
  • What improvements would you like to see in elfeed? (@minad@mastodon.world)
  • Add elfeed-tree-mode · emacs-elfeed/elfeed@072a609 · GitHub (@minad@mastodon.world)
• Multimedia:
  • contrapunctus/sxiv.el: Launch (n)sxiv ((Neo) Simple X Image Viewer) (@contrapunctus@fe.disroot.org)
• AI:
  • I made elisp-quality-ai: AI-friendly quality reports for Emacs Lisp projects
  • Emacs with Org-Mode and Claude for Apple MacBook (HN)
  • ox-skills: manage AI agent skills in Org-mode (Reddit)
  • display-buffer-alist config for claude-code (@cyberwolf@infosec.town)
• Community:
  • Fortnightly Tips, Tricks, and Questions — 2026-05-05 / week 18
  • Sacha Chua: Emacs Carnival May 2026: "May I recommend…"
    • May Emacs Carnival: Carlos Pajuelo
    • May I Recommend EWM | Dilip's Log
    • Sacha Chua: From David Dimagid: What we talk about when we talk about recommending Emacs packages
    • May I recommend… escaping the minibuffer (@vanni@mibl.vannilla.org)
    • May I recommend… vibemacsing? | Giampaolo Guiducci (@gosub@fosstodon.org)
    • May I recommend… to only add items to your init files you understand and document? Martin Stemplinger
    • Curtis McHale: Emacs Carnival: May I recommend…
  • Amin Bandali: Emacs Chat with Sacha Chua (YouTube 01:12:31, Irreal, Sacha)
  • Sacha Chua: Emacs Chat 22: Shae Erisson (YouTube, 01:02:36)
  • I just dont get it… - long discussion about Emacs Lisp and customization
  • Emacs ATX Meetup. May 2026. GNU Hyperbole. (01:44:31)
  • Thread about what makes Emacs easy for you (@chiply@fosstodon.org)
  • Kent Pitman, Ramin Honary, Screwlisp #climate #emacs autocomplete #lisp #unix_surrealism #logic #lispyGopherClimate - toobnix (@screwlisp@gamerplus.org)
  • Curtis McHale: The gravitational pull of familiar tools
• Other:
  • veer66/ya-sort-lines: Yet-another sort lines - Codeberg.org (@veer66@mstdn.io)
  • jamesendreshowell/ramb: Emacs package Really Actually Make Backups - Codeberg.org (@jameshowell@fediscience.org)
  • Protesilaos: Emacs: save any buffer as PDF (my new buffer-to-pdf package)
  • Corwin Brust: last-rev.pl - find the most recent commit to each Emacs branch (or other Savannah projects)
  • James Cherti: A Technical Guide for Compiling Emacs and its Packages for Maximum Performance on UNIX or GNU/Linux systems
  • Protesilaos: Re: Emacs and keyboard ergonomics (Irreal)
• Emacs development:
  • emacs-devel: Re: Tail recursion - Lynn Winebarger - emacs-31 probably not going to have igc
  • New variable 'completion-frontend-properties' (bug#80990)
  • Bump master Emacs version to 32.0.50
  • Introduce 'margin' face for window margin background
  • nadvice.el: Make it easier to find how to change an interactive-form
  • keyboard.c: Allow SIGINT to `quit` in batch mode, instead of exit
• New packages:
  • apple-container-tramp: TRAMP integration for apple container (MELPA)
  • claude-code-context: Share buffer context with Claude Code (MELPA)
  • folgezett: Folgezettel IDs for org-roam (MELPA)
  • gnus-browse-url-in-article: Smarter browse-url for Gnus articles (MELPA)
  • har-viewer: Major mode for viewing HTTP Archive (HAR) files (MELPA)
  • indigo: Emacs interface to the Indigo cheminformatics library (MELPA)
  • nucleo-completion: Nucleo-backed completion style (MELPA)
  • shannon-max: Analyze your keybindings with information theory (MELPA)
  • verdict-dart: Dart runner for verdict (MELPA)

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!

You can e-mail me at sacha@sachachua.com.

Most Linux distributions ship generic binaries compiled to run safely on a vast array of older hardware configurations. While this ensures broad compatibility, it sacrifices the speed that comes from using the specific, modern instruction sets of your processor. Building Emacs directly from source allows instructing the compiler to generate machine code targeted at your CPU architecture, resulting in a faster and more efficient runtime environment.

Before we dive in, please consider sharing this article on your website, blog, Mastodon, Reddit, X, Linkedin, or other social media platforms. Sharing it will help other Emacs users discover how to properly build Emacs for performance.

Beyond raw hardware optimization, building from source enables dropping decades of legacy compatibility layers and embracing modern desktop technologies. For example, Wayland users can configure the build to bypass old X11 display protocols in favor of a Wayland environment, ensuring smoother rendering and better system integration.

Additionally, this article details how to optimize the internal native Lisp compiler, which transforms Lisp packages into machine code to ensure that every Emacs package in your configuration operates at its maximum potential speed.

Here is the step-by-step process for building a highly optimized Emacs binary and packages.

Installing dependencies

Arch Linux

On Arch Linux, the cleanest and most native method to resolve build dependencies is to use the official Emacs PKGBUILD, which automatically read the official dependency list and install them:

mkdir -p ~/emacs-deps
cd ~/emacs-deps
wget https://gitlab.archlinux.org/archlinux/packaging/packages/emacs/-/raw/main/PKGBUILD
makepkg --syncdeps --nobuild

NOTE: Once makepkg finishes installing the dependencies, you can safely delete the ~/emacs-deps directory.

Debian, Mint and Ubuntu

On Debian-based systems, the most efficient method to gather dependencies is to use the package manager to automatically fetch them based on the distribution’s source package. You must first ensure that source repositories are enabled:

• Open /etc/apt/sources.list with root privileges in your text editor.
• Find the lines starting with deb-src (Read: “sources.list format” on Debian Wiki) and uncomment them by removing the # at the beginning of the line.
• Update your package lists and download the install Emacs dependencies:

sudo apt update
sudo apt build-dep emacs

Other Linux Distributions (Generic)

If you are using a distribution not listed above, you will need to use your distribution’s specific package manager to install the required development libraries. Look for packages that include the library headers, typically suffixed with -dev or -devel.

Here is the master list of upstream library names required to compile this specific Wayland and Native-Comp optimized build:

• Core Build Tools: gcc, make, autoconf, automake, pkg-config (or pkgconf), git, texinfo
• Native Compilation Engine: libgccjit (Ensure this matches your GCC version)
• System and Core Libraries: glib2, gnutls, zlib, ncurses, sqlite3, tree-sitter, gmp
• Graphics and Wayland Toolkit (PGTK): gtk3, cairo, harfbuzz, pango, dbus
• Image Formats: libjpeg (or libjpeg-turbo), libpng, libtiff, giflib, libwebp, librsvg2, lcms2
• Fonts and Text Shaping: fontconfig, freetype2, libotf, m17n-lib, libxml2

Optimizing the Native Lisp Compiler

Fine-Tuning Native Compilation

Before building Emacs with native compilation support, we will optimize how Emacs transforms Lisp packages into machine code. This is managed via the native-comp-compiler-options variable. While the main Emacs build uses your global CFLAGS, this variable specifically instructs libgccjit on how to handle every .el file it encounters.

Add the following to your early-init.el file:

;; Display the architecture using:
;;   gcc -march=native -Q --help=target | grep march
;;
;; The above command asks the compiler to resolve native for your current CPU
;; and display the resulting target. For example, if the output shows
;; -march=skylake, you know that skylake is the identifier you should pass to
;; -mtune and -march.
(setq my-cpu-architecture "CHANGE_THIS_TO_YOUR_ARCHITECTURE")

;; `native-comp-compiler-options' specifies flags passed directly to the C
;; compiler (for example, GCC) when compiling the Lisp-to-C output
;; produced by the native compilation process. These flags affect code
;; generation, optimization, and debugging information.
(setq native-comp-compiler-options `(;; The most meaningful optimizations:
                                     "-O2"
                                     ,(format "-mtune=%s" my-cpu-architecture)
                                     ,(format "-march=%s" my-cpu-architecture)
                                     ;; Reduce .eln size and compilation
                                     ;; overhead.
                                     "-g0"
                                     ;; Good defensive choice for Emacs
                                     ;; stability.
                                     "-fno-omit-frame-pointer"
                                     "-fno-finite-math-only"))

(setq native-comp-driver-options '(;; -Wl,-z,pack-relative-relocs compresses
                                   ;; relocation tables to reduce file size and
                                   ;; slightly improve load times.
                                   "-Wl,-z,pack-relative-relocs"
                                   ;; -Wl,-O2 applies standard linker-level
                                   ;; optimizations (like string merging) to the
                                   ;; generated shared object.
                                   "-Wl,-O2"
                                   ;; -Wl,--as-needed prevents the linker from
                                   ;; recording dependencies on libraries that
                                   ;; are not actually used by the code.
                                   "-Wl,--as-needed"))

IMPORTANT: Change CHANGE_THIS_TO_YOUR_ARCHITECTURE to your specific architecture. Run the following command to display the CPU architecture:

gcc -march=native -Q --help=target | grep march

The above command asks the compiler to resolve native for your current CPU and display the resulting target. For example, if the output shows -march=skylake, then replace CHANGE_THIS_TO_YOUR_ARCHITECTURE with skylake.

(If you prefer automatic CPU architecture detection, refer to the comments section below. I shared a function that detects the CPU architecture using gcc and adds it to the configuration.)

NOTE: Avoid adding -mtune=native and/or -march=native to the native-comp-compiler-options variable. While these flags work in global CFLAGS, libgccjit, the library responsible for native compilation, often fails to resolve the native keyword correctly. This happens because the JIT interface does not always trigger the same host-probing logic as the standalone GCC driver.

The rationale behind the selection of these flags is as follows

• The choice of -O2 is an intentional balance. While -O3 may provide small performance gains in some workloads, it can also increase binary size and occasionally reduce responsiveness. -Ofast is generally discouraged because it enables aggressive floating-point optimizations.
• Using -g0 disables the generation of debug symbols for .eln files, which reduces their size on disk and speeds up the compilation process itself.
• -fno-omit-frame-pointer The Emacs developers recommend using this flag to disable omit-frame-pointer. Although enabling omit-frame-pointer frees up a general-purpose CPU register, it does not yield significant performance gains on modern architectures and can lead to bugs that are difficult to debug. According to Eli Zaretskii, an Emacs developer: “See bug#76180. This is in the context of the igc branch, where omit-frame-pointer is particularly troublesome, though it also causes problems in other situations. For further details, see etc/DEBUG in the Emacs source tree.”
• The -fno-finite-math-only flag prevents the compiler from assuming that floating-point operations never produce NaN or infinity values. This flag is mostly defensive because GCC does not enable -ffinite-math-only at -O2 by default, but it can help avoid unsafe assumptions if additional aggressive optimization flags are introduced later.

For users looking to ensure a fully optimized environment, the compile-angel package is a valuable addition to the native compilation workflow. Integrating compile-angel guarantees that every .el file in your load path, including your own configuration and manually managed .el files, is properly byte and natively compiled. This ensures a consistent performance boost across the entire editor.

Purging the Native Cache to Force JIT Recompilation

After modifying the native-comp-compiler-options and/or native-comp-driver-options variables, you must force Emacs to rebuild your packages. Ensure Emacs is closed and delete all existing .eln binaries using the following command:

find ~/.emacs.d/ -name '*.eln' -delete

Because Emacs uses a deferred compilation engine (Native JIT compiler), you do not need to manually trigger a build script. Simply launch Emacs and begin your normal workflow. As Emacs loads your packages and detects the missing .eln files, it will spin up background threads to recompile them using your new optimization flags.

Compiling Emacs for Performance

Step 1: Cloning and Preparing the Source

To build Emacs, you must first obtain the source code from the official mirror and switch to a stable release branch:

git clone https://github.com/emacs-mirror/emacs
cd emacs
git checkout "emacs-30.2"

NOTE: The official Savannah Git repository at https://git.savannah.gnu.org/git/emacs.git can occasionally be slow or unreliable, so this guide uses the official GitHub mirror instead.

We target a specific release tag like emacs-30.2 (If you desire to install another version, you can display tags using the git tag command) to ensure a stable foundation. Building from a tagged release, rather than the bleeding-edge development branch like the master branch, minimizes the risk of build failures or experimental regressions that could impact your daily productivity.

Standard cleanup is often insufficient when switching branches or recovering from a failed build. Execute the following commands to ensure a pristine environment where no residual artifacts can interfere with the new build:

git reset --hard HEAD
git clean -f -d -x
rm -fr .git/hooks/*

(Executing these commands acts as the ultimate factory reset for your repository, which is important when switching between major Emacs versions. Emacs has a highly complex build process where the C core compiles its own Lisp files; if leftover artifacts from a previous configuration, such as cached object files, old Makefiles, or stale byte-compiled .elc scripts, git hooks, are left behind, they can silently contaminate the new build and cause segmentation faults or compile-time errors. Together, these commands guarantee a pristine, predictable environment.)

Once inside the repository, all subsequent configuration and compilation commands are executed from this directory.

Step 2: Generating the Configuration Script

Emacs uses the Autotools build system, which requires generating the final configuration script before it can be used:

./autogen.sh

This shell script reads the developer configuration files provided in the repository and generates the final ./configure script. It sets up the necessary infrastructure to inspect your specific environment, locate system libraries, and prepare the Makefile.

Step 3: Setting Compiler and Linker Flags

To enhance runtime performance, we must export specific variables that instruct the C compiler and linker to optimize the resulting binary for the host CPU:

export CFLAGS="-O2 -pipe -march=native -mtune=native -fno-omit-frame-pointer -fno-plt -flto=auto"
export LDFLAGS="-Wl,-O2 -Wl,-z,now -Wl,-z,relro -Wl,--sort-common -Wl,--as-needed -Wl,-z,pack-relative-relocs -flto=auto -O2"

The CFLAGS variable tells the compiler to apply safe, general-purpose optimizations (-O2), optimize instruction scheduling for the specific CPU compiling the code (-march=native and -mtune=native), store the metadata necessary for the linker to later perform cross-module optimization (-flto=auto), disable omit-frame-pointer (-fno-omit-frame-pointer), use memory pipes instead of temporary files to speed up the build (-pipe), and remove indirect PLT calls to external functions, improving runtime call efficiency at the cost of slightly higher startup and dynamic loading overhead (-fno-plt).

The LDFLAGS variable instructs the linker to apply additional optimization passes to the final executable (-Wl,-O2), group common symbols to reduce duplicate storage (-Wl,--sort-common), avoid linking unused shared libraries (-Wl,--as-needed), reduces binary size by performing a global analysis to inline functions and remove dead code across the entire program (-flto=auto), compress relative relocations to reduce relocation overhead and binary size (-Wl,-z,pack-relative-relocs), resolve all dynamic symbols at startup, trading slightly slower launch time for faster, more consistent runtime execution (-Wl,-z,now -Wl,-z,relro). Together, these flags help produce a smaller, more memory-efficient executable with improved startup and runtime performance.

NOTE 1: To successfully build Emacs using Link-Time Optimization (LTO) -flto, It is recommended to maintain a consistent optimization level, such as -O2, across both the compilation (CFLAGS) and linking stages (LDFLAGS). When enabling -flto=auto in your CFLAGS, the compiler emits GIMPLE intermediate representation; the actual transformation into an optimized executable is deferred until the linking phase, where the GCC driver re-invokes internal optimization passes. While modern GCC versions can often infer the correct heuristics from metadata embedded within the object files if a link-time flag is missing, explicitly including -O2 in your LDFLAGS is recommended for a predictable, deterministic build. This practice ensures that the whole-program analysis phase executes the exact same optimization level as the initial compilation. (Source: “To use the link-time optimizer, -flto and optimization options should be specified at compile time and during the final link. It is recommended that you compile all the files participating in the same link with the same options and also specify those options at link time…”)

NOTE 2: You must ensure CC are exported to the exact gcc version that matches your libgccjit version. For example: export CC="/usr/bin/gcc-11".

Step 4: Configuring the Build

We run the configure script to select exactly which features to include.

For X11 users:

./configure \
  --with-x \
  --with-x-toolkit=gtk3 \
  --without-toolkit-scroll-bars \
  --with-cairo \
  --without-xft \
  --with-harfbuzz \
  --without-libotf \
  --with-gnutls \
  --without-xdbe \
  --without-xim \
  --without-gpm \
  --disable-gc-mark-trace \
  --enable-link-time-optimization \
  --with-gsettings \
  --with-modules \
  --with-threads \
  --with-libgmp \
  --with-xml2 \
  --with-tree-sitter \
  --with-zlib \
  --without-included-regex \
  --with-native-compilation \
  --with-file-notification=inotify \
  --without-compress-install

For Wayland users:

./configure \
  --without-x \
  --with-pgtk \
  --with-toolkit-scroll-bars \
  --with-cairo \
  --without-xft \
  --with-harfbuzz \
  --without-libotf \
  --with-gnutls \
  --without-xdbe \
  --without-xim \
  --without-gpm \
  --disable-gc-mark-trace \
  --enable-link-time-optimization \
  --with-gsettings \
  --with-modules \
  --with-threads \
  --with-libgmp \
  --with-xml2 \
  --with-tree-sitter \
  --with-zlib \
  --without-included-regex \
  --with-native-compilation \
  --with-file-notification=inotify \
  --without-compress-install

The rationale behind the selection of these flags is as follows

• --enable-link-time-optimization Instructs the build system to natively apply link-time optimization. This ensures the Emacs build scripts coordinate the optimization properly across all compiled object files to produce the fastest possible executable. When you pass this to ./configure, the build system actively probes your environment. If you look at the configure.ac script, you will see it attempts to find the number of available CPU cores. It then automatically injects -flto=N (where N is your core count) into the build flags. More importantly, this flag ensures that archiving tools like ar and ranlib are configured to use the correct LTO plugins.
• --disable-gc-mark-trace: Disable the GC mark trace buffer for about 5% better garbage collection performance. It removes debugging code from the garbage collector marking phase. This provides a reduction in overhead during garbage collection cycles, leading to a more responsive experience during memory-intensive tasks.
• --with-native-compilation Enable native compilation. (I omitted the aot flag to instruct the build system to skip compiling the built-in Lisp files during the make step. Instead, Emacs defers this work until runtime, where it will use the optimizations in native-comp-compiler-options and native-comp-driver-options while compiling all .el files the first time Emacs is launched.)
• --with-cairo and --with-harfbuzz enable modern text rendering.
• --without-compress-install By default, Emacs compresses its installed Lisp files to save disk space. Using this flag keeps the files uncompressed. The benefit is faster load times when Emacs needs to read these files from disk, as it skips the decompression step entirely. (On modern SSDs, loading compressed .el.gz files generally takes a bit more time than loading uncompressed files. While compression definitely saved time on older spinning hard drives by reducing I/O waits, modern solid-state drives can read uncompressed data at gigabytes per second. That being said, the actual performance gain of using uncompressed files is often negligible in practice. This is especially true if you are compiling all your .el files, because Emacs prefers to load the compiled byte-code .elc or native code .eln)
• --without-xft Disable xft because modern Emacs rendering no longer needs it. Modern GTK builds of Emacs use Cairo + HarfBuzz handle rendering.
• --without-included-regex Makes Emacs use the system libc regex implementation. On contemporary Linux systems using glibc, the system regex engine is usually better optimized and maintained than Emacs’s bundled GNU regex implementation.
• --with-libgmp Enables GMP, the GNU Multiple Precision Arithmetic Library, an optimized engine Emacs relies on to calculate arbitrary-precision integers (bignums) at bare-metal speeds. Modern Emacs workflows constantly process massive numbers in the background. If you disable this flag or fail to install the system library, Emacs is forced to fall back on mini-gmp, a generic, software-only C implementation designed strictly for portability rather than speed.
• --without-xim: Disable XIM, a legacy X Input Method protocol used primarily for typing complex languages (like Chinese, Japanese, or Korean) on old X11 systems. If you use GTK3/Wayland, modern input methods handle this instead. Disabling this is recommended for Wayland/PGTK users as it removes unnecessary X11-specific code.
• --with-file-notification=inotify Guarantees that the build will use the Linux kernel’s efficient event-watching API rather than falling back to slow, resource-heavy polling if the detection fails.
• --with-gsettings Enable communication with the GTK configuration storage system. This allows inheriting system-wide preferences for themes, fonts, antialiasing hints…
• --without-libotf: Disables the legacy OpenType Font library. This is recommended for modern builds that use HarfBuzz (--with-harfbuzz), as HarfBuzz handles text shaping more efficiently. Disabling this library reduces binary size without sacrificing font quality in modern desktop environments.
• --with-gnutls: Enables secure network communication. This is required for secure package installation from MELPA/ELPA and for browsing HTTPS websites via EWW.
• --without-xdbe: Disables the X11 Double Buffer Extension. This protocol is redundant for modern builds because both the PGTK (Wayland) and GTK3 (X11) layers handle window buffering internally. Disabling it simplifies the binary and ensures Emacs uses modern rendering paths.
• --without-gpm Disable General Purpose Mouse (GPM), a background service that provides mouse support for the Linux console (the text-only TTY you see before logging into a graphical desktop). Unless you plan to use Emacs in a bare-metal Linux console (outside of a terminal emulator like Alacritty, Foot, or GNOME Terminal), GPM is unnecessary. Modern terminal emulators use their own internal protocols for mouse interaction that do not rely on the GPM daemon.

Additional flags to pass to ./configure

If your workflow is primarily text-based, you can significantly reduce the number of external libraries linked to your binary. However, each omission comes with a specific trade-off:

• --without-sound Disables support for audio notifications. You will not hear the audible system bell or sound cues from productivity packages like Pomodoro timers or chat clients.
• --without-libsystemd Disables the ability for Emacs to communicate with systemd. You cannot use advanced systemd service features, such as Type=notify, which allows systemd to know exactly when the Emacs daemon is fully loaded and ready.
• --without-dbus: Disables D-Bus integration in Emacs. This produces a slightly leaner build, but removes integration with desktop services that rely on D-Bus. Depending on the desktop environment and enabled packages, this can affect desktop notifications, interaction with services such as GNOME Keyring, file manager integration, power and network state notifications, and various portal-based desktop features. It is generally safe on minimal Emacs GUI builds or terminal-only setups, but many modern Linux desktop environments expect D-Bus support.
• --without-gconf Disables support for GConf. This is a deprecated GNOME configuration system that was replaced by GSettings. Disabling it ensures your build is not carrying legacy, obsolete desktop integrations.
• --without-sqlite3 Disables the built-in SQLite engine. This breaks modern packages that rely on a local database for performance, such as org-roam or certain mail indexers.
• --without-m17n-flt Disables the m17n library for complex text layout. While fine for English-only workflows, this will cause rendering issues (incorrect character joining or positioning) for complex scripts like Indic or Thai.
• --without-selinux Disables Security-Enhanced Linux support. On systems where SELinux is active, Emacs will be unable to preserve or manage SELinux security contexts when creating or copying files, potentially leading to permission issues or security policy violations.
• --without-libsmack Disables Smack security support. Similar to SELinux, if your Linux distribution uses the Smack kernel security module, disabling this prevents Emacs from managing those specific security contexts on files.
• --disable-build-details: Omits build metadata, such as your machine’s hostname and the compilation timestamp, from the final executable. While this doesn’t provides performance or startup speed benefits, it ensures a “reproducible build” and prevents your personal system details from leaking if you share your compiled binary.
• --without-gif, --without-jpeg, --without-png, --without-rsvg, --without-tiff, --without-xpm, --without-webp Disabling these prevents Emacs from linking against heavy image processing libraries. Emacs will be unable to render these image formats natively. This breaks functionality for image-heavy modes, such as image-mode, viewing PDFs via pdf-tools, or displaying mathematical LaTeX previews.
• --without-imagemagick Prevent Emacs from using this large dependency for complex image transformations. You lose the ability to perform advanced image manipulation (like dynamic resizing or rotation of certain formats) within Emacs buffers.
• --without-lcms2 Remove the Little CMS color management layer. Images may appear with slightly incorrect colors on high-quality displays, as Emacs will ignore ICC color profiles embedded in files.
• --without-xinput2: Disables the modern X11 input extension. Warning: If you are building for X11, disabling this will break pixel-precision smooth scrolling for trackpads and mouse wheels, forcing Emacs to use choppy line-by-line scrolling. This flag does nothing for Wayland/PGTK builds and offers no performance benefits.
• --disable-acl: Disables support for Access Control Lists. Disabling this reduces the number of system calls Emacs performs during file operations. This is a good choice for single-user systems where standard Unix permissions are sufficient.
• --disable-xattr: Disables support for Extended File Attributes. Only keep this enabled if you rely on SELinux or filesystem-level file tagging.
• --without-kerberos --without-pop --without-kerberos5 --without-hesiod --without-mail-unlink: These flags disable support for ancient mail retrieval methods, directory services, and local mail spool manipulation. Because modern Emacs mail setups rely on external synchronization, disabling these ensures the build script does not waste time searching for legacy network libraries and keeps the binary entirely free of dead mail code.

Step 5: Compiling the Source Code

With the configuration complete, the next step is to compile the C source files and the core Emacs Lisp files:

make -j "$(nproc)" -l "$(nproc --ignore=1)"

• -j $(nproc): This sets the maximum number of concurrent jobs to the number of CPU cores. Make will attempt to run up to the the number of CPU cores compilation commands in parallel. This is an upper bound; actual concurrency may be lower depending on dependencies and system load.
• -l $(nproc --ignore=1): This sets a load average limit. $(nproc --ignore=1) returns the number of available CPU cores minus 1. Example: on an 8-core system, this evaluates to 7. So effectively, -l 7 means: do not start new jobs if system load average is 7 or higher. Make uses system load average (typically 1-minute load average) as a throttling mechanism.

On a low-load system, Make may run close to 48 jobs in parallel. Under high CPU pressure, Make will throttle and pause scheduling new jobs until load decreases.

(Related article: Similar to make -j command above for Emacs compilation, read “Enabling Emacs native compilation and dynamically adjusting the number of Elisp files compiled in parallel“)

Step 6: Installing the Stripped Binary

The final step is to copy the compiled binary and its associated files to their proper locations on your file system.

sudo make install-strip

While the standard make install simply copies the compiled files, make install-strip performs an additional optimization. It strips debugging symbols from the final executable. Removing these symbols reduces reduces binary size on disk.

Verifying Emacs Build Features

After successfully compiling Emacs from source, execute the resulting Emacs binary.

Once the editor is running, it is good practice to verify that your desired features, such as native JSON parsing or tree-sitter support, were correctly detected and linked during the build process.

You can verify this by inspecting the system-configuration-features variable. To view its contents, type M-x describe-variable RET system-configuration-features RET, which will output a string detailing the exact libraries and features baked into your current executable.

Optional: Risky Emacs Optimizations

Risky Optimization: Replacing -O2 with -O3

NOTE: The Emacs developers strongly recommend against using -O3, -Os, and -fsanitize=undefined for ordinary production builds, stating that these flags are known to sometimes cause unpredictable problems with the generated code. (Source: The INSTALL file in the Emacs source tree.) That said, I have compiled Emacs using -O3 and have not experienced any issues.

Here is how to apply this optimization:

• Compiler configuration: Replace the -O2 flag with -O3 in your CFLAGS. (Avoid substituting -Wl,-O2 with -Wl,-O3 in your LDFLAGS, as the underlying GNU ld documents optimization levels up to -O2 for linker optimizations.)
• Linker configuration: Replace the -O2 flag with -O3 in LDFLAGS.
• Emacs configuration: Replace -O2 flag with -O3 in the native-comp-compiler-options variable.

The theoretical benefits of -O3:

• Aggressive function Inlining: Function inlining speeds up execution by pasting a function’s code directly where it is called, eliminating the overhead of jumping to a different memory address.
• Loop Unrolling: Loop unrolling is a compiler optimization that copies parts of a loop multiple times so the program does not need to repeatedly check conditions like i < 10 as often. This reduces repeated checks and jumps, allowing the CPU to spend more time performing useful work instead of constantly deciding whether to continue the loop. This creates longer uninterrupted sections of code, which modern processors can execute more efficiently by processing several independent operations in parallel at the same time.
• Faster Buffer Processing (Vectorization/SIMD): For heavy text searching, such as complex regular expression matching or byte-level buffer manipulation, -O3 may allow the compiler to use special CPU instructions that operate on many bytes of data at once instead of processing each byte individually. For example, instead of comparing one character at a time, the CPU may compare 16, 32, or more characters in a single operation, which can improve performance in some workloads.

The tangible risks of -O3:

• Instruction Cache Bloat: Aggressive inlining copies large amounts of code directly into other functions, which can significantly increase the size of the final executable.
• Exposing Undefined Behavior: -O3 enables more aggressive optimizations that assume the C source code fully follows the rules of the C standard. In large and old codebases like Emacs, some code may accidentally rely on behavior that is technically invalid or undefined. When combined with Link-Time Optimization (LTO), the compiler can optimize across multiple source files and make transformations that expose these hidden issues, potentially causing random crashes, UI freezes, or unstable behavior.
• Mangled Stack Traces: -O3 aggressively rearranges and simplifies code to improve performance. Functions may be merged, variables may disappear entirely, and instructions may execute in a very different order than they appear in the original source code. If Emacs crashes, debugging tools such as gdb may produce stack traces that no longer clearly match the original program structure, making debugging substantially more difficult.

Using -O3 is an experimental optimization. If you experience out-of-memory build failures, random micro-stutters, UI freezing, or crashes, revert to a standard -O2 build with or without LTO.

Conclusion

Compiling Emacs from source and bypassing generic Emacs distribution binaries strips away decades of legacy compatibility layers and align the Emacs’ execution directly with your specific hardware architecture.

Remember to trigger a fresh recompilation whenever you update core system toolchains, such as GCC or your graphical compositor, to maintain binary compatibility and performance integrity.

Marcin Borkowski (mbork) has an interesting post on the describe-personal-keybindings command. The idea is that the command lists the keybindings that you have set in your configuration. It’s convenient, mbork says, for checking that new Emacs releases haven’t stolen one of your bindings. It’s also interesting to see what bindings you’ve added and what, if anything, they’ve replaced.

But there’s a catch. In order for a personal keybinding to show up, it must have been set with the bind-key macro. That’s a problem for those of us who are long term users. Those who use use-package exclusively have no problem since the :bind command uses bind-key automatically but bindings set with, say, define-key will not appear in the describe-personal-keybindings output.

That’s inspired mbork to refactor his init.el to use use-pacjkage and for stand-alone bindings, the bind-key macro.

The minions are insisting that I mention what they consider the best part of mbork’s post. That, of course, concerned dark mode. Mbork begins his post by mentioning a Web app that provides a Web based cheat sheet of Emacs commands. Mbork says it’s a cool command but not for him because

if I were to create something like that, it would run in Emacs and not in the browser, it would definitely mention transpose-.* commands, and it would never be dark-mode-only;-).

The minions haven’t been causing much trouble lately so I thought it only fair to indulge their desire to get mbork’s dislike of dark mode on the record.

I have used EWW in Emacs for some of my browsing for a while and it does the job very well unless browsing single page applications or other sites that do not send HTML unless you run JavaScript. Thank you Lars Magne Ingebrigtsen for making EWW! Hitting R filters out all the noise for a really pleasant reading experience. It is good to browse within Emacs with no context switching in a keyboard-driven way.

(Apropos they joys of context switching: When I am a bit tired, I use Emacs keybindings everywhere. Tap-to-click is naturally off on my laptops to prevent insanity. I am often able to "help" my students a lot within just a few seconds of random keybindings and clicking everywhere on their laptops. It is really good for students to learn patience and tolerance towards people unable to handle computers. They need that for their user support class and future work in the IT industry.)

When Joshua Blaise wrote about his eww setup and use, I read it with interest and stole most of his ideas for my own config. The important one for this little hack is that I set up URLs with endings like .mp3, .mp4, .m4v, .mkv etc to launch in mpv when browsing to them. This makes watching videos and listening to audio content easy with EWW. EWW is also good for browsing local files by hitting W with point on a file in dired.

In dired, I usually launch external programs for photo editing, media playback etc by pressing & with point on a file name. This brings up the completing-read interface in the minibuffer which asks me if I would like to use dired's guess as to which program to use (which I have set to guess xdg-open first) or something else. I press return and then mpv, gimp, darktable or whatever launches with the file.

I had an html file in my downloads folder which I launched with W to read in EWW. I then, by mistake, hit W when on a .mp3 file, and it launched in mpv. Since W launches the file in EWW and EWW was configured to open .mp3 files in mpv, it did that without asking me which program to use. It is faster to hit W than to hit & RET, or in worst case write a program name and RET. So now I launch media files with W in dired in stead of using &. It speeds things up a bit.

(While writing this, I also remembered that I have functions for playing enclosure links and links in elfeed through mpv that I might replace or improve by shuffling the links to EWW or einar-browse-url-mpv. I wrote my configuration for elfeed very early in my Emacs journey, without really understanding any of it, by copying snippets from the Emacs wiki, blogs and Reddit so it is high time to look at it again anyway. I can probably simplify it.)

Here are the relevant parts of my configuration for EWW to get this working:

(defun einar-browse-url-mpv (url &rest _args)
  "Opens URL in mpv."
  (start-process "mpv" nil "mpv" url))

(use-package eww
  :config
  (setopt browse-url-handlers
          '(("\\(youtube\\.com\\|youtu\\.be\\|vimeo\\.com\\|twitch\\.tv\\)" . einar-browse-url-mpv)
            ("\\.mp3$" . einar-browse-url-mpv)
            ("\\.mp4$" . einar-browse-url-mpv)
            ("\\.webp$" . einar-browse-url-mpv)
            ("\\.m4v$" . einar-browse-url-mpv)
            ("\\.mkv$" . einar-browse-url-mpv)
            ("\\.pdf$" . einar-browse-url-pdf)
            ("." . eww-browse-url))))

Those of us who have been around long enough remember Sacha Chua’s Emacs Chat videos. The last one was a decade ago but now that Chua’s daughter is a bit older, she’s decided to resurrect them. The first new episode, Emacs Chat 21, is with Amin Bandali with whom she’s worked on EmacsConf for the last 7 years.

The format is always the same. Chua and her guest discuss the guest’s Emacs configuration and how they’ve solved various problems. There’s way too much material for a quick recapitulation—the video is an hour and 12 minutes long—but there’s a transcript at the link so you can go through it at your leisure if you find the video’s pace too rapid.

There were a couple of things that I found particularly interesting. The first is the upcoming user-lisp-directory. It allows you to specify a directory for your Lisp files and Emacs will automatically compile them and add them to the load-path for you. Bandali uses it as a replacement for the package system because he prefers to configure things manually.

The second interesting thing for me was his use of EXWM (Emacs X Window Manager), which goes a long way towards the dream of bringing everything into Emacs. I’ve long wanted to try it out but as its name suggests, it works with the X-Windows system only. The Irreal bunker has famously standardized on Macs so EXWM is unavailable to us. I’d still love to try it though.

There’s a lot of material in the chat so you’ll have to watch it—or at least skim the transcript—to get the whole picture. There are links to his configuration so you can steal anything that seems useful to you.

I’m really happy to see Chua resurrecting her Emacs Chats. I really enjoyed the previous ones and learned a lot from them and I’m sure that will be true of the new ones too.

I've done a small update to make-phony.el, my little Emacs package that lets me be lazy when adding .PHONY to mark a target as a phony target in a Makefile.

The only change is a tweak to the regular expression, to tighten up the check for a target that can be marked.

last-rev.pl

As returning readers will know, I produce (or try to produce) regular builds of Emacs for Windows. When things work, these produce pre-compiled binaries as an installer and unpack-and-run zip files. You can find links to the latest set for each branch in the box at the top-left each page on the site.

Today's post is about one program out from the middle of the bucket-brigade of data I have created, generally in an effort to avoid unneeded queries of the upstream (Savannah or Savannah mirrors hosted) repositories.

Carrying on with the theme of being lazy while editing posts, I've released blogmore.el v4.5.0. This version adds blogmore-set-as-cover. With this, if you place point on a line that is an image and run the command, it is set as the cover for the post.

Sure, it's not like it's hard to copy, move, insert a new line, type cover: and then paste the text, but this is faster and more accurate.

And I'm lazy.

And I like hacking on Emacs Lisp that makes my workflow flow faster.

The shell-pop Emacs package provides on-demand access to a terminal buffer via a single, configurable key binding. It allows toggling a terminal window without disrupting the workspace layout, making it a useful tool for quick command-line tasks.

NOTE: Kazuo Yagi, the shell-pop original author, appointed me as a co-maintainer of shell-pop Emacs package. I recently refactored shell-pop to improve robustness, fix bugs, and add support for additional terminals (vterm and eat). Stepping into the maintainer role gave me the opportunity to give the codebase a thorough refactoring.

Why use shell-pop?

Adding shell-pop to your workflow offers the following benefits:

• Your terminal session remains active in the background, retaining your command history and running processes.
• It can automatically change the terminal directory to match the file or project you are currently visiting in Emacs.
• Toggling the shell does not ruin your carefully arranged window splits. (Especially when shell-pop-full-span is set to set to t)
• It supports a wide variety of terminal emulators (term, eshell, ansi-term, vterm, and eat).
• It provides control over the terminal window layout, allowing you to specify its exact size as a percentage, define its position (top, bottom, left, right, or full screen), and choose whether it should span the entire width of the frame.
• It handles cleanup gracefully by automatically killing the terminal buffer and safely deleting its window when the underlying shell process exits.
• It includes a comprehensive set of lifecycle hooks (for opening, closing, and exiting), allowing you to trigger custom Emacs Lisp functions automatically based on the terminal state.

Installation and configuration

To install shell-pop from MELPA:

1. If you haven’t already done so, add MELPA repository to your Emacs configuration.
2. Add the following code to your Emacs init file to install shell-pop from MELPA:

(use-package shell-pop
  ;; :bind automatically sets up the keybinding AND tells Emacs to lazy-load the
  ;; package the moment the key is pressed.
  :bind (("C-c t" . shell-pop))
  :custom
  ;; The key sequence used to toggle the shell window.
  (shell-pop-universal-key "C-c t")

  ;; Sets the screen position where the shell popup appears.
  ;; You can choose "bottom", "top", "right", "left", or "full".
  (shell-pop-window-position "bottom")

  ;; If non-nil, the window stretches across the entire frame width.
  (shell-pop-full-span nil)

  ;; The path to the shell executable used by the terminal emulator
  ;; (e.g., "/usr/bin/env bash").
  (shell-pop-term-shell shell-file-name)

  ;; The height or width of the window as a percentage of the frame.
  (shell-pop-window-size 30)

  ;; Setting this to non-nil sends commands to the shell. This is not always
  ;; desirable, as it can send commands to any prompt.
  (shell-pop-autocd-to-working-dir nil))

Configuring the terminal

Here are the exact configurations for the most popular Emacs shells. Simply copy and paste your preferred option into your init file:

ansi-term

(with-eval-after-load 'shell-pop
  (setopt shell-pop-shell-type '("ansi-term" "*ansi-term*"
                                 (lambda ()
                                   (ansi-term shell-pop-term-shell)))))

term

(with-eval-after-load 'shell-pop
  (setopt shell-pop-shell-type '("terminal" "*terminal*"
                                 (lambda ()
                                   (term shell-pop-term-shell)))))

vterm

Note: Requires the vterm package to be installed.

(with-eval-after-load 'shell-pop
  (setopt shell-pop-shell-type '("vterm" "*vterm*"
                                 (lambda ()
                                   (when (fboundp 'vterm)
                                     (let ((vterm-shell shell-pop-term-shell))
                                       (vterm)))))))

eat

Note: Requires the eat package to be installed.

(with-eval-after-load 'shell-pop
  (setopt shell-pop-shell-type '("eat" "*eat*"
                                 (lambda ()
                                   (when (fboundp 'eat)
                                     (eat shell-pop-term-shell))))))

Enhancements that I implemented as co-maintainer

If you are a long-time shell-pop user, here are the changes I recently made to the package. I encourage you to try the latest version and send Kazuo Yagi and me your feedback in the issue tracker:

• I added support for the vterm and eat terminals, two highly requested modern terminal emulators. This includes implementing automatic directory synchronization to ensure the shell always matches the current working directory in Emacs.
• Previously, the package relied on global variables and buffer deletion to manage window states. This caused unpredictable behavior when using complex layouts, multiple frames, or tabs. I refactored shell-pop to isolate state tracking by attaching it directly to Emacs window parameters.
• I resolved issues related to zombie buffers and asynchronous window hijacking. The code now stores buffer objects instead of names, scopes process sentinels strictly to the shell window, and correctly verifies buffer lifespans before attempting restoration.
• The toggle functionality now correctly recognizes active shell windows even when the cursor is focused elsewhere in the frame, preventing redundant terminal pop-ups.
• I fixed a directory desync bug by unconditionally enforcing auto cd. Emacs will no longer lose track of the shell’s actual working directory if a user manually changes directories inside the terminal.
• The teardown routines were adjusted to ensure native terminal cleanup processes, such as writing Eshell history, execute fully before the buffer is destroyed.
• I replaced the simulated Ctrl-L keystroke with an explicit clear command to prevent literal ^L characters from printing in the terminal input buffer.
• The hard dependency on the term package is now optional. Users who prefer vterm, eat, standard shells or Eshell are no longer forced to load unnecessary terminal packages on startup.

Conclusion

Taking on a maintenance role for a tool I use daily has been an interesting experience. These recent updates aim to make shell-pop more reliable and modern. I encourage you to try the latest version and send us your feedback.

As I mentioned a few days ago, the Emacs 31 release process was on the verge of starting. Now Sean Whitton writes to tell us that the Emacs 31 branch has been created and that the feature freeze has begun.

This means that the Emacs 31 release cycle has begun and that’s what on the Emacs 31 branch is pretty much—modulo bug fixes and last minute emergency additions—what the final release will be like.

The release cycle—if you believe in history—is apt to be long but even though that can be frustrating it means that the final product is going to be rock solid.

Although I keep repeating it, I can’t say it enough: thanks to all the developers who selflessly donate their time and efforts to making and keeping Emacs one of the best—if not the best—editors available.

In the recent weeks I've been engaging Prot as an Emacs coach to help with doing review passes over my upcoming ffs package as I work on polishing and documenting it in preparation for offering it for inclusion in GNU ELPA.

Yesterday we had our second session focused on ffs, which I recorded and share publicly with everyone with Prot's permission, so that others can also benefit from Prot's insights and experience as we discuss various aspects of Emacs package development with the concrete example of ffs.

Here is the video recording of our session:

You can view or download the full-resolution video from the Internet Archive.

I addressed most of Prot's feedback about ffs from our first session, and I'll be working on the changes we discussed in this session in the next days.

In the last third of the video we switched topics to discuss a few Emacs-related tangents including adding a 'padding' effect for the mode line and its constructs, and distilling and separating the easily-reusable package-like parts of one's Emacs configuration from the actual configuration of those parts (e.g. the distinction of prot-lisp and prot-emacs-modules in Prot's Emacs configuration).

For mode line padding, here is the snippet I'm using with Prot's doric-themes:

(doric-themes-with-colors
  (custom-set-faces
   `(mode-line
     ((t :box (:line-width 6 :color ,bg-shadow-intense))))
   `(mode-line-inactive
     ((t :box (:line-width 6 :color ,bg-shadow-subtle))))
   `(mode-line-highlight
     ((t :box (:color ,bg-shadow-intense))))))

Take care, and so long for now.

I met with Amin Bandali to talk about Emacs, specifically Amin’s upcoming ffs package. Amin informed me about changes to ffs in light of a discussion we had during a previous session.

Amin asked me to record the meeting and then publish it, which I happily agreed to. You can watch it on Amin’s website: https://kelar.org/~bandali/gnu/emacs/ffs-code-review-prot.html.

[ NOTE: I normally do not share anything about my meetings with people. Not who they are nor what we talk about. ]

Thanks to Amin for making this happen! I am looking forward to new developments.

By the way, I learnt about the function x-export-frames from a mention in Amin’s ffs package, which led me to write buffer-to-pdf: https://github.com/protesilaos/buffer-to-pdf.

I chatted with Shae Erisson about Emacs, keyboards, Org Mode, and life.

View it via the Internet Archive, watch/comment on YouTube, read the transcript online, download the video / MP3 / transcript, or e-mail me your thoughts!

• Shae Erisson: Haskell, Python, Swedish, knitting, mountain unicycling, contact juggling
• Shae Erisson's blog - 1. DO SOMETHING 2. BRAG ABOUT IT
• Shae Erisson (@shapr@recurse.social) - recurse.social
• Shae Erisson's blog - Programmers want flow. when programming, light turns RED
• shapr/markovkeyboard: keyboard layout that changes by markov frequency · GitHub

Transcript

Transcript

0:00 Intro

Sacha: Okay, so I'm going to actually remember to hit go live. I've got a 10 second delay, so if we need to panic, we can panic. Okay, so let's see. I think we are live. Hi, everyone. This is Emacs Chat number 22 after a long hiatus. And today, I'm here with Shae Erisson, who is also like an Emacs friend from a long time back. So this is it. As you were just saying, this is the first time we're actually talking live. And I'm looking forward to hearing about your configuration, how you use Emacs, Shae. But before we dive into that, can you give us a little bit of context? Who you are, what sorts of things you do, and how you use Emacs for that?

0:57 1999, IRC, community building in Haskell

Shae: I would say that... I guess I started using Emacs in 1999 when I moved to Finland. And I remember about the same time I was on IRC and I was really frustrated. I remember I got on the Perl IRC channel and I was like, hey, I want an editor that has syntax highlighting. I want to see colors to these words when I'm typing them. And they were like, noob, and they kick-banned me. And I was like, well, maybe I don't want to learn Perl, which I never did. And I guess that was an early introduction into I wanted to be part of communities where people were sharing positive things and building up each other. Actually, I ended up starting the Haskell IRC channel a couple of years later, and that became a very big thing. I would say that I'm mostly known for my work in community building in the Haskell programming language community, because I did that for, I don't know, 15 or 20 years. But I really like Emacs.

1:58 Emacs as a light-weight build-your-own-editor toolkit

Shae: So like last week at the same time I had the standing chat with a friend of mine who is also a programmer and he said oh so you're going to do this thing in a week do you want to give me like a preview of the talk and I was like yeah I guess so and some of the things that were really interesting was he was like I've never really tried Emacs I don't know much about it I kind of have this impression that it is a very lightweight build your own editor toolkit and I I was kind of taken aback because, you know, I guess I still have this long ago and far away. I don't know if you remember 8 Megs and Constantly Swapping is what people used to call Emacs and things like that. And I was, it was just kind of, I realized I'm still in my little echo chamber. And this is why I like to talk to other people all the time is because I want to have some exposure to what other people are doing.

2:51 LSP, treesitter, Magit, jujutsu, C++, Python, Haskell, rust

Shae: I guess things about Emacs that really changed stuff for me is language server protocol, TreeSitter. Those, I think, are two very powerful tools that are much more generic than, I mean, Magit, of course, is like magic. Although I've mostly switched to jujitsu lately instead for the last year. Let's see, I had, I guess, let's see, I did C++, I did Python, I did a whole lot of Python. And then I had Haskell jobs for five or six years. And then I switched to Rust about a year and a half ago. I now have a Rust job. And one of the things that Prot had asked, I think, or you had asked, and I forget exactly how this went.

3:35 how does a new person experience Emacs? Emacs is always fun.

Shae: It was great fun watching your livestream. And it was, how does a new person kind of get comfortable with using Emacs for a particular purpose. And I look for things, in fact, like how do I use Emacs for Rust, Rust development? And I found a couple of good guides on, and I was able to follow most of them, although my Yesnitit stuff is broken and I don't exactly know why tab doesn't work, right? But, you know, like there's always, Emacs is always fun, right? There's so many cool things you could do with it.

4:03 Markov keyboard project, moving to Finland, right-handed Dvorak, split keyboard; Jeff Raskin; I am not a koala

Shae: I noticed, I actually hadn't seen your preview page and I noticed that you found my Markov keyboard.

Sacha: When you say Emacs is fun, I'm reminded of all of your fun, crazy keyboard experiments. It's like, what? I have a feeling you like to tinker with things.

Shae: Yeah, so I think actually the influences as to how I got to where I am are pretty interesting. So the person that I ended up moving to Finland to for dating her, we started a company, we did projects, and I was the programmer. We had this pretty big project. I guess it was like 350,000 euros. And I mean, that was going to be over four years and we had to kind of complete the whole thing, and I was the programmer and we'd had the lowest bid... I had an IBM model M, you know, the super clicky with like all the... And about three years into it, my arm started really hurting a lot. But I was the only programmer. And nobody else knew all the code. And we had to ship it, because that's how we got paid. And so I ended up pushing through. And at the end of it, my arm just didn't work anymore. So for about a year and three months, what I did was I actually taught myself to type right hand. ...Dvorak, because I was already using two-hand Dvorak, and so I kept programming, but I just... One of the things was... like, I like programming, I like using computers, I don't want to wear out my arms again, I don't want to blow them out, so I ended up switching to split keyboards, and I will show you. This is very much the kind of thing that I like to use, and that is like this.

Shae: This is an Ergodox Infinity, but there's a lot of other keyboard flavors like this. And one of the things that I particularly like about this... So around the same time I met Jeff Raskin, who wrote the Inhumane Interface. And so for this particular thing, this is like Control and Alt and Hyper and Super and Shift. And this means that under one thumb, I have a lot more modifier keys than you get off of a standard. And it also means... A lot of my problems started with Emacs pinky, the dreaded, the infamous... I think that one of my... I made a keyboard layout called "I am not koala." You may not know this, but koalas have two thumbs. They have one on each side. And that's cool, but I don't have two thumbs, and I realized that when I was trying to grab something, I didn't put my pinky on it. That would be silly, right? I want to put my thumb around it. And so I decided I would move all of my chording keys under my thumbs. And that's kind of how I...

6:43 Purpose-specific function keys

Shae: And another thing I did was when I was really only able to use one hand, was I made my function keys mostly purpose-specific. And that was from Jeff Raskin's writings in The Humane Interface. So I guess I'm a programmer who really likes writing code, doesn't want to wear out my arms, and likes to do fun keyboard things, yeah.

Sacha: Definitely. You're in it for the long term. You don't want to use up all of your arm capacity now and not be able to keep programming in the future. And now there's hardware to make that easier. So I'm glad. Split keyboards with extra thumb keys seem to be very popular in the Emacs community. I'm now tempted to find space in my desk in order to make that happen.

7:30 Trackballs, scroll

Shae: Another thing I ended up switching to was I started using trackballs. Oh yeah, yeah. I tend to go completely overboard when trying out new things, so I bought 20 different models of trackballs and ended up settling on this one. The nice thing about this one is that this is how you scroll, and it has four buttons.

Sacha: That is really cool. I like using ThinkPads, so I've been just living off the tiny little mouse in the middle of the keyboard. But back in the day, I also used a trackball. If I can get to the point where I want to take my hands off the keyboard again in order to do mouse things, that would probably be the direction I would go.

8:14 1" trackpad rings

Shae: I had an experiment in that area, which is where I purchased a one-inch touchpad, and I strapped it to my finger. And it was a PS2, and it had a USB converter plugged into it. And the idea was I could keep typing, and then I could move the mouse around without taking my hands off the keyboard. And now they actually have touchpad rings. They came out six months or a year ago. It's relatively recent. But the idea is no change in context.

Sacha: I've only seen the scroll rings, but now there's a touchpad version. That is interesting.

Shae: Yeah, I think that's pretty cool stuff. Hardware is actually improving things.

8:54 Pair programming: ttyshare, shwim

Shae: Oh, another thing, one of the things you talked about with Prot was how do you learn other people's stuff? And one of the things that I use for pairing, so I have one coworker, and it's a strange, interesting job. I like it a lot. And I met this coworker at a previous job, and one of the things, let's see if I can find it. So we used to, at the previous job, we used this thing called ttyshare. Have you heard of it? ttyshare. It's great. You can run it in a terminal and then you can effectively share your terminal with someone else. And so you have multiplayer terminals and that's neat. It was kind of a pain to set up. You had to make sure that you weren't NATed, you know, like you had to have effectively... someone had to have a public IP. You had to do a couple of other things. And as part of my job, I'm now, I guess, part maintainer for Magic Wormhole, the software.

Shae: And so one of the things that my coworker wrote was this nifty thing called ShWiM. And it's basically "shell with me." And it's a wrapper around TTY share so that with one single command, you can share a terminal. And the way that we use this is... We both run Emacs as a server, and then we use emacsclient in the terminal to connect.

Shae: I don't know if you've ever done this, but I can have a terminal right next to this, and if I run emacsclient in a window, then I'm sharing the same thing. This is a graphical chat with Sacha, in the terminal or in the UI, and both of them are updated.

Sacha: That's fantastic. I remember people were using tmate for something similar before where you could share that. But yeah, it's just making it seamless, making it frictionless. And on the other side, I have also just been using wormhole to send large files back and forth between Karthik and John Wiegley because we have this other Emacs chat thing where we're going to post it eventually, once I finish figuring out how to redact all the personal information and Org files. But yeah, it's great for being able to send things without having to worry about, oh, you know, what's my public IP? Can I tunnel all the different things to get past whatever firewalls there are? So if this also works for terminal things plus Emacs client, that sounds really, really exciting.

Shae: We've tried some other experiments. One of the things we tried to do was, and the only downside is like, what if my terminal has a different size, then you have to kind of shrink and match. And so we tried to honestly directly bridge to Emacs clients. And because I don't know if you're aware that there's effectively a local socket for the Emacs client that you can have multiple things connect to. But it turns out there's some sort of like system so I couldn't like reach across the network and directly use my co-workers Emacs session and he couldn't use mine. Weird things happened when we tried to do this cross host. As far as I can tell the Emacs client only works in the same host.

Sacha: That's interesting. Lately, I've also been experimenting with CRDT, which has that Emacs-less plant as well. So that's been nice. But yeah, of course, a lot of people will be kind of stuck with the first challenge of finding someone that they can pair in Emacs with.

Shae: I understand. And I think I'm honestly very happy that my one single coworker at this job is also a big Emacs user. And so we exchanged cool ideas and worked on stuff. And I'm very happy about that.

Sacha: Were they already an Emacs person before they joined? Or did you pick the coworker because they were an Emacs person?

Shae: They picked me. They were pretty much the person who started this thing. And they picked me because they'd worked with me at the previous job. Although I did have an experience like that. I had this massive Emacs config file, like 20,000 lines, and half of it was comments because it had accrued over 20 years.

13:13 Recurse Center, "What is that keyboard? What is that editor?!", Emacs bankruptcy and starter kits

Shae: And in 2019, when I first went to the Recurse Center, well, my first batch, I just was extremely extroverted and social. But my second immediate following batch, which is not the common pattern, I was like, okay, my goal is to write a bunch of Haskell, get some Haskell jobs, And so I went to the quiet room on the quiet floor. But then someone else came in, Marianne, my favorite programming friend. And she was like, what is that keyboard you're using? And I was like, ah, this is an Ergodox thing. And then she's like, what is this editor you're using? And I was like, oh, that's Emacs. And I was kind of a grumpy, like, I'm trying to get stuff done. But she was persistent. She was like, show me this thing. And so I was like, I'll show you Emacs. And she was like, this is great. And I was like. This thing? OK, cool. And I was like, I don't think you want my config. You'll probably want a starter kit. And she was like, well, what are starter kits? And I was like, well, I've heard about Spacemacs. I've heard about Doom. And I would try one of those. So she tried Spacemacs. And I guess this next part happened over several months. She tried Spacemacs. And then she was like, I like it, but it's slow. So I'm switching to Doom Emacs. And I would pair with her. And I was like, wow, look at all these cool things that the starter kits can do. I ended up flushing my entire 20-year-old config and kind of starting over and stealing a lot of great ideas from the starter kits. And Marianne is very ambitious, independent, hardworking, very focused. I'm not very focused. But I've learned a lot of things from her and watching her kind of... I haven't done C in Emacs in a long time so it's great fun to watch her learn these new things and then I learned stuff too and yeah it's good to have collaborative people to work with.

Sacha: So it sounds like if people would like to encourage more people to talk to them about Emacs, feel free to use your strange keyboards out in public.

Shae: I like that. That's good. That is good. Yeah I think that's reasonable.

Sacha: Yeah, and I've just recently started digging into the starter kits too, because I realized I don't know much about them. It is really interesting going through them and discovering all these Emacs 31 options that you can enable to simplify your config or improve your workflow and all that stuff. So there's a lot of good stuff in starter kits, even for people who are not newcomers.

Shae: I agree. And I think there's nothing wrong with just learning a bunch of new things, trying them out, and also throwing them away if you don't like them.

Sacha: Now that you've declared Emacs bankruptcy and rebuilt your Emacs on top of other people's starter kits, what has made it into your config? What have you kept from those 20 years of tinkering with Emacs that you really wanted to stick around?

16:06 hippie-expand

Shae: I think the only thing that has absolutely stuck around is my use of hippie-expand, which is, I believe, a very old... an ancient tool from a different time. Most of the other stuff is kind of gone. Gone to the wayside. But I really like, I honestly really like hippie-expand. And I know that like, I have rarely heard of other people who use hippie-expand. But you use it? I think you just muted yourself.

Sacha: I also vote for hippie-expand. It's a nice way to try different functions and just say, I just want all these different possible completions to go in there.

Shae: Yeah. The thing for me that really sold me on hippie-expand is that most of the time when I am... When I'm doing something, I want to say, like, I can already see that word, just pick that one. And so I'll type the first characters and hit, like, meta forward slash, and ta-da, it's usually there. But then sometimes I do really want, like, some Elisp or some other stuff. And so I actually spent a lot of time tuning this the first time.

17:14 yasnippet

Shae: I actually only changed it for the first time recently because I was reading a how to write Rust well inside Emacs and they said oh well you want to use yasnippet and so I you know the funny thing is that yasnippet I believe is the thing that got me into Emacs like in 1999 I met this Finnish person Erno Kuusela in Oulu, Finland. Really cool guy. I was like, wow, how do you do this? As soon as you open a file, it's got a substructure and a skeleton. And when you type part of a function or something, it just populates it. And he was like, I'm using this snippet command in Emacs. That's why I was like, what's Emacs? It was very exciting. And at the time, I was using Vim. And Vim was not as, I don't want to say, automatable.

Sacha: Yeah, now with Neovim and Lua, people are writing more extensions for it. But before, you had to know a lot of magic in order to customize Vim.

Shae: Right, right. I agree. Let's see, what else do I do? I run my own email server, and I, of course, read my email in Emacs. In GNU, no less. Which is, I know, an NNTP reader, but it's still also a great... I used to use twiddle compile and I think that stopped working like six years ago, so I need to get rid of this comment, but there's still a lot of kind of cruft from earlier times.

18:52 Function keys

Shae: Remember how I said that I use function keys to have like purpose specific stuff? This was especially true because, I mean, I had my left arm strapped to my chest for like a year and three months before I even started regaining any flexibility, and that meant that... I'm amazed that you could just map them directly to single commands instead of giving in to the temptation to make them prefixes for longer keystrokes. I didn't really have the choice because I had only one arm that worked. It was just a lot harder to do any chording at the time. I still have a lot of these. F3 I use a lot, which is like, oh, what am I working on right now? That is org-clock-goto. A lot of times, I want to have a terminal that's in Emacs, so that's vterm,

20:02 Org Mode

Shae: And I actually really do use the calendar all the time. This is like just switch to whatever it is. Of course, my email is here. You know what, let's see... So this... I don't know, have you seen this before? Have you seen this thing called STARTED in an Org mode file?

Sacha: I use a STARTED state, yes.

Shae: Well, I got it from you! So if I look at like, my Org Mode configuration, a lot of this STARTED stuff I have from you, I don't know when, but you were the person who introduced me to it.

Sacha: It's the reminder that I did start working on this. I tend to get distracted by intermediate tasks, so it's nice to be able to say, try to finish these ones first before you move on to the next thing, maybe?

Shae: I agree. I have the same thing, yeah. And I keep meaning, because this is... I know that you can put Org Mode configuration into the first TODO item. I would really like to move it into the elisp and I just haven't gotten around to it. And it's been 10 years. I mean, maybe I should just do it.

21:14 Show Org agenda when idle

Shae: One of the things I did that I found fun... I really have written almost zero Elisp, but I did actually puzzle my way through this a year ago. Since so much of my life is in Org Mode, I learned how to make timers. This is very close to what you get directly out of how to do timers in Emacs. After some amount of time, I want my Org agenda to pop up because I want to say like, oh, what is the stuff I'm supposed to be doing? And what am I forgetting? What has been scheduled? And what is on my to-do list? And I also like to look at what is the stuff I've been working on lately? And I really like that a lot.

21:58 Programmers want flow. When programming, light turns red

Shae: Another thing that I realized is that I had a blog post that was wildly popular. Where did I put it? And it was all about Emacs. I don't know if you saw the... Here we go. It was... Ah, here it is. So here it is in... This is very much an Emacs...

Sacha: Oh, yeah, I remember that one. I put it in Emacs News. I thought it was great.

Shae: All right, cool.

Sacha: I would like the kiddo to sometimes be able to acknowledge this, but this is not happening. Still, yes.

Shae: Right, right. Yeah, and so this was really fun because, like... I had a friend who was in development and there was like millions of dollars spent on how do you detect whether a programmer is in flow and it came down to if they're typing they're probably in flow so and that was it because they tried to look at EGs and doing all kinds of other stuff but it was like if they're typing don't interrupt them. And I don't know, because I do so much in Emacs, I'm not sure how accurate this was. But basically, that's where I learned to do timers the first time. Or maybe... I don't remember which one I did first. And the idea then was as soon as basically my average typing into Emacs has gone up a certain amount, then it will actually switch to busy. And it works just fine. It was a lot of fun to write.

Sacha: So yeah, interesting use of getting the activity. I've seen other fun implementations of this. I think there's a c-c-c-combo package that makes some fun animation appear if you're typing really quickly.

Shae: Oh, oh, yeah. I'm guessing because I think Atom, the Atom editor had that for a while. I guess that's where it came from.

Sacha: So yeah, because you can instrument Emacs and play around with it, you can certainly do all sorts of things based on that information. Okay, so you've got it, you've got it set up so that when you come back to your computer, it'll show you the stuff that you've been working on. And when you're working on the things, you can tell it to tell the rest of the world not to bug you. Gotcha.

Shae: That's right. [Sacha: What other fun stuff do you have in there?

24:25 ef-themes and modus-themes, season

Shae: I discovered that I love the EF themes. I love the Modus themes. They make me very happy. They're just unreasonably pleasant. As someone who has tried every single Emacs theme ever, they're just my favorite themes.

Shae: And so, at the moment, it's summer... Where did my summer go? How can this be? There we go. How come I'm in spring? Wait, isn't spring over? Hasn't summer just started? You know what I was thinking would be fun would be take the time of day, and you know that the EF themes has spring, summer, autumn, and winter, and I'm not sure if there are dark versions of each of those, but I thought, like I know that Modus themes will do this like check for the local time of when it turns dark, and then it will go from the light theme to the dark theme as soon as the sun hits, and I was like, well, what if I do that for seasons, you know, wouldn't that be cool?

Sacha: There's this subtle sense of change as you go through the year. But of course you also have this thing there where you just randomize it.

Shae: Well, I like that. Sometimes it's like I'm just kind of like, ah, I'm bored. I'm just bored of what I'm looking at. And so I will just change my thing. And it's just time for something. I don't know. It seems to work. It's like it gives me a little brain break from what I was staring at. And I did not know I was going to reset the effects scale, but that's fine. Interesting. What else do I have in here?

25:56 htmlize (does this still work on Wayland?)

Shae: Oh, Emacs HTMLize. I'm a little sad. I switched to Wayland. And if I remember correctly, HTMLize only works with, or maybe HTMLize still works, and it's the SVG one that doesn't work. Emacs SVG is a thing that if you're running with an X11 backend, you can turn your current screen directly into an SVG, which is really cute. It does not work in Wayland. I think HTMLize does still work. What other things do I have in here? I don't know. I guess a lot of it lately has been trying to make Rust things work smoothly. I've been trying to do some... I wonder does... Oh, cool. That was not what I expected.

26:37 lsp-ui-imenu, jumping through rust code

Shae: I just started doing this thing with imenu. imenu integrates nicely with LSP.

Sacha: That is a very pretty sidebar thing, and I need to learn how to do that.

Shae: So because I have all these extra modifiers, my s-i is lsp-ui-imenu. And the reason that what I mostly use that for is when I have like a bunch of Rust code and I want to quickly jump through the structure of it. Basically that integrates with LSP, finds all the definitions, and I can quickly jump through it. I used to use lsp-treemacs for that, but lsp-treemacs puts things in its own order, not quite the same order I want, although treemacs is quite nice. I think that the thing to do is that you and I at some time maybe the next time if we do this again we should set up with a Shwim connection and you and I can both share our Emacs and then you can show me cool things that you do and I can show you cool things that I do and then we can start filing over some of the things. How about that?

Sacha: That sounds fantastic. I know we'd wanted to experiment with pair programming a long time ago so that sounds like a seamless way to do it. And therefore I will go and figure out how to install shim and get it working. I will probably need your help to actually test it. I don't know, I think I can rustle up. Maybe it'll work off my phone. You haven't tried that. But lspui, okay, so I've just been using straight up imenu, like on Neanderthal, but lsp-ui has this fancy grouping of things and colors and stuff, so I definitely want to check that out.

Shae: I'm a fan, yeah. I don't know. Do I have anything else exciting that goes with this in here?

28:25 laptop with 126GB of RAM

Shae: I will say that at the moment, the system I'm working on, I like buying unreasonably powerful laptops. And so, like, this system has 128 gigs of RAM and 24 cores. My previous laptop has 192 gigs of RAM. Long story short, I end up in a lot of cases where I want to use more memory. I've got all these cores. Can you do something with them? Perhaps you've already seen things like LSP doctor, which will say, have you tried this thing? Have you done this other thing? LSP has really changed

Sacha: I have not. Sorry, would you like to show me this LSP doctor thing? Because I have not ever seen it.

Shae: Yeah. Do you use language servers much for your development?

Sacha: I am only just getting used to having a relatively modern 2018 instead of 2010 laptop. And so I have the red squigglies and various things, but I don't know what to do with them yet.

Shae: Well, I mean, I'm doing a lot of this. So I have...

29:46 LSP coolness, Haskell, treesitter

Shae: Originally for me it was like I spent a lot of time with the Haskell language server because I was doing so much Haskell and it was a super powerful thing. In fact, somebody decided to hammer in half of a proof assistant into the Haskell language server and that was magic. You could do incredible stuff with that because you could just grab all of your local variables and transform the whole shape of your function and you could just write little snippets and just have it work. And that was amazing. It wasn't quite... One of the goals that I believe is... For future development of all programming editors, I believe that something like Emacs macros, but instead for abstract syntax trees, I believe this is an essential ingredient that we do not yet have. And I think that TreeSitter is the first step towards there. We now have one of the hats, right? Which is where we can take... TreeSitter is, you know, if you've used it... It is like you write some effectively C code to produce a really fast parser. Or is it like JavaScript that then compiles to C code? I forget exactly how it works. But the nice thing about TreeSitter is, I don't know if you remember, I'm sure you do remember, that if you were writing Python code and you used a triple-quoted string, you had to then add a comment with another quote because regular expressions is how Emacs was doing all the syntax highlighting. And honestly, that was kind of crap. And then there were projects like the Semantic Bovinator that made a full parsing suite in Elisp, which to me is half brilliant and half insane. And then there was TreeSitter, which kind of took over the world because it was... I think that the language server and TreeSitter are the first two of these editor generic pieces, and I suspect there will be more. I think that something where you can modify the abstract syntax tree and then put back to the source is one of those potential paths forward. I hope so.

Sacha: Yeah, that would be great if you could just do the manipulations and then roundtrip it back into source code. Just regenerate the changed part of your code. That sounds fantastic. So it sounds like you were able to do some kind of manipulation with the Haskell use case that you were describing. Any chance you can show us like the awesomeness?

Shae: Sadly, that sadly does not work anymore.

31:58 Combobulate

Shae: But you know, if you're looking for something in that area, have you heard of a Emacs library called Combobulate?

Sacha: I have heard of it. I haven't dug into it.

Shae: So it uses TreeSitter for source code manipulation by, and it's a lot closer to the way that like, you know, in Org Mode, you can like hold meta and arrow to kind of move things around. It uses TreeSitter to let you both move around in the context as well as actually alter the shape. And to me, this is the first step towards this tool that I want, which is where I can write a keyboard macro and have it edit an abstract syntax tree and then spit the results back into the buffer. Yeah.

Sacha: All right.

32:46 What else are you using your 126 gigabytes of RAM for?

Sacha: What else are you using your 126 gigabytes of RAM for?

Shae: Let's see. Honestly, I'm going to tell you that Rust Analyzer can take a lot of memory. And a Rust compilation can take a lot of cores. And I'm okay with that because I actually, I do like, and I will say that this laptop is actually from this year. So it's a brand new, like, top of the line. But then like, how would I, because I've got like, which I think is a bunch of matrix multiplication hardware. How do I use that from Emacs? I don't know. I'm sure I can find something, you know.

33:25 TalonVoice

Sacha: Maybe voice computing?

Shae: Oh, that's an idea. Yeah, one of my friends, she's using Talon. Have you heard of Talon?

Sacha: Yeah, I've heard of Talon. There are a couple of videos about people using Talon to code by voice, usually involving memorizing kind of a different alphabet for very quickly accessing different shortcuts. But it sounds really cool, and you sound like you've got the hardware to do something amazing with it.

Shae: That's true. Well, you know, Talon actually lets you do something very similar to Combobulate, where you can navigate the AST of your source code. You can kind of move around very quickly. I don't know, like, are we like at the end of our? No, no, we're halfway through, right?

Sacha: We're halfway through. I have about 28 minutes before the kiddo runs out and starts demanding lunch.

Shae: Okay, well, I feel like I've been driving the structure of our just kind of like dumping random things. Did you have any questions or anything you wanted to cover?

Sacha: This is all amazing. I come in with no preconceived notions. I'm just like, okay, shapr does cool things with Emacs. Let's hear about it. Let's go, let's go.

Shae: That works for me. Yeah. I mean, a lot of it's been focused on Rust development lately. Rust and Jujutsu.

34:45 NixOS, following Steve Purcell about 5 years behind

Shae: I've been doing a lot of Nix. I'm running NixOS. I don't know if you're familiar, but that's been great fun. It's funny, I feel like I've been following Steve Purcell around from a technical perspective. I'm always about five years behind Steve.

35:03 envrc

Shae: I was like, oh, you know, NixOS is kind of a pain with Emacs. And just like this, what was it, NixOS? I forget. Anyway, Steve was like, oh, well, have you tried my library, envrc? And I was like, what's that? And he was like, well, now each buffer can have its own envrc. And I was like, it's perfect. That's exactly what I need. Because previously, every time I switched buffers, it would then go load all of the local everything in Nix. And sometimes that could take a long time, especially if I'm doing Haskell, that could take 10 seconds, and I really don't want that sort of lag. And so Steve Purcell's brilliant library, envrc, says, you know what? Every single buffer can just keep such a thing, and then you can only relit it when you need to. And that's pretty awesome.

Sacha: That sounds cool, and I should check that out too.

35:52 time-tracking

Sacha: @JacksonScholberg has a question. He says, "I was curious about what you were tracking your time working on, how you track it." Is it just Org Clock? So this is how you keep track of the things you're working on and what got interrupted by the new thing that you just added to the stack and so forth?

Shae: Right. In fact, I have this thing. Honestly, when I sit down on my computer, Just clock in. You'll notice in the bottom right here, we have chat with Sacha, right? And so like, I just kind of clock in stuff. And like, I'm not always, I really kind of need to reorganize my Org mode files because I've been naming them per host because I previously had like a work Org mode and I had a home Org mode. now that my home hardware is also my work hardware I guess and so like I still have my previous laptops things where I'm keeping my events I really need to reorganize things but I mean yeah I schedule things I oh you know I've got a weird thing to show you

37:01 taxes with Org Mode, remote lookup

Shae: I decided that it would be great fun to do my taxes.

Sacha: You are showing me your taxes, do I need to like black out this whole thing?

Shae: Well, this is actually just an example from the docs. So I could actually share my taxes on it because I mostly don't care. But I think in fact you can figure out exactly how much money I'm making by looking at the open whatever. So the thing about this is that I decided to file all of my tax forms directly into Org Mode spreadsheets and then do remote lookups. So basically each spreadsheet was one particular form. And then once I'd gotten to the bottom, like I need this result, like what's my estimated income? And then I would use the lookup, kind of this cross spreadsheet lookup. And that's how I did my taxes for last year. And then my de facto mother-in-law, she's an accountant, and she didn't exactly do this thing, but it was pretty close. She was like, you've got all your taxes in the spreadsheet. I was like, yeah. And then she looked at it and she was like, what is that? And I was like, anyway. So I got to kind of file everything back out into TurboTax, but that was a fun thing to build.

Sacha: Yeah, I have something like that too. So for example, whenever I do my tax paperwork, I just have to have like, you know, the step by step checklist. Okay, this is where I need to go to get this number. This is where I can put it in. And then eventually it spits out a table that says, okay, put this in box 11, put this in box 13, so that I don't have to do the steps by hand. Because even before the, you know, for me, I use like simple stacks or whatever, it's web based. But before you get to the point where you can put the numbers in the form, you gotta go to this website, calculate this thing, and Org just makes all of that so much easier.

Shae: I agree. Yeah.

Sacha: And this remote lookup thing is something I'm always looking up because Org tables are so powerful, but also I need more examples in my life to remember how to use them.

Shae: Well, I think it took me four hours the first time to get it all figured out. But I can send you an example without showing it here. I can send you an example because I figured out, I think I've hammered the remote lookup down very thoroughly.

Sacha: And once you've got it right, you can just keep filling that in or copy and paste it. You have an example of the syntax and that's already all you need.

Shae: Right. I did run across some limitations of the evaluation method of Org mode spreadsheets. But maybe I've been using them a little too hard, if that makes any sense.

Sacha: Oh, what kind of limitation?

Shae: Honestly, I think I finally found a way to say every single... Because it was... So really the way that spreadsheets work is they're much more like Dataflow. And that is just that you end up with, like, either you work from the endpoint, which is like much more Haskell style evaluation, which is where you're like, I need to start here. What depends on this? But in the case where you have a whole bunch of different Org Mode spreadsheets, I think I ended up with this little text style hack where I just ran it a bunch of times. So it's like evaluate, evaluate, evaluate. Because remote lookups I ran, you know, I don't remember. And I think I took notes, but I don't remember. That's one of the great things about Org Mode is that I swear it's my, like, half of my brain is in my Org Mode notes. And whenever I had, I'm like, oh, what was that thing? I'm like, well, fortunately, with my terrible short-term memory, I took copious notes because otherwise I would never be able to get back to it.

40:55 finding notes with C-s

Sacha: What is your favorite way of finding those notes?

Shae: I actually use a lot of C-s just because I kind of have some idea of where they are in my tree structure and I'll also say I use a lot of my Org capture templates and they're not super complicated. I have like a to-do, I have a journal, I have ideas and like random ideas will float into my head like you saw Markov keyboard right it is like the weirdest art piece you've seen all day right and Markup keyboard shows up on the front page of Hacker News once a year or so. And people are like, programmers have gone too far. This cannot possibly be usable by humans or something. And I'm like, well, I don't know. I think it was art. And so a lot of times those things will drop into my head, something like that, where I'm trying to do something else. And so I will quickly write down the idea and then just gotten it out of my head enough that I can continue with what I was doing. And so I have a long list of strange ideas. A recent one was like, you've probably had your teeth worked on once or twice. And you know that the dentist always had to move the light around. And I'm like, but we have really good eye tracking. Wouldn't it make sense to figure out where the dentist or the car mechanic is what they're looking at? And then have the light move around behind them to figure out how to actually light up the place they're looking at, right? We've got vision tracking. Why don't we do this? But I don't really, yeah. I decided maybe I don't want to work on that one right now.

Sacha: It sounds like an involved project. Yeah. Yeah, yeah, yeah. Okay, so you're capturing, you're stuffing a lot of these ideas into an inbox.

42:35 Org Mode, managing inbox

Sacha: A lot of people are probably in the same boat where they've got these inboxes full of ideas. How do you deal?

Shae: I archive stuff when I'm done with it.

Sacha: Oh yeah?

Shae: Yeah, so a lot of times, and I find this very valuable, is like if I look at... Do I have it? Oops, that was not what I meant to do.

Sacha: Alright, so you basically just do aggressive speed commands, archive, archive, archive, or look at the agenda and just mark a whole bunch of things and say, that's it, that's gone. It was written down and then it can go.

Shae: Yeah, well, when I'm really done with something, when the thing is finished, then I will just archive it. I mean, do you use Archive much?

Sacha: I do. I have a function that goes through my inbox file and just archives anything that was marked as done.

Shae: Oh, nice!

Sacha: Because that way it clears it up, right? So I'll refile things where I'm like, okay, it's done, but it has important information. I want to put it somewhere else. But if it's just a transitory task that I'm using to remind myself, tomorrow I have to do this, go find the water bottle when it's done, I don't need to know about it in the future. So it's left in my inbox because I checked it off, and then periodically I'll say, clean up inbox. Not only will it remove all of the done things, but if I leave a tag In the title of the task or if the task matches certain regular expressions, it will refile it to the appropriate place in my kind of more permanent thing. So I can say, okay, all of my Emacs related tasks will get automatically refiled to my Emacs category without my having to do that manually.

Shae: So you're using tagging because I kept trying to do tagging and never quite did it.

Sacha: I use tagging sometimes when I remember it, but this is also why I use the The regular expression match against the title. I'm using Orgzly on Android to capture the thing on my phone. I might want to say this is a consulting task. File it in the right place so it doesn't get lost in my inbox.

Shae: Wow. When is your interview so I can learn from your tricks?

Sacha: This is now. Here we go! You can ask questions. The nice thing about conversations is that we jostle different ideas, and we are like, oh yeah, maybe I should write a blog post about that, because I take it for granted. So now apparently I have to write a blog post about my cleaning up process. My inbox is very long. The other thing, speaking of dealing with really long lists that I picked up from John Wiegley was I also sometimes remember to check this list of random items. So in my agenda, there's also like this, you know, random selection of things that I have not gotten around to thinking about further, but it's there just in case serendipity or boredom make me do something.

Shae: you know that's... I've thought about having... because you know, I've got the pop-up this little timer that pops up my agenda, but I've thought about maybe adding a section I don't know if I could add a section here but it would be something that says like at the bottom here's two or three random to-do's that have been open for a while just like for garbage collection. Because I know that in Jujutsu, I've got a cool little query that says, if you have any change sets that are more than two weeks old and are not in a permanent branch state, maybe you should do something about them. It's just called to do. It'd be kind of nice to have that for Org Mode as well.

Sacha: Yeah, it's just, you know, and our brains do these strange things with randomness, right? They're like, oh, I want to see what's new now.

Shae: Right, right, yeah. Oh, I have a question. You have this thing where you had...

46:28 Timestamps

Shae: I saw you taking notes with Prot, and you had this timestamp.

Sacha: Oh, yeah, yeah, yeah. I'm using it now. Okay, okay. So I have it bound two ways now. I have it as a dabbrev, so dynamic abbreviation, and I also have it as a yasnippet because sometimes I'm using it with either SPC or tab to complete it. And I don't really want to think, I just want to get the timestamp in and then move on. And so abbrevs can run functions to evaluate it. You can insert the timestamp that way. Or yesnippet, of course, can evaluate the thing. And now I have those. It's basically just a wall-clock time so that I can go back and plop in the chapters as time offsets, which are automatically calculated from the YouTube data on when the stream started. So I don't have to manually calculate my chapters. But it's super useful to have these times everywhere. And in this case, during a conversation, I want to be able to say, hey, we talked about something interesting. And then be able to go back to that point in the video later on.

Shae: So you're matching? Oh, oh, wow.

Sacha: So my shortcut for yasnippet is "ot" because I never type "ot" elsewhere, and it's close enough. I use Dvorak, so my O is on home row, and T is close by. Also, on the other hand... There you go.

Shae: Did I already show you that this is actually Dvorak?

Sacha: Oh, there you go. Now I can see the keycaps. Yeah, earlier it was kind of blurry, but now, yes, yes. So yes, that is my shortcut for inserting the timestamp. I previously added seconds as well, but then I realized that my kind might be false precision. So I just, you know, just use a minute at the moment and then I go back and adjust the timestamps a little bit later. But yeah, you can use abbreviations for all sorts of things, including times and dates and stuff.

Shae: Have you ever tried Org timestamp?

Sacha: Yeah, Org timer. So Org timer gives you a relative timestamp, right? You can say Org timer. Oh, okay. So, sorry. Are you talking about the C-u C-c ! or something of that sort? So that's actually what I initially was doing, but then it was too many keystroke word modifiers to remember. And then I had to press RET to select the, you know, thing. So now I just have an abbreviation insert the Org mode formatted timestamp for me. And then I have this code that searches for Org timestamp regular expression and then does the calculation and conversion and stuff.

49:12 Org timers

Sacha: So Org timer is a separate thing. It's useful for meetings and things like that. You would say, okay, your Org timer starts at the beginning of the meeting and then you can have a list and it automatically, like if you alt shift enter or something like that in the list, it'll automatically like insert the right timer, relative timer to it. There you go. So there's an org-timer-start. But the reason I didn't go that approach was because then you A. have to remember to actually start the timer and B. then you have to synchronize your time with video time. Which might not have started at the same time. So now I'm just like, okay, wall clock for everything. And then I can do the transformation with whatever I like. And since I'm editing my subtitles in Emacs, I can say, hey, this file started at this time, according to YouTube. And then just, you know, map all of the wall clocks to the appropriate subtitle times.

Shae: Wow. That's really cool.

Sacha: Anyway, so timers, relative, absolute, and using abbreviations is great. Which I think actually is a thing that I picked up from Karl. Karl Voit because he also likes to use... He has an abbreviation, not at the Emacs level, but he has an abbreviation on his system level, like with his window manager, so he can use this timestamp trick anywhere, including in Etherpad or wherever else where you want to insert the date and time. That's V-o-i-t, by the way. But yeah, so times are a great way to just leave yourself a pointer to that moment so you can go back to it later.

Shae: Now I'm curious, how well does that integrate with this sort of thing? Because I really like looking back at my history agenda.

Sacha: If you have it insert an inactive timestamp, I think it should still show up there. I think it will be a little like those.

Shae: Yeah, it looks like the... Well, it looks like these two are showing up.

Sacha: Yeah, yeah, yeah. Yeah, so that's a basic thing that I would have inserted by my either abbrev or... So it's not even dabbrev. It's just regular abbrev in Emacs.

Shae: What's the difference?

Sacha: dabbrev is like hippie... Okay, let me just double check here. I feel like dabbrev is sort of hippie expand-ish. It looks in your buffer or possibly other buffers. And I think hippie-expand and dabbrev, they kind of work together. It's an option to have them work together. Okay, so hippie-expand is... Oh, so I see. Hippie-expand is the more advanced version of dabbrev. dabbrev was Dynamic Expand, and Hippie Expand says, yes, that, but try a whole bunch of other things first. But my timestamp thing is actually just done by a regular abbrev, and I will find the thing in my config for "ot". Oh, yeah. I will put it in my chat.

Shae: My spelling, most people say my emails are spelled really well, but it's only because I have ispell set up.

Sacha: Yeah, ispell is great. I am learning French and therefore...

Shae: Oh, c'est très bien. Je parle un peu de français aussi.

Sacha: Oh, oui. I'm keeping a journal in French on my blog and I have the Tatoeba Project with all the example sentences and I have a consult interface to look up stuff in them so I can just borrow other people's words and try to make it sound more natural. Plus of course the usual searching for words in dictionaries and stuff. Anyway, in the chat, I put in my global abbrev table definition for insert format time string. In case you want to steal that, it's right there.

Shae: I will definitely save that into my notes here.

53:53 Org Mode snippets

Shae: Another thing I use a lot is I use Org Mode snippets. I will tell you that the first time, I guess if I look back at... This is another thing that I have done a lot of in the past, which is where... I love the fact that Org Mode snippets are just executable. I can just run them. I guess two jobs, three jobs ago, there was a case where, because I would keep the results around and look at them, there was a case where, I guess a couple of months before, something got shipped to a customer, and I noticed our database schema had changed and I prevented a tremendous amount of upset and emergency by being like this doesn't look great. I got one from two weeks ago, and it does not match. Something's wrong here. Everybody's like, I don't think so, Shae. And I'm, like, no no no, we do have a problem, we've got to fix this. And they were, like, oh crap! And then I was like, yeah, solved a problem!

Sacha: Yeah, I basically try to do as much in a snippet instead of in, you know, in a scratch buffer or whatever, just because having that record, the fact that I did it, and also any notes that I had leading up to it and the output of it, it's just so helpful.

Shae: Oh, I've got a cool thing that I'm doing for work. And that is that our readme file is not only a word file, but we also have the demonstration of our actual thing is done by using like dependent snippets. And so that means that like if you want that, perhaps this is something everyone already knows, I don't know, but we basically are using the results of earlier commands in later places. And the other nice thing about that is that then when we want to check, we have to effectively dock tests, right? When we want to check and see if our software works the way it does in the readme, we evaluate the final Org Mode snippet, which then calls it forward, calls it forward, and then if something goes up or not. Well, I guess I need to fix something. And so it was pretty exciting to put Org Mode niftyness into our, into my Word reading file, you know?

Sacha: Nice, nice. And you did mention your other coworker is on board with the whole Emacs thing. So that's one of the things that people are often like, I want to use Org Mode and I want to use it for like the documentation or the testing or whatever, but they got to get everyone else on board with the thing. Otherwise it's Jupyter Notebooks or whatever else, right?

Shae: Right. Okay, so I have a joke for you that I came up with a long time ago, and that is, do you know the only way, there's only one way that Sauron could have organized the invasion of Middle-earth, and do you know what he used?

Sacha: What?

Shae: Orc Mode. It's a terrible joke, isn't it?

Sacha: That's okay. I'm sure someone in the comments will come up with an even worse pun.

Shae: I'm excited! It's going to be great!

Sacha: Never underestimate the punniness of the Emacs community.

Shae: I completely agree. I don't know. Do I have anything else exciting in here?

57:15 Compilation finish function: handle success

Shae: I actually really like this one. I used to run all of my tests in compile. F12, I have F12 bound to compile. And one of the things I wanted was, I wanted something where it was, if the compile is successful, don't show me the results, because everything's good. And so since I'm doing stuff in Rust, when I run all the tests, it leaves the buffer up, and I need to get around to actually doing stuff like this for Rustic mode as well, where when the tests pass, just go away, because it's all good. And when the tests don't pass, show me where to... I need to look at the problem. And I got this from Enberg and Emacs, I don't know, 20 years ago. Maybe it was less than 20 years ago, but it probably wasn't. So yeah, there's so much good stuff. Yeah, there's just so much good stuff. And I also like to, oh, look, here we go. You can see that this is long gone, by the way. It's not there anymore.

Sacha: I have a proper, you know, it's sachachua.com/dotemacs. A lot easier to remember. But yeah, and I think that's, yeah, yeah, I remember that now. defadvice is also obsolete. The new hotness is advice-add or something like that.

Shae: Oh, really? I'm going to make another TODO item for there.

Sacha: I was digging through my notes trying to find, do you share your config anywhere?

Shae: No, but you know, at this point if I share it on YouTube, I might as well just throw it up somewhere. Why not? It's not very exciting. Like if you look at someone like Ross Baker who has magic, like wow, is there some magic coming in from Ross Baker? I'm so excited to see more stuff from him. There's just like, I guess I feel like compared to almost everybody else I know, I feel like a power user. Because I'm like, you know, I wish I could do this thing. A lot of times someone I know is like, well, I did that thing and here's a library. And I'm like, yeah, I'll have to do it. And I just, I guess I feel like I'm a power user. And on the good side, I guess I kind of, I really haven't written that much Elisp ever, like I was saying in the comments during your interview with Prot. And I kind of like to, it's just I guess it's never quite gotten to the top of my stack. And I did decide it was time for me to send money to Parade for at least for themes, if not for like, please teach me some Elisp so I can actually, because you know, it's not that Elisp is hard. It's more like, how do I kind of, what are the things I interact with? What are the words? What's the vocabulary of working with Emacs? I don't actually really know. As a user, sure, I can do cool stuff. I can do Lisp macros. I've done Scheme and Lisp some of the past, but not inside Emacs.

Sacha: Alright, so let me clarify. After more than 20 years of using Emacs, did you say you feel like a power user or do not feel like a power user?

Shae: I definitely feel like a power user, but I don't feel like someone who does much of anything with Elisp. I don't really feel like someone who has much of a clue in the internals. And that's not entirely true. I have some of the ideas. But for the most part, I haven't actually needed to know that much about the internals. And sure, I've dug into things like how do you efficiently work with large buffers in your ??, like the ropes data structure and stuff like that. That was more for fun. Although it is something that Emacs does and does extremely well. But I'd kind of like to... There's a lot of things I'd kind of like to change and I don't really have enough of the understanding of the kind of how I would write the Elisp to do it. Here's a good example. When I hit F3, it takes me to the one I'm currently clocked into. Unless I haven't clocked in to something since I started Emacs. And honestly, I would like to use something like org-ql, the Org query language, to go find if I've just started Emacs, and Org does not know about something, you know, I just want you to go search for it. I have so many cores and so much memory, just go find it.

Sacha: That sounds like an excellent reason to go learn Emacs so that you can have it... If you're not currently clocked in, go find the most recent clocked in task and go there, or maybe present you with a list of things and then go from there. I would love to hear about your Emacs Lisp learning journey because that's one of the big things that moves people from, you know, power users, yes, but users, to using Emacs as a lightweight editor toolkit for something that's custom fit to exactly what their workflow is. And on that note, I'm going to try to wrap up gracefully before the kiddo, you know, just like drags me out here. Thank you so much for doing this. I look forward to more conversations. I'm going to post the transcript and other things like that pretty quickly, I think, because I have this nice workflow now that lets me take screenshots and everything, but there's so much here that I want to unpack. But I hear the kiddo, bye!

#+begin_export 11ty

<a name="end-ec22-transcript"></a></details> #+end_exportbvt

Chat

• JacksonScholberg: ​​Emacs is fun
• JacksonScholberg: ​Apple's touchpad is another option
• JacksonScholberg: ​Trackpad
• JacksonScholberg: ​Lol
• JacksonScholberg: ​I was curious about what you are tracking your time working on
• JacksonScholberg: ​How you track it.
• JacksonScholberg: ​You clock in and out to what you are working on. I like that idea.
• Bezaar.musicc: ​​That's great!
• PuercoPop: ​​the buffer api (properties) is the hardest part for me
• charliemcmackin4859: ​​I think you still have a timer going, btw

Find more Emacs Chats or join the fun: https://sachachua.com/emacs-chat

View Org source for this post

You can e-mail me at sacha@sachachua.com.

I've released an update to blogmore.el, my Emacs package that helps me out when writing this blog. I've added two commands to this version which help me be lazier than ever.

The first is blogmore-become-like. When run, this prompts for another post and, once selected, it sets this post's category and tags to be the same as the other one. I added this because I'm often writing an occasional series of posts that are all about the same project, and so I always find myself copying and pasting those frontmatter properties from another post.

The second command I've added is blogmore-toggle-image-centre. Built into BlogMore is a little bit of styling that will ensure an image is placed in the centre of the page, if the URL for the image has #centre on the end. This means that, for most images I add, I have to go and edit the URL to add that. Now I can just run a single command when the cursor is on an image and it'll add (or remove, if it's already there) that styling hint.

In both cases, I've added the commands to the transient menu too.

capture icon

Product: Capture
Price: $7.99 · lifetime updates · up to 5 Macs · 7-day free trial

Capture is a product designed to capture something, and move on with your life. It is an universal product, you can be in any application, Safari, Chrome, BBEdit, Finder, anywhere. You can press the keyboard shortcut to invoke capture. Fill in what you want to capture. Hit return and go back to whatever you were doing.

The product is advertised as “Capture thoughts to Obsidian without leaving what you’re doing.” You don’t have to use Obsidian. I use Emacs and it works great for that too. You can use any text editor and it is as useful.

Two Routes

capture options

Capture gives you two options to capture your content.

1. You can capture to a new individual file. Every capture gets put into a time-stamped new file.

capture where?

1. You can append to an existing file which you have specified, or append to a daily note.

capture and folders

You can define the Obsidian vault that Capture deals with. In my case it is the folder which contain my org files. Within that folder is another folder called ‘capture’ where I put my captured files into.

capture context

Within these options you have various options. You can include context. You get to define the context.

capture tags

You can add tags to your captured content.

I am happy with Capture. It is a focused utility which does what it promises well.

Wishes for Capture

1. I understand that the link to Obsidian means that this deals with Markdown files. We don’t need that restriction. It can work with Org-mode files and plain text files. Give me the ability to specify the extension I want my files to be.
2. The command to save the capture is ⌘↵. On my machine ↵ saves the capture. There is no way to add a new line. This must be a bug.

Recommendation

I used the program for fifteen minutes and bought it. It is the kind of utility which I am going to use multiple times a day.

Recommended most heartily.

macosxguru at the gmail thingie.

twtxt was one of the strongest inspirations behind Org Social: a plain text file served over HTTP, with no active server, no database, no signup. I personally admire the work done by Buckket: the concept is so powerful that it has captured the hearts of many people over the years. Its author gave us an elegant solution for creating a personal microblog, an alternative to Twitter (now X).

That said, Org Social would not exist if it weren't for the limitations of twtxt or the natural evolution of social networks. Org Social keeps its spirit, learns from its mistakes and from the competition, reinforces other concepts (like federation) and adopts modern features (like visibility). It is not an improvement, it is a shift in approach.

That's why I'd like to go over the three most important aspects where Org Social improves on twtxt.

Technical improvement

The most obvious one is the ability to have structured metadata thanks to Org Mode.

#+TITLE: Bob's journal
#+NICK: Bob
#+DESCRIPTION: I'm a software developer and I love open source.
#+AVATAR: https://my-awesome-website.com/avatar.jpg
#+LINK: https://my-awesome-website.com
#+FOLLOW: https://foo.org/social.org
#+FOLLOW: https://jane.com/social.org

* Posts
** 2024-12-12T12:00:00+0100
:PROPERTIES:
:LANG: en
:TAGS: emacs org-social
:CLIENT: org-social.el
:VISIBILITY: public
:MOOD: 😊
:END:

Hello Org Social!

This opens the door to giving context to each post, having native threads, tagging, organizing in groups, defining visibility, running polls...

We don't just get richer post bodies: the possibilities for interaction between users grow without limit. The specification invites you to create, not to work around limitations.

5 design principles

Org Social follows these principles:

• Simplicity: the format must be easy to understand and write with any text editor, with no special tools or advanced technical skills required.
• Accessibility: the feed must be readable by both humans and machines.
• Decentralization: every user should be a node, a self-hosted feed or one publicly accessible.
• Org philosophy: the format must take advantage of Org Mode features, like links, tables, code blocks, checkbox lists, etc.
• Your information belongs to you: no one owns your feed, content, or followers. Just you and your text file. Where you host it is a separate matter.

Without clear rules, the ecosystem fragments. There isn't a single line of the specification that isn't aligned with the points above.

Infrastructure should add value, not be a requirement

A very important element in Org Social are the Relays, which let you organize threads, discover other users, receive notifications, run searches, get an RSS feed, etc. However, without them the network would still work: users could keep publishing, following others and interacting. Relays are not the core of the social network. Clients can rely on them, but should never depend on them. This isn't a quality exclusive to Org Social: twtxt is also aligned with this principle. The point lies elsewhere.

The goal of clients is to make reading and writing feeds (social.org) easier, not to be a requirement to participate. That said, they are very practical for building your timeline, since you need to read and sort the feeds of the users you follow. For that there are Desktop and Android versions thanks to Emacs, plus a native iOS version written in Swift.

The differentiating point is balancing different user profiles via the infrastructure. For example:

• Users with no technical knowledge: in a couple of clicks you can have an account thanks to Org Social's free hosting. The clients will take care of syncing and publishing for you. It is very similar to how other networks like Mastodon work, except that everything lives in a plain text file locally and transparently.
• Users with some technical knowledge: they can host their social.org on GitHub, GitLab, their own server, etc. They control and manage where it is hosted and how it connects.
• Users with deep technical knowledge: they fully control their presence on the network. They run their own server (with WebDAV, for example), with their own configured domain, with their own caching policies... or they even spin up their own Relay for extra speed or to build private federations.

It embraces every kind of user, without sacrificing the essence of the social network. You don't need to be an expert to take part, but if you are one, you control every byte.

Conclusion

Org Social doesn't just improve on twtxt technically: it also evolves the concept of a social network on top of plain text. It takes a step forward by providing more infrastructure and incorporating modern features.

The future is not about going massive or competing with Mastodon, but about satisfying a very small niche of users.

Focus on the content or on engaging with others, Org Social will take care of the rest.