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.
I'm not sure if I understood the issue right, but if the issue is with the runloop, I think you can technically reimplement it yourself with nextEventMatchingMask.
But their design just seems broken, if they're re-initializing the graphics context on every runloop iteration?
That’s what nsterm.m uses. As far as I can tell, the problem is that nextEventMatchingMask needs to be called from the NSApp main loop. But calling NSApplication:run blocks and takes over the main loop, which doesn’t work with for Emacs.
So what Emacs does is keep control of its own main loop. It has a select() that listens for events, and then calls NSApplication:run in the event handler. Emacs’s implementation of run() processes all pending events and then exits and returns control to the real Emacs main loop. So every keystroke or timer event in Emacs invokes setting up and tearing down the entire NSApplication main loop.
Hm I'm still not sure I understand what you mean by "sets up and tears down the entire main loop". Even in normal cocoa applications every keystroke or input event causes an event to be dispatched from WindowServer to the application which gets handled by the runloop. The expectation of course is that you never do any blocking work on this runloop. nextEventMatchingMask doesn't have to block, you can have it return if there are no events that need to be processed so it can integrate with your own runloop (of course bypassing [NSApplication run] and implementing the runloop yourself this way is discouraged, but I don't think it's forbidden)
The model of "slurp some events from a queue-like thing, throw some drawing at another queue-like thing, then wait for another event" is precisely what [NSApplication run] already implements. Per Apple
>A Cocoa application is event driven: It fetches an event from the queue, dispatches it to an appropriate object, and, after the event is handled, fetches the next event. With some exceptions (such as modal event loops) an application continues in this pattern until the user quits it.
Yeah I can't see it tearing down the message pipe, that would exit the app.
But what it is doing is first posting a message that will call `[NSApp stop]` then calling `[NSApp run]`. Which is odd, because `[NSApp nextEvent]` exists, but even if that doesn't work it's not the way I'd do it. However I'm sure there are very good reasons to do it this way when you know the emacs source.
With an old and conservative project like Emacs, the reason could just as likely be that it was done that way for the NEXTSTEP port in the early 90s and that nobody revisited it since then. Oftentimes the reason is just legacy, limited manpower and "don't fix what ain't broken".
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.
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...
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.
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 used to use that version of emacs, but performance issues on my Mac Studio made using it just untenable. I switched to Homebrew's "emacs-plus" which does not suffer, for whatever reason, the same performance issue. Based on TFA, I'm somewhat baffled as to why, but I can't argue with results.
> 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;
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!
> 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
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...
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.
I think this is a uncharitable take. I don't feel at all that the maintainers have this level of disdain for non-free OSes. Just type C-h n and you can see work done for non-free OSes (e.g. "'NSSpeechRecognitionUsageDescription' now included in "Info.plist" (macOS).")
I don't think there'd be pushback on bug fixes. I think it's only new features that would only exist on macOS that get pushback.
As someone who have tried upstreaming a patch for Emacs on macOS (to add a feature that already existed on Linux), I can bitterly say that at least some of the maintainers do have a disdain for non-free OSes and that it makes it contributing patches for macOS as miserable as possible.
The patch was adding xwidget webkit support for macOS Cocoa[0], which I iterated for the next few months[1], only to side-rail into a discussion on macOS/GCC and GNUStep support policy[2], and I fizzled out.
That was abt 5 years ago, and I’ve never touched on the Emacs codebase since.
> If you're wondering what was controversial about the patch, GNU guidelines discourage adding features targeting non-free operating systems before it can be made available for GNU/Linux. While the patch could be easily reworked to expose the native capabilities available for each platform, there's plenty of room for interpretation as to whether a rework is considered enough to satisfy the guideline. Most of the discussion was centered around this topic. Once the thread was refocused around shaping the patch, I received super constructive feedback and the patch was indeed reworked to cater for different platforms. We also agreed to rename the feature from "share" to "send". To my surprise, even RMS also chimed in on the patch discussion. Achievement unlocked?!
Almost actually. My nine year anniversary is coming up this November. Obviously the experience isn't perfect (like the article mentions), but it's perfectly usable.
You don't have to look hard to see that the Emacs maintainers aren't actively hostile to non-free OSes. Android is another good example. The Emacs manual states "it must be necessary to consider Android proprietary software from a practical standpoint." and yet a good amount of work went in to adding support for Android.
I have. Emacs has never felt actively hostile to me. Rather (as I describe above), running Emacs with a window system has always felt a little jank... free OS or otherwise. (Honestly, Windows is where I've had the best experience.)
Specific example: for a while, color emoji worked on macOS emacs perfectly. Then it was decided that since linux couldn't support it, it needed to be disabled on macOS, or else people might want to use a non-free system. It was removed for many years.
Is there _any_ other example? For years now, this is the only one I've ever seen brought up to support this point.
On the other side, there are many MacOS-specific features supported by Emacs, with the recently added dictation support being one of them. If a MacOS feature is missing, it's much more likely to be due to a lack of manpower than a desire to maintain feature parity with Linux.
For the entire 10 years I was a Mac user, a Japanese professor named Mitsuharu maintained a fork of Emacs with MacOS-specific features. I never came across any explanation for why the Emacs project didn't accept his changes (i.e., why he needed to maintain his own fork) other than some maintainers' wanting to discourage the use of non-Free OSes.
The good news is that this fork was very competently maintained, so I had a good experience in Emacs on OS X.
The 2 or 3 times I tried "vanilla" Emacs (the one published on fsf.org) it had bugs that weren't present in Mitsuharu Emacs. One of those times vanilla Emacs did not work at all: it displayed a window, but the window was very small (i.e., incapable of displaying more than a few characters) and the usual ways of enlarging a windows on OS X had no effect. My (typing blindly) evalling (set-frame-parameter frame 'fullscreen 'maximized) also had no effect.
The homebrew package named "emacs" got you vanilla Emacs. To get Mitsuharu Emacs, you needed to install the homebrew package named "emacs-mac" instead.
Maybe vanilla Emacs got better on OS X during the past 4.5 years. I haven't had access to a Mac during that time.
I have my own story over here[0], and I’m pretty sure that there’s going to be a lot of instances similar to what I’ve experienced — blocked from merging or just fizzling out due to the lack of push on features that work on non-free OSes. There’s a reason why there are so many forks and patches for Emacs on macOS that are maintained for years that are not getting upstreamed.
This is the only one that has bitten me personally, but I probably only noticed it because it was working and then taken away. I just assume there are more instances where something was never implemented in the first place for a political reason.
Edit: I also remember hearing that for a long time an ffi was forbidden because someone could use it to call proprietary software. Don't have a source on that one though.
I've used emacs nearly daily, most of that time with emacs --daemon and computer uptimes measured in months, on macOS (nee OS X) for nearly 20 years. It works fine. I've never encountered whatever issue this post is about in all that time. I cannot think of an instance when emacs froze up on me.
~22 years of daily Emacs on MacOS, and never encountered (or never noticed) it, either. Perhaps a build issue. I think my Linux builds may run slightly better, and Windows slightly worse, but I haven't had a problem on Mac in decades.
Thirded. I don't doubt that some people have problems with it. Software that runs on lots of differently-configured and -maintained systems will do that. However, I don't think that's the common case. I wouldn't say I've never had problems, but they've been rare and minor inconveniences at most.
The funny thing is I bought a mac some years ago because Emacs was installed by default. Sadly does bot come anymore installed, probably because of bad support
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?
Just out of curiosity, what issue did you encounter? I have a quite customized emacs, and the only lag I really notice between Linux and macOS is in magit, where operations are noticeably slower.
> What will my next editor be?
Fancy giving a shot to Helix[0]? Not even is it pretty good out of the box, it has a scheme extension language in the work.
helix looks cool and the scheme PR open with STEEL looks quite at home for me. I'll check it out, Thanks!
There is a plugin I can't live without: aggressive-indent, and it is awfully slow for me. I don't use any emacs distributions like doom, everything is hand rolled yet my keystrokes are noticeably slower than any other place.
Sometimes random operations like projectile get slow down, sometimes I'm stuck hitting c-g multiple times, it keeps popping up every now and then.
I need to restart emacs once every week because things tend to get slow by then.
And yes, magit is the slowest of them all. I've spent weeks trying to debug and fix magit but it's so slow for me. I am a magit power user despite all the jank, because it really gives me superpower.
Emacs has made me a much better developer, both because of repl driven development, and by making me grok how much power you can wield when you can mold an editor to your needs.
Switching from emacs to something else will be a long and arduous journey for me, but I can't live with the jank anymore as I get frustrated by it almost every day.
How about Emacs in the terminal? Now I'm a lowly neovim user so I don't know what I'm missing but I feel like I get on fine without a graphical web browser in my text editor or whatever Emacs people use the GUI mode for
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.
Yeah I'm a 20 year emacs user in the same boat. Kinda curious what the learning curve is like going from emacs keybindings to vim style modal editing. Bonus points if Dvorak typists can tell me what they do because I've been sadly typing in Dvorak for even longer than I've been using emacs.
As a Dvorak typist and Emacs user (repented from using Vim in the past), when I need to use a vi-like I just use the standard key bindings. Nothing good comes from rebinding keys in my opinion. But the way my brain works is by remembering that scroll down in Vim is Control + D and my fingers remember where Control and D are located on the keyboard.
I was an Emacs user for many years. I used it to write my papers and dissertation (AUCTeX mode was great), and a huge amount of code.
I switched to Vim, and later to NeoVim. I'd highly recommend it.
It's scriptable, and these days is scriptable in multiple "real" programming languages. It took some getting used to, but I found myself going faster in vim than I ever did in Emacs.
You might find https://vim-adventures.com/ fun for learning some of the basics. In particular, it's worth spending time learning the motion commands "in the small", because you'll spend a lot of time using them. For instance:
t (up to character) and f (up to and including character)
i( (inside parens, works with [ or < or ", or p for paragraph)
a( (same thing but includes the delimiters).
Things like that are extremely worth learning, in part because they're the "nouns" in vim's verb-noun editing model, so you'll use them in many different commands.
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?
I liked emacs, still use it for a lot of things, but the instantly tinkering and changing got to me. Took longer to set something up to work how I wanted than to do the thing.
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
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.
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.
Yeah, that is one of the main reasons I don't use emacs in a terminal much (the main exception being that I use emacsclient with -t for terminal mode as $EDITOR and for quick editing). Some key bindings just don't work properly.
The reason is listed at the bottom of the page: "You can't type C-M-% on the terminal is because C-% is not part of the standard control codes." This page lists the standard control codes https://en.wikipedia.org/wiki/C0_and_C1_control_codes (e.g., `^_`). There are only a few special characters that are recognized by a terminal with control (while all the letter keys are [although I think shift and lowercase are combined?]).
Everything is recognized with the meta, because meta just sends an escape sequence followed by the key code for the other characters.
With all that said, there are thousands of reasons it could be working for you "it's just software" so anything can be programmed, but I'm not aware of say a terminal spec that supports more control codes. Usually when this works it's because the user has implemented one of the many workarounds available online (e.g., change the terminal emulator to send a different key code, and change Emacs to use that key code for the command). It's also possible the terminal emulator you're using has custom support built-in specially for Emacs.
I could fix this myself if I wanted to, but I've just found it's better for my sanity to work with terminal emulators as a clear spec (which includes only the limited set of control character codes) rather than work against that. For an example of how much work this can be to maintain, this is fixing all the discrepancies I've found in Alacritty where it doesn't send the correct key code by default https://github.com/robenkleene/Dotfiles/blob/4d06e9855465c00... I mainly did that to make terminal Emacs usable in Alacritty.
With all that said, if you have another terminal emulator handy, I'd be super curious if it works with that one as well.
Regarding your last sentence, I don't know the answer. If you really want to find out I would make an educated guess that it is one of the more feature-rich modern terminal applications (like kitty, wezterm, alacritty, ghostty)
Oh it's also possible it's triggering `M-%` instead of `C-M-%`, `M-%` definitely usually works (just an escape sequence followed by percent character). `C-h k` followed by the binding will of course show what command is triggered, `M-%` is the non-regex variant `query-replace`.
It depends on what you're trying to use it for. If you just use Emacs for coding, you're not going to gain anything from running it in a GUI. However, if you also use it to read documentation, take notes, etc.; being able to display images, different fonts, different sized fonts, etc. is pretty nice.
Just a heads up, in 2025 the mouse and trackpad work incredibly well with TUI applications. There are days I think the mouse works even better than with GUI applications because it tends to be easier to select any text on the screen than with a GUI. To be clear, I love both (TUI & GUI), but when I started integrating the mouse more into my terminal workflow, I was shocked at how well it worked.
Can you move point to a position by clicking that position with a pointing device?
Also, when you've selected some text with the pointing device, does Emacs sense the selection? I.e., does (list (region-beginning) (region-end)) return the start and end of the selection?
Before writing my comment, I started Emacs as `emacs -nw` in Gnome Terminal and failed to find a way to move point with my mouse. If there is any additional configuration I need to do to Emacs or a different terminal-emulating app I need to install, I'd be glad to learn about it.
I didn't mean to suggest that pointing devices are completely useless in a terminal, but it has always been my experience that what the device can do is severely limited compared to graphical Emacs.
I made the opposite choice with Vim, opting to always use GVim instead of the terminal. I was never able to set up terminal colors and mouse compatibility just right, and at 4k Gnome terminal would lag a bit. Terminals use windowing systems too. :P
This was 10 years ago though, before Kitty and the new Windows Terminal.
The fact that Emacs is happy in the terminal is what keeps me in Emacs and away from GUI editors that come and go over the years - that and Emacs' longevity....
I started on vim and hopping back and forth between my editor and my terminal is just some muscle memory that I cannot break - so I too have always run emacs in the terminal ever since I made the switch.
I've been meaning to switch to GUI emacs for 15 years, I usually have it working, vterm is nifty... but it just works great in the terminal and with terminals getting SO FUCKING GREAT lately, eh, is it really an upgrade? WezTerm and ghostty on Wayland with no X jank? Accelerated, ligatures, mouse and keyboard clipboard integration, high-DPI...
With a font like "Input Sans" you can fit about +30% more code on the same screen unless you're too pixel starved.
Terminal can't do non-monospace.
And even if it's just that I want character width to scale slightly with font weight...
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.
[1] https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb7...
I'm not sure if I understood the issue right, but if the issue is with the runloop, I think you can technically reimplement it yourself with nextEventMatchingMask.
But their design just seems broken, if they're re-initializing the graphics context on every runloop iteration?
That’s what nsterm.m uses. As far as I can tell, the problem is that nextEventMatchingMask needs to be called from the NSApp main loop. But calling NSApplication:run blocks and takes over the main loop, which doesn’t work with for Emacs.
So what Emacs does is keep control of its own main loop. It has a select() that listens for events, and then calls NSApplication:run in the event handler. Emacs’s implementation of run() processes all pending events and then exits and returns control to the real Emacs main loop. So every keystroke or timer event in Emacs invokes setting up and tearing down the entire NSApplication main loop.
The relevant code is ns_select_1 in nsterm.m, line 5102. https://github.com/emacs-mirror/emacs/blob/master/src/nsterm...
Hm I'm still not sure I understand what you mean by "sets up and tears down the entire main loop". Even in normal cocoa applications every keystroke or input event causes an event to be dispatched from WindowServer to the application which gets handled by the runloop. The expectation of course is that you never do any blocking work on this runloop. nextEventMatchingMask doesn't have to block, you can have it return if there are no events that need to be processed so it can integrate with your own runloop (of course bypassing [NSApplication run] and implementing the runloop yourself this way is discouraged, but I don't think it's forbidden)
The model of "slurp some events from a queue-like thing, throw some drawing at another queue-like thing, then wait for another event" is precisely what [NSApplication run] already implements. Per Apple
>A Cocoa application is event driven: It fetches an event from the queue, dispatches it to an appropriate object, and, after the event is handled, fetches the next event. With some exceptions (such as modal event loops) an application continues in this pattern until the user quits it.
Yeah I can't see it tearing down the message pipe, that would exit the app.
But what it is doing is first posting a message that will call `[NSApp stop]` then calling `[NSApp run]`. Which is odd, because `[NSApp nextEvent]` exists, but even if that doesn't work it's not the way I'd do it. However I'm sure there are very good reasons to do it this way when you know the emacs source.
With an old and conservative project like Emacs, the reason could just as likely be that it was done that way for the NEXTSTEP port in the early 90s and that nobody revisited it since then. Oftentimes the reason is just legacy, limited manpower and "don't fix what ain't broken".
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.
https://appetrosyan.github.io/posts/emacs-widget
Hopefully, similar improvements can address the issues with large locks and the lack of proper threading.
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.
It's not just slow, it's also broken.
Maybe broken is the wrong word, but it handles chained chords differently and it breaks my workflow at least.
(C-s s C-s for instance needs you to release and press S again when lucid doesn't need it)
I wonder how hard it would be to run the pgtk version on macOS
I run emacs on MacOS specifying the `emacs-pgtk` build in my Nix config as the package. Seems to work quite well for me
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...
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.)
[edited slightly for clarity]
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.
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 used that too, but have held back at 27.2 because all the following versions have been significantly slower.
It seems around that time they added some processing loop that really made things sluggish.
I used to use that version of emacs, but performance issues on my Mac Studio made using it just untenable. I switched to Homebrew's "emacs-plus" which does not suffer, for whatever reason, the same performance issue. Based on TFA, I'm somewhat baffled as to why, but I can't argue with results.
> 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;
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!
[bug]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75275#83 [brew]: https://github.com/d12frosted/homebrew-emacs-plus/compare/ma...
Another example, if you run gunicorn with --preload on Macos, you need to export OBJC_DISABLE_INITIALIZE_FORK_SAFETY and some shenanigans.
> 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
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...
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.
I think this is a uncharitable take. I don't feel at all that the maintainers have this level of disdain for non-free OSes. Just type C-h n and you can see work done for non-free OSes (e.g. "'NSSpeechRecognitionUsageDescription' now included in "Info.plist" (macOS).")
I don't think there'd be pushback on bug fixes. I think it's only new features that would only exist on macOS that get pushback.
As someone who have tried upstreaming a patch for Emacs on macOS (to add a feature that already existed on Linux), I can bitterly say that at least some of the maintainers do have a disdain for non-free OSes and that it makes it contributing patches for macOS as miserable as possible.
The patch was adding xwidget webkit support for macOS Cocoa[0], which I iterated for the next few months[1], only to side-rail into a discussion on macOS/GCC and GNUStep support policy[2], and I fizzled out.
That was abt 5 years ago, and I’ve never touched on the Emacs codebase since.
[0]: https://lists.gnu.org/archive/html/emacs-devel/2019-05/msg00...
[1]: https://lists.gnu.org/archive/html/emacs-devel/2019-07/threa...
[2]: https://lists.gnu.org/archive/html/emacs-devel/2019-08/msg00...
>I think it's only new features that would only exist on macOS that get pushback
Not even that anymore, it seems. https://xenodium.com/emacs-send-to-aka-macos-sharing-merged-...
I mean, pretty much exactly that.
> If you're wondering what was controversial about the patch, GNU guidelines discourage adding features targeting non-free operating systems before it can be made available for GNU/Linux. While the patch could be easily reworked to expose the native capabilities available for each platform, there's plenty of room for interpretation as to whether a rework is considered enough to satisfy the guideline. Most of the discussion was centered around this topic. Once the thread was refocused around shaping the patch, I received super constructive feedback and the patch was indeed reworked to cater for different platforms. We also agreed to rename the feature from "share" to "send". To my surprise, even RMS also chimed in on the patch discussion. Achievement unlocked?!
I used Emacs on OS X (for 10 years, ending 4.5 y ago). Have you?
Almost actually. My nine year anniversary is coming up this November. Obviously the experience isn't perfect (like the article mentions), but it's perfectly usable.
You don't have to look hard to see that the Emacs maintainers aren't actively hostile to non-free OSes. Android is another good example. The Emacs manual states "it must be necessary to consider Android proprietary software from a practical standpoint." and yet a good amount of work went in to adding support for Android.
I have. Emacs has never felt actively hostile to me. Rather (as I describe above), running Emacs with a window system has always felt a little jank... free OS or otherwise. (Honestly, Windows is where I've had the best experience.)
Specific example: for a while, color emoji worked on macOS emacs perfectly. Then it was decided that since linux couldn't support it, it needed to be disabled on macOS, or else people might want to use a non-free system. It was removed for many years.
http://xahlee.info/emacs/misc/emacs_macos_emoji.html
Is there _any_ other example? For years now, this is the only one I've ever seen brought up to support this point.
On the other side, there are many MacOS-specific features supported by Emacs, with the recently added dictation support being one of them. If a MacOS feature is missing, it's much more likely to be due to a lack of manpower than a desire to maintain feature parity with Linux.
For the entire 10 years I was a Mac user, a Japanese professor named Mitsuharu maintained a fork of Emacs with MacOS-specific features. I never came across any explanation for why the Emacs project didn't accept his changes (i.e., why he needed to maintain his own fork) other than some maintainers' wanting to discourage the use of non-Free OSes.
The good news is that this fork was very competently maintained, so I had a good experience in Emacs on OS X.
The 2 or 3 times I tried "vanilla" Emacs (the one published on fsf.org) it had bugs that weren't present in Mitsuharu Emacs. One of those times vanilla Emacs did not work at all: it displayed a window, but the window was very small (i.e., incapable of displaying more than a few characters) and the usual ways of enlarging a windows on OS X had no effect. My (typing blindly) evalling (set-frame-parameter frame 'fullscreen 'maximized) also had no effect.
The homebrew package named "emacs" got you vanilla Emacs. To get Mitsuharu Emacs, you needed to install the homebrew package named "emacs-mac" instead.
Maybe vanilla Emacs got better on OS X during the past 4.5 years. I haven't had access to a Mac during that time.
I have my own story over here[0], and I’m pretty sure that there’s going to be a lot of instances similar to what I’ve experienced — blocked from merging or just fizzling out due to the lack of push on features that work on non-free OSes. There’s a reason why there are so many forks and patches for Emacs on macOS that are maintained for years that are not getting upstreamed.
[0]: https://news.ycombinator.com/item?id=44739359
This is the only one that has bitten me personally, but I probably only noticed it because it was working and then taken away. I just assume there are more instances where something was never implemented in the first place for a political reason.
Edit: I also remember hearing that for a long time an ffi was forbidden because someone could use it to call proprietary software. Don't have a source on that one though.
Aquamacs, which IME is the best GNU Emacs for macOS, is already a fork.
that kind of inflexible ideology is one of the reasons why i avoid emacs in general
Tbh I'd avoid MacOS if I can't run emacs on it.
I've used emacs nearly daily, most of that time with emacs --daemon and computer uptimes measured in months, on macOS (nee OS X) for nearly 20 years. It works fine. I've never encountered whatever issue this post is about in all that time. I cannot think of an instance when emacs froze up on me.
~22 years of daily Emacs on MacOS, and never encountered (or never noticed) it, either. Perhaps a build issue. I think my Linux builds may run slightly better, and Windows slightly worse, but I haven't had a problem on Mac in decades.
Thirded. I don't doubt that some people have problems with it. Software that runs on lots of differently-configured and -maintained systems will do that. However, I don't think that's the common case. I wouldn't say I've never had problems, but they've been rare and minor inconveniences at most.
The funny thing is I bought a mac some years ago because Emacs was installed by default. Sadly does bot come anymore installed, probably because of bad support
"inflexible ideology" is the dominant paradigm for Apple is it not?
Mēh! Maybe not "inflexible", more "inscrutable", very hard to discern any method to their madness....
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?
EDIT: helix looks cool
Just out of curiosity, what issue did you encounter? I have a quite customized emacs, and the only lag I really notice between Linux and macOS is in magit, where operations are noticeably slower.
> What will my next editor be?
Fancy giving a shot to Helix[0]? Not even is it pretty good out of the box, it has a scheme extension language in the work.
[0] https://helix-editor.com/
Believe it or not but I tried to use Helix when my Emacs build was completely broken.
It couldn't handle the Git repo of Emacs' size. Every keystroke took 3 seconds to process.
I found it somewhat funny. But otherwise Helix is still a great editor worth recommending.
helix looks cool and the scheme PR open with STEEL looks quite at home for me. I'll check it out, Thanks!
There is a plugin I can't live without: aggressive-indent, and it is awfully slow for me. I don't use any emacs distributions like doom, everything is hand rolled yet my keystrokes are noticeably slower than any other place.
Sometimes random operations like projectile get slow down, sometimes I'm stuck hitting c-g multiple times, it keeps popping up every now and then.
I need to restart emacs once every week because things tend to get slow by then.
And yes, magit is the slowest of them all. I've spent weeks trying to debug and fix magit but it's so slow for me. I am a magit power user despite all the jank, because it really gives me superpower.
Emacs has made me a much better developer, both because of repl driven development, and by making me grok how much power you can wield when you can mold an editor to your needs.
Switching from emacs to something else will be a long and arduous journey for me, but I can't live with the jank anymore as I get frustrated by it almost every day.
Ah I see, I personally only use electric-mode + [insert language]-format on save, so that's much lighter.
And I restart mine every 2-3 days, so it doesn't have that much time to get slowed down.
Have you tried installing the latest version of git via homebrew? I found it to be noticeably faster.
How about Emacs in the terminal? Now I'm a lowly neovim user so I don't know what I'm missing but I feel like I get on fine without a graphical web browser in my text editor or whatever Emacs people use the GUI mode for
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.
> Is there any other lisp/emacs like editor?
There is Lem, an Emacs- like editor written in Common Lisp, which seems quite active.
Yeah I'm a 20 year emacs user in the same boat. Kinda curious what the learning curve is like going from emacs keybindings to vim style modal editing. Bonus points if Dvorak typists can tell me what they do because I've been sadly typing in Dvorak for even longer than I've been using emacs.
As a Dvorak typist and Emacs user (repented from using Vim in the past), when I need to use a vi-like I just use the standard key bindings. Nothing good comes from rebinding keys in my opinion. But the way my brain works is by remembering that scroll down in Vim is Control + D and my fingers remember where Control and D are located on the keyboard.
I was an Emacs user for many years. I used it to write my papers and dissertation (AUCTeX mode was great), and a huge amount of code.
I switched to Vim, and later to NeoVim. I'd highly recommend it.
It's scriptable, and these days is scriptable in multiple "real" programming languages. It took some getting used to, but I found myself going faster in vim than I ever did in Emacs.
You might find https://vim-adventures.com/ fun for learning some of the basics. In particular, it's worth spending time learning the motion commands "in the small", because you'll spend a lot of time using them. For instance:
t (up to character) and f (up to and including character)
i( (inside parens, works with [ or < or ", or p for paragraph)
a( (same thing but includes the delimiters).
Things like that are extremely worth learning, in part because they're the "nouns" in vim's verb-noun editing model, so you'll use them in many different commands.
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?
I liked emacs, still use it for a lot of things, but the instantly tinkering and changing got to me. Took longer to set something up to work how I wanted than to do the thing.
Try Doom Emacs with native-comp enabled - it significantly reduces the macOS jank while preserving your Emacs workflow and keybindings.
option 1 - run your dev env in a linux vm
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
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.
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.
Some Emacs bindings don't work in the terminal, a big example is `C-M-%` , `query-replace-regexp` https://stackoverflow.com/questions/71302860/emacs-terminal-... to do a regex find and replace.
Yeah, that is one of the main reasons I don't use emacs in a terminal much (the main exception being that I use emacsclient with -t for terminal mode as $EDITOR and for quick editing). Some key bindings just don't work properly.
Works fine for me. Is it your terminal configuration that needs tweaking?
The reason is listed at the bottom of the page: "You can't type C-M-% on the terminal is because C-% is not part of the standard control codes." This page lists the standard control codes https://en.wikipedia.org/wiki/C0_and_C1_control_codes (e.g., `^_`). There are only a few special characters that are recognized by a terminal with control (while all the letter keys are [although I think shift and lowercase are combined?]).
Everything is recognized with the meta, because meta just sends an escape sequence followed by the key code for the other characters.
With all that said, there are thousands of reasons it could be working for you "it's just software" so anything can be programmed, but I'm not aware of say a terminal spec that supports more control codes. Usually when this works it's because the user has implemented one of the many workarounds available online (e.g., change the terminal emulator to send a different key code, and change Emacs to use that key code for the command). It's also possible the terminal emulator you're using has custom support built-in specially for Emacs.
I could fix this myself if I wanted to, but I've just found it's better for my sanity to work with terminal emulators as a clear spec (which includes only the limited set of control character codes) rather than work against that. For an example of how much work this can be to maintain, this is fixing all the discrepancies I've found in Alacritty where it doesn't send the correct key code by default https://github.com/robenkleene/Dotfiles/blob/4d06e9855465c00... I mainly did that to make terminal Emacs usable in Alacritty.
With all that said, if you have another terminal emulator handy, I'd be super curious if it works with that one as well.
Regarding your last sentence, I don't know the answer. If you really want to find out I would make an educated guess that it is one of the more feature-rich modern terminal applications (like kitty, wezterm, alacritty, ghostty)
Oh it's also possible it's triggering `M-%` instead of `C-M-%`, `M-%` definitely usually works (just an escape sequence followed by percent character). `C-h k` followed by the binding will of course show what command is triggered, `M-%` is the non-regex variant `query-replace`.
It depends on what you're trying to use it for. If you just use Emacs for coding, you're not going to gain anything from running it in a GUI. However, if you also use it to read documentation, take notes, etc.; being able to display images, different fonts, different sized fonts, etc. is pretty nice.
>If you just use Emacs for coding, you're not going to gain anything from running it in a GUI.
That's true only if you think pointing devices are useless for editing and navigating code.
ADDED: I withdraw this comment.
Just a heads up, in 2025 the mouse and trackpad work incredibly well with TUI applications. There are days I think the mouse works even better than with GUI applications because it tends to be easier to select any text on the screen than with a GUI. To be clear, I love both (TUI & GUI), but when I started integrating the mouse more into my terminal workflow, I was shocked at how well it worked.
Can you move point to a position by clicking that position with a pointing device?
Also, when you've selected some text with the pointing device, does Emacs sense the selection? I.e., does (list (region-beginning) (region-end)) return the start and end of the selection?
Yes and yes, I don't think there are any mouse issues I've had working with Emacs in the terminal (whereas there are tons of bindings issues).
I had no idea! Wow.
What terminal are you using that doesn't support a mouse? Or is it emacs that doesn't have mouse support?
Before writing my comment, I started Emacs as `emacs -nw` in Gnome Terminal and failed to find a way to move point with my mouse. If there is any additional configuration I need to do to Emacs or a different terminal-emulating app I need to install, I'd be glad to learn about it.
I didn't mean to suggest that pointing devices are completely useless in a terminal, but it has always been my experience that what the device can do is severely limited compared to graphical Emacs.
Looking at my config quickly, I think you probably need this:
(xterm-mouse-mode 1)
Or simply upgrade to the top of tree version of Emacs that now has native mouse support in the terminal.
Native UI integrations are pretty nice. For example, native sharing/send-to was recently merged https://xenodium.com/emacs-send-to-aka-macos-sharing-merged-...
I made the opposite choice with Vim, opting to always use GVim instead of the terminal. I was never able to set up terminal colors and mouse compatibility just right, and at 4k Gnome terminal would lag a bit. Terminals use windowing systems too. :P
This was 10 years ago though, before Kitty and the new Windows Terminal.
Emacs in a terminal is the best.
The fact that Emacs is happy in the terminal is what keeps me in Emacs and away from GUI editors that come and go over the years - that and Emacs' longevity....
I started on vim and hopping back and forth between my editor and my terminal is just some muscle memory that I cannot break - so I too have always run emacs in the terminal ever since I made the switch.
I've been meaning to switch to GUI emacs for 15 years, I usually have it working, vterm is nifty... but it just works great in the terminal and with terminals getting SO FUCKING GREAT lately, eh, is it really an upgrade? WezTerm and ghostty on Wayland with no X jank? Accelerated, ligatures, mouse and keyboard clipboard integration, high-DPI...
Can GUI anything keep up?
With a font like "Input Sans" you can fit about +30% more code on the same screen unless you're too pixel starved. Terminal can't do non-monospace. And even if it's just that I want character width to scale slightly with font weight...
[flagged]
> Emacs: The macOS Bug
I feel like there’s a vi joke in this submission subject…