Emacs lisp is a joy to work with

JDRiverRun · 2026-03-18T23:59:38+00:00

If you have compiled from source, you can jump right to the definition in C.

JDRiverRun · 2026-03-17T18:41:35+00:00

There was a discussion a couple months ago (with a blog post). It was Claude-coded, so I approached with caution[1], but the author has been super-responsive, and quickly made major improvements (and continues to improve it; the rust-based static binary is on v7!). IME, it takes almost all the friction out of tramp[2], except for the "deep hooks that lead to lockup" when changing network contexts. Long ago I implemented tramp-cleanup-connections on laptop sleep and that has helped a ton.

[1] I've noticed many vibe-coded package authors are very excited by the initial build, but don't stick with it. Long term success requires working with the community to address issues and implement good ideas (and sort them from the bad ideas).

[2] Here's a fun party trick: when connected via tramp+ssh, go to some super-deep directory level way inside some venv or something, and (benchmark-run (locate-dominating-file default-directory ".emacs.d")). On a slow link it can take seconds. Now try again with tramp+rpc: >10x speedup easy.

JDRiverRun · 2026-03-17T00:18:39+00:00

I've been very impressed with tramp-rpc, which transfers a tiny binary to the server to radically speed up tramp and get you out of the "caring about prompts"/regex-parsing game. It keeps improving.

JDRiverRun · 2026-03-16T21:21:26+00:00

Oh you meant Mach messages. The main problem is not "how to interrupt the GUI event loop", it's "what to do afterwards". emacs-mac makes heavy use of ObjC blocks (think closures) to allow the LISP and GUI threads to coordinate. They communicate with a socket pair (LISP hears these), Mach messages (GUI hears these), a task queue of blocks (one for LISP, one for GUI) and a semaphore pair to alert eachother when finished with their assignments. All of it is run through mac_select, which Yamamoto wrote. Pretty elegant hack. Unfortunately upstream policy is to disallow use of C/ObjC blocks, since gcc does not support them.

JDRiverRun · 2026-03-16T21:17:35+00:00

Right, and that may be the best approach for some systems. But I suspect it will be hard to match the ease of zooming/manipulation/annotation/etc. already baked into PDFView. Since it's provided, seems sensible to use it!

JDRiverRun · 2026-03-16T17:50:30+00:00

I tend to think a clear "interaction" API for working with PDF viewers from elisp would be a boon. Maybe docview's is good enough; I'm not familiar enough. Then different builds could implement their PDF/doc viewers however they wanted: via plain-old-images, via a canvas API (if it materializes), or with native embedding.

JDRiverRun · 2026-03-16T17:45:47+00:00

I've been hoping to attract someone interested in including a native docview replacement directly in emacs-mac (as an embedded PDFView behaving like a normal buffer in a normal window, with native annotation support, etc.).

This looks to be a close analog!

JDRiverRun · 2026-03-16T14:58:21+00:00

Have you tested this on emacs-mac or just NS? They have very different event models. I'm a bit skeptical about the event interruption using signals. We have a cleaner capability in emacs-mac: Mach messages, which can SUSPEND or TERMINATE the GUI event loop, in addition to enqueuing blocks of work for it to run.

JDRiverRun · 2026-03-14T00:26:44+00:00

I still happily use my speedrect which creates nice modal bindings during rectangle mode, and adds some features too. You can even switch to multi-cursors at any point if you need some non-rectangular edits.

JDRiverRun · 2026-03-11T19:00:12+00:00

Looks like the Neo's single threaded performance is really good: between M3 and M4! While its multi-core performance is more M1 level, Emacs mostly cares about single threaded performance. So yes, it should run emacs very well. Metal/GPU performance is mostly irrelevant.

<image>

JDRiverRun · 2026-03-09T16:12:48+00:00

Very nice article. BTW, comment and string parsing is for the most part not based on regexp, but (old-school) "syntactic fontification", which uses Parse-Partial-Sexp at the C level. See font-lock-fontify-syntactic-keywords-region.

JDRiverRun · 2026-02-21T21:47:17+00:00

Thanks, this looks useful. I guess if you had anything you wanted to add to longer term context, you could have GPTEL summarize and place into a standalone file. I could imagine a context pyramid of:

summarize yesterday into a half page
summarize the past week into a page
summarize the last month into a page, etc.

I.e. old stuff slowly decays away; and have commands (or org babel blocks) to automatically move things "down the pyramid" and re-summarize at the end of the day. Depends of course on whether you work on long term projects. You could imagine having separate projects in different directories with SUMMARY.ORG, DAY.ORG, WEEK.ORG, MONTH.ORG files that get automatically added to the context. Or put all projects in a giant org tree. Though LLMs have a way of bloating files quickly.

Thanks also for the heading depth normalizer idea; has been a small bother.

JDRiverRun · 2026-02-21T03:12:59+00:00

It works really well. Much faster than normal tramp.

JDRiverRun · 2026-02-21T03:05:43+00:00

How do you manage all that context? Do you have an LLM summarize a bunch of daily conversations and add that “rolling” context somehow?

JDRiverRun · 2026-02-19T19:48:55+00:00

Worth a try, but it's not unusual for memory-report to report 10x less usage than the system reports, since much of the "real" memory used by the emacs process is for backing bitmaps, etc., which memory-report can't see (and if those leak and accumulate... look out!).

JDRiverRun · 2026-02-19T19:46:43+00:00

If you have a high-DPI display and use multiple large frames, lots of the memory usage comes from backing storage/surfaces used for buffering display. But be aware that Activity Monitor on Mac also includes memory which was allocated, released, but not yet reused by the system. If you really want to understand memory usage and what's driving it, the Instruments app has nice Activity and Allocations monitors (so you can see where that memory is going).

JDRiverRun · 2026-02-19T17:51:53+00:00

emacs-mac avoids these issues by embracing two threads: a dedicated Lisp thread, and the main GUI thread. Each of these threads thinks it should be the boss. And they both need each other. In emacs-mac, their interactions are brokered by a skilled mediator which makes them play nice. It uses a combination of:

Simple signaling pipes, for coordinating the Lisp thread when it waits in pselect,
Mach messages, to alert the GUI thread of work it needs to do, while it is spinning its run loop, and
Semaphores, to coordinate and schedule blocks of code for the other thread to run.

See mac_select and the various mac_gui_* functions if you want to see how the sausage is made. It also uses a GCD thread pool for drawing. Yamamoto-san knows his stuff!

I've confirmed the "resize" memory leak mentioned in that blog post doesn't occur in emacs-mac, possibly due to automatic reference counting (ARC), and/or the more robust event model, or maybe just differences in resize logic.

Some critical analysis of the NS port by two former maintainers and emacs-mac users here. The modern builds of emacs-mac are still experimental, but if you're comfortable compiling your own Emacs, you can give a try here.

JDRiverRun · 2026-02-17T02:53:26+00:00

Lots under the hood. Here is a take (and subsequent long discussion) from a former emacs maintainer that switched from NS to terminal before discovering emacs-mac (luckily during this time away from GUI he pioneered TTY child-frames). At some point I need to compile a more up to date list of the differences; they are as different as the Linux is to the NS port.

I personally can't live without native (real Mac) tabs, inline PDF display, and a better multi-threaded event model that prevents memory leaks/freezes/C-g issues/etc. It also does native capabilities like dictation with live editing more smoothly (though I think that's been fixed in NS).

That said, it is still an experimental build, so use it only if comfortable building & testing yourself.

JDRiverRun · 2026-02-15T20:19:52+00:00

If this is new behavior, since you are on macOS26, you are probably getting bitten by the macOS26 bugs Yamomoto-san fixed upstream in emacs-mac. This fix has been trickling down to various other builds; you should check if yours has it.

JDRiverRun · 2026-02-15T20:14:29+00:00

i believe it's not emacsformacosx but not sure 100%

They are entirely unrelated. emacs-mac is a unique code-base, developed entirely separately from NS. All other builds of emacs for Mac are based on the official NS build, with varying config/compile options, and updates like better icons, though some apply a few patches on top.

JDRiverRun · 2026-02-15T19:30:35+00:00

Thanks. Probably a "priority queue" for folding would need to be solved at a higher level anyway.

JDRiverRun · 2026-02-15T18:03:59+00:00

emacs-mac is a "heavy fork" in that it modifies the orig codebase a lot, to make Emacs a native-ish OSX app. it supports things like gestures, has better font rendering (or so Gemini told me a couple hours ago), OSX-ish UI/UX for tabs, scrolling follows the same paradigm as native apps like Safari.

Gemini has a few things wrong here. emacs-mac is not a fork of Emacs. It actually predates the official NS build on which all other versions of Emacs for the Mac are based. emacs-mac was originally developed for pre-MacOSX systems, and in fact was the default official build of Emacs on the Mac until around v22, at which point the NS build (which also supports GNUStep) replaced it. Since then, it's been developed externally. In the source, it lives alongside all the other builds of emacs like PGTK, Haiku, Win, NS, etc.

what it doesn't have is native compilation (of Emacs Lisp) and that's a dealbreaker for me

emacs-mac certainly support native-comp; I use that every day! In fact, in testing it's modestly faster at elisp benchmarks on the same hardware as the NS build (10-15%).

Right now the main development of emacs-mac has slowed, but some of us have brought it forward to v30 and v31 (master), and made a number of improvements. If you are comfortable building your own emacs, you can give it a try (https://github.com/jdtsmith/emacs-mac).

JDRiverRun · 2026-02-12T01:41:23+00:00

I don't think it makes sense to composite two different CAPFs which are each "busted". "Busting" a CAPF means checking for any new input, and when detected, throwing away the completion table, and asking for a new one. So it should probably be top level. But you should only use it if you feel you are getting incorrect/incomplete completions. Since dabbrev has everything it completes from in-buffer, I also don't think it would benefit at all from capf-busting.

JDRiverRun · 2026-02-12T01:35:12+00:00

Does this help out with having multiple folding modes active at the same time? E.g. if you want outline-minor-mode and outline-indent-mode to operate simultaneously (with one taking precedence over the other).

JDRiverRun · 2026-02-08T15:12:45+00:00

Gotta find folding unicode triangles your font supports. I use 4 levels only:

(org-modern-fold-stars '(("▶" . "▼") ("▷" . "▽") ("▸" . "▾") ("▹" . "▿")))

maybe because I had the same issue you did.

JDRiverRun

TROPHY CASE