And if someone manages to fix the bug described in the OP, he might have to maintain it as a fork because some influential emacs maintainers want it to be frustrating and unpleasant to use Emacs on non-Free OSes.
Can't they just use Jemalloc with something similar to LD_PRELOAD under OSX?
Ah, ok, it's Cocoa related. It won't happen for instance with the Lucid build of Emacs for Mac OS X, but you might need an XServer for that. Altough I could be wrong and Lucid libraries can be run under OSX if they are ported...
This is worth undertaking. macOS's stricter approach to handling some questionable hacks in Emacs could improve the codebase across all platforms.
The PGTK frontend for Emacs (the Wayland-native frontend) was derived from the macOS version for instance. It replaced much of the messy X11 code with a cleaner, more modular Cairo-based frontend, which could be further enhanced by adopting a cross-platform, more future-proof SDL toolkit.
The problem with the PGTK frontend is it is notoriously EXTREMELY slow. The latency on user input compared to the X11 (especially Lucid) version has some people reverting back to X11/Lucid.
When I do run Linux I run Wayland, I daily drive macOS, but better than both are what you already allude to: the Emacs widget toolkit which will focus on replacing the GUI frontend with SDL and also (equally potentially) introducing an actor-type framework (akin to BEAM's) for communication to decouple that GUI.
I think I will take some flak for this ... but honestly, I've always preferred running Emacs in my terminal. Weird things like this always happen when a windowing system gets involved (and I suppose, window system support was kind of bolted on to Emacs, not designed in from version 0). I started using the terminal exclusively on Linux when gtk + emacs --daemon was known to cause frequent crashes. I carried this over to using Mac OS without really thinking about it. I currently use Mac OS for work and some days I use Emacs with a native windows and sometimes just use my terminal. (Kitty is a really nice terminal. KKP is supported in Emacs with a third-party package, and kitty can do things like display underlines, italic, bold, etc. I use Windows Terminal at home and it really sucks compared to Kitty.)
There are advantages to using a native window (display your method doc popups in formatted markdown instead of plain text), but they have never really made up for the jank, so I've never committed to it. I'm glad the author took a look, though.
I recently noticed deleting a frame doesn't seem to free the associated memory; you can see this by running Activity Monitor and opening and deleting some frames. It's on the order of 10s of MB (exact amount depends on size of frame, whether it is fullscreen, etc). This is not much on a modern machine, but if you open and close lots of frames everyday (as I do) and keep Emacs running for weeks at a time (I do that too) then it starts to add up. My current kludge is to add a hook to resize a frame (which deallocate most of the frame memory) before deleting. This keeps the leaked memory to a level that is more tolerable.
(I've dug through the ObjC source, specifically "nsterm.m", but haven't quite figured out the core problem.)
Addendum: I wrote the original comment after skimming the article but before reading it (and the associated thread on emacs-devel) closely. These memory-related issues are (of course) what the article and the emacs-devel thread are about.
Kind of wish I had the time/energy to help out here cos I'm motivated and interested, but I don't, so I'll just say thanks for the effort and write-up! The emacs-devel thread is interesting too: https://lists.gnu.org/archive/html/emacs-devel/2025-07/msg00...
there's another interesting issue on OSX which I've got a patch for in my homebrew version: on OS X, sleeping in a thread can hang, which causes LSP issues for me (through the `lsp-auto-install` package, since it downloads in a thread). The bug thread is interesting, but seems to have petered out; the patch works for me though!
Emacs jank on macos has been slowly killing me. Enough so, that I am thinking of completely jumping ship after almost a decade of using emacs.
I often end up facing lag and performance issues in several different aspects of using emacs. Every time I boot up vim or any of the modern editors (zed/vscode), I get shocked at how smooth they are.
I only have 3 realistic options at this point:
- stop using macos (won't because macbooks are the best hardware I can get)
- stop using emacs
- keep suffering
currently I'm doing #3, but I soon need to make the hard call and swallow the pill.
What will my next editor be? Zed? NeoVim? write my own? Is there any other lisp/emacs like editor?
you might enjoy Lem! for ages i thought it was an editor _for_ common lisp, and then i learned the other day that it has built in lsp mode and highlighting for typescript and lots of other langs. it's pretty good!
though i highly recommend writing your own editor. there aren't really any editors out there that can provide what emacs can provide someone who's been using it for almost a decade.
Even if macbooks were indeed the best hardware you can get, does having the best hardware you can get really matters more that having the best IDE you can get?
There is fennel which compiles into lua. I know there are some people who use fennel almost exclusively, and have some sort of system set up that watches and auto-compiles and sources. I only ever used emac as a basic text editor in the terminal (years ago), so I can't say if this will be sufficient compared to the "real" experience in emacs. Just letting you know in case it is helpful.
edit: I forgot to mention the most important thing, I am talking about using neovim
This is a problem with Emacs on virtually every GUI platform. Emacs insists that it owns the main loop, while most GUI frameworks insist that they own the main loop. Emacs wants to slurp some events from a queue-like thing, throw some drawing at another queue-like thing, then wait for another event. The GUI instead wants to call back into Emacs whenever an event comes in.
All that being said, Emacs has always worked pretty well for me on Mac. I use Emacs and PDFgrep to spelunk through multi-GBs of PDFs and it is faster than almost anything else.
As Daniel Colascione ('quotemstr' around these parts) said [1]:
> GNU Emacs is an old-school C program emulating a 1980s Symbolics Lisp Machine emulating an old-fashioned Motif-style Xt toolkit emulating a 1970s text terminal emulating a 1960s teletype. Compiling Emacs is a challenge. Adding modern rendering features to the redisplay engine is a miracle.
Emacs owns its main loop because, damnit, it created one before it was cool.
Hats off to any heroes who would manage to drag it, kicking and screaming, into this millennium.
> It sounds horrible. But does it make sense? If it’s that bad - why didn’t anyone notice?
But they did! As you say yourself
> For many, this slowness won’t be a surprise. There are plenty of complaints about slowness on MacOS, especially around popular packages.
So this is some parody, describing as efficient something rather inefficient
> Because Emacs is very efficient.
> For instance, dragging a window handle - depending on the machine - could result in thousands if not millions of such events, causing allocation and reallocation of gigabytes of memory;
fwiw I live in [macOS emacs](https://emacsformacosx.com/) all day long for systems engineering (C/C++) and have 201 open buffers, an uptime of 57 days and ~540 MB memory usage.
I also live in macOS Emacs built from source, currently running 31.0.50. Linux kernel dev over TRAMP w/ clangd language server, ~300 open buffers and <500MB memory.
> Even in the best case though, things won’t be as great as they are on Linux or Windows.
Worst case, you just swap out the NS p pselect hack and use a w32-like separate thread. Let Emacs be Emacs and let Cocoa be Cocoa.
NS would be just as good as Windows then. Isn't that bood enough? Maybe this thread splitting is the "deep event loop surgery" the author meant? I haven't been following.
On macOS and Linux, I haven't noticed any performance issues with Emacs. On Windows, however, the performance is significantly worse. To make matters worse, I even have to patch w32.c just to get it to build:
@@ -10298,7 +10298,7 @@ w32_read_registry (HKEY rootkey, Lisp_Object lkey, Lisp_Object lname)
/* mingw.org's MinGW doesn't declare _dstbias. MinGW64 defines it as a
macro. /
#ifndef _dstbias
-__MINGW_IMPORT int _dstbias;
+__MINGW_IMPORT long _dstbias;
#endif
/ Fix a bug in MS implementation of 'tzset'. This function should be
I do not seem to be experiencing this issue on my work machine, which is a 64 GiB MBP, running Homebrew's version of Emacs. It runs fine, but the endpoint security software activates every single time a binary is run, which means that Emacs workflows heavy on spawning subprocesses, like magit, tend to be slow.
29 comments
[ 3.2 ms ] story [ 57.1 ms ] threadAh, ok, it's Cocoa related. It won't happen for instance with the Lucid build of Emacs for Mac OS X, but you might need an XServer for that. Altough I could be wrong and Lucid libraries can be run under OSX if they are ported...
https://appetrosyan.github.io/posts/emacs-widget
Hopefully, similar improvements can address the issues with large locks and the lack of proper threading.
When I do run Linux I run Wayland, I daily drive macOS, but better than both are what you already allude to: the Emacs widget toolkit which will focus on replacing the GUI frontend with SDL and also (equally potentially) introducing an actor-type framework (akin to BEAM's) for communication to decouple that GUI.
There are advantages to using a native window (display your method doc popups in formatted markdown instead of plain text), but they have never really made up for the jank, so I've never committed to it. I'm glad the author took a look, though.
(I've dug through the ObjC source, specifically "nsterm.m", but haven't quite figured out the core problem.)
[edited slightly for clarity]
[bug]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75275#83 [brew]: https://github.com/d12frosted/homebrew-emacs-plus/compare/ma...
I feel like there’s a vi joke in this submission subject…
I often end up facing lag and performance issues in several different aspects of using emacs. Every time I boot up vim or any of the modern editors (zed/vscode), I get shocked at how smooth they are.
I only have 3 realistic options at this point:
- stop using macos (won't because macbooks are the best hardware I can get)
- stop using emacs
- keep suffering
currently I'm doing #3, but I soon need to make the hard call and swallow the pill.
What will my next editor be? Zed? NeoVim? write my own? Is there any other lisp/emacs like editor?
EDIT: helix looks cool
though i highly recommend writing your own editor. there aren't really any editors out there that can provide what emacs can provide someone who's been using it for almost a decade.
edit: I forgot to mention the most important thing, I am talking about using neovim
All that being said, Emacs has always worked pretty well for me on Mac. I use Emacs and PDFgrep to spelunk through multi-GBs of PDFs and it is faster than almost anything else.
> GNU Emacs is an old-school C program emulating a 1980s Symbolics Lisp Machine emulating an old-fashioned Motif-style Xt toolkit emulating a 1970s text terminal emulating a 1960s teletype. Compiling Emacs is a challenge. Adding modern rendering features to the redisplay engine is a miracle.
Emacs owns its main loop because, damnit, it created one before it was cool.
Hats off to any heroes who would manage to drag it, kicking and screaming, into this millennium.
[1] https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb7...
But they did! As you say yourself
> For many, this slowness won’t be a surprise. There are plenty of complaints about slowness on MacOS, especially around popular packages.
So this is some parody, describing as efficient something rather inefficient
> Because Emacs is very efficient.
> For instance, dragging a window handle - depending on the machine - could result in thousands if not millions of such events, causing allocation and reallocation of gigabytes of memory;
It seems around that time they added some processing loop that really made things sluggish.
Worst case, you just swap out the NS p pselect hack and use a w32-like separate thread. Let Emacs be Emacs and let Cocoa be Cocoa.
NS would be just as good as Windows then. Isn't that bood enough? Maybe this thread splitting is the "deep event loop surgery" the author meant? I haven't been following.
@@ -10298,7 +10298,7 @@ w32_read_registry (HKEY rootkey, Lisp_Object lkey, Lisp_Object lname) /* mingw.org's MinGW doesn't declare _dstbias. MinGW64 defines it as a macro. / #ifndef _dstbias -__MINGW_IMPORT int _dstbias; +__MINGW_IMPORT long _dstbias; #endif
/ Fix a bug in MS implementation of 'tzset'. This function should be