7 ms·

Emacs: The macOS Bug

157 points by xlii 1y ago

hollerith 1y ago
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.
- deafpolygon 1y ago
  that kind of inflexible ideology is one of the reasons why i avoid emacs in general
  - exe34 1y ago
    Tbh I'd avoid MacOS if I can't run emacs on it.
    - Jtsummers 1y ago
      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.
      - ergonaught 1y ago
        ~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.
        kstrauser 1y ago
        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.
    - f1shy 1y ago
      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
  - worik 1y ago
    "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....
- uludag 1y ago
  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.
  - hollerith 1y ago
    I used Emacs on OS X (for 10 years, ending 4.5 y ago). Have you?
    - jrockway 1y ago
      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.)
      - cobbal 1y ago
        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 http://xahlee.info/emacs/misc/emacs_macos_emoji.html
        karthink 1y ago
        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.
- PaulDavisThe1st 1y ago
  Aquamacs, which IME is the best GNU Emacs for macOS, is already a fork.
anthk 1y ago
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...
rahen 1y ago
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 https://appetrosyan.github.io/posts/emacs-widget Hopefully, similar improvements can address the issues with large locks and the lack of proper threading.
- fiddlerwoaroof 1y ago
  I wonder how hard it would be to run the pgtk version on macOS
  - flylikeabanana 1y ago
    I run emacs on MacOS specifying the `emacs-pgtk` build in my Nix config as the package. Seems to work quite well for me
- tsujp 1y ago
  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.
  - 3836293648 1y ago
    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)
jrockway 1y ago
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.
- st3fan 1y ago
  Emacs in a terminal is the best.
  - worik 1y ago
    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....
- MintPaw 1y ago
  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.
- benreesman 1y ago
  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?
kkylin 1y ago
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]
- kkylin 1y ago
  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.
dwb 1y ago
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/msg00290.html https://lists.gnu.org/archive/html/emacs-devel/2025-07/msg00...
lygaret 1y ago
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 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75275#83 [brew]: https://github.com/d12frosted/homebrew-emacs-plus/compare/master...lygaret:homebrew-emacs-plus:master https://github.com/d12frosted/homebrew-emacs-plus/compare/ma...
- semi-extrinsic 1y ago
  Another example, if you run gunicorn with --preload on Macos, you need to export OBJC_DISABLE_INITIALIZE_FORK_SAFETY and some shenanigans.
LooseMarmoset 1y ago
> Emacs: The macOS Bug I feel like there’s a vi joke in this submission subject…
algo_lover 1y ago
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
- mort96 1y ago
  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
- shakow 1y ago
  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/ https://helix-editor.com/
  - xlii 1y ago
    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.
  - algo_lover 1y ago
    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.
rayiner 1y ago
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.
- krackers 1y ago
  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?
  - rayiner 1y ago
    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.m https://github.com/emacs-mirror/emacs/blob/master/src/nsterm...
    - krackers 1y ago
      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.
deleted 1y ago
[deleted]
LanternLight83 1y ago
[flagged]
eviks 1y ago
> 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;
mattlangston 1y ago
fwiw I live in [macOS emacs](https://emacsformacosx.com/ 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.
- e40 1y ago
  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.
- m463 1y ago
  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.
- donaldihunter 1y ago
  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.
quotemstr 1y ago
> 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.
vim-guru 1y ago
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
bitwize 1y ago
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.

157 points by xlii 1y ago

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.

deafpolygon 1y ago
that kind of inflexible ideology is one of the reasons why i avoid emacs in general
- exe34 1y ago
  Tbh I'd avoid MacOS if I can't run emacs on it.
  - Jtsummers 1y ago
    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.
    - ergonaught 1y ago
      ~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.
      - kstrauser 1y ago
        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.
  - f1shy 1y ago
    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
- worik 1y ago
  "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....
uludag 1y ago
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.
- hollerith 1y ago
  I used Emacs on OS X (for 10 years, ending 4.5 y ago). Have you?
  - jrockway 1y ago
    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.)
    - cobbal 1y ago
      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 http://xahlee.info/emacs/misc/emacs_macos_emoji.html
      - karthink 1y ago
        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.
PaulDavisThe1st 1y ago
Aquamacs, which IME is the best GNU Emacs for macOS, is already a fork.

anthk 1y ago

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...

rahen 1y ago

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 https://appetrosyan.github.io/posts/emacs-widget Hopefully, similar improvements can address the issues with large locks and the lack of proper threading.

fiddlerwoaroof 1y ago
I wonder how hard it would be to run the pgtk version on macOS
- flylikeabanana 1y ago
  I run emacs on MacOS specifying the `emacs-pgtk` build in my Nix config as the package. Seems to work quite well for me
tsujp 1y ago
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.
- 3836293648 1y ago
  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)

jrockway 1y ago

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.

st3fan 1y ago
Emacs in a terminal is the best.
- worik 1y ago
  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....
MintPaw 1y ago
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.
benreesman 1y ago
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?

kkylin 1y ago

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]

kkylin 1y ago
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.

dwb 1y ago

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/msg00290.html https://lists.gnu.org/archive/html/emacs-devel/2025-07/msg00...

lygaret 1y ago

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 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75275#83 [brew]: https://github.com/d12frosted/homebrew-emacs-plus/compare/master...lygaret:homebrew-emacs-plus:master https://github.com/d12frosted/homebrew-emacs-plus/compare/ma...

semi-extrinsic 1y ago
Another example, if you run gunicorn with --preload on Macos, you need to export OBJC_DISABLE_INITIALIZE_FORK_SAFETY and some shenanigans.

LooseMarmoset 1y ago

> Emacs: The macOS Bug I feel like there’s a vi joke in this submission subject…

algo_lover 1y ago

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

mort96 1y ago
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
shakow 1y ago
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/ https://helix-editor.com/
- xlii 1y ago
  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.
- algo_lover 1y ago
  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.

rayiner 1y ago

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.

krackers 1y ago
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?
- rayiner 1y ago
  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.m https://github.com/emacs-mirror/emacs/blob/master/src/nsterm...
  - krackers 1y ago
    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.

deleted 1y ago

[deleted]

LanternLight83 1y ago

[flagged]

eviks 1y ago

> 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;

mattlangston 1y ago

fwiw I live in [macOS emacs](https://emacsformacosx.com/ 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.

e40 1y ago
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.
m463 1y ago
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.
donaldihunter 1y ago
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.

quotemstr 1y ago

> 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.

vim-guru 1y ago

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

bitwize 1y ago

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.