[HN Gopher] Emacs: The macOS Bug
___________________________________________________________________
Emacs: The macOS Bug
Author : xlii
Score : 78 points
Date : 2025-07-30 18:15 UTC (4 hours ago)
(HTM) web link (xlii.space)
(TXT) w3m dump (xlii.space)
| hollerith wrote:
| 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 wrote:
| that kind of inflexible ideology is one of the reasons why i
| avoid emacs in general
| exe34 wrote:
| Tbh I'd avoid MacOS if I can't run emacs on it.
| Jtsummers wrote:
| 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 wrote:
| ~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 wrote:
| 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.
| worik wrote:
| "inflexible ideology" is the dominant paradigm for Apple is
| it not?
|
| Meh! Maybe not "inflexible", more "inscrutable", very hard to
| discern any method to their madness....
| uludag wrote:
| 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 wrote:
| I used Emacs on OS X (for 10 years, ending 4.5 y ago). Have
| you?
| jrockway wrote:
| 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 wrote:
| 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
| karthink wrote:
| 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.
| cobbal wrote:
| 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.
| hollerith wrote:
| 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.
| goranmoomin wrote:
| 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
| uludag wrote:
| 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.
| lvass wrote:
| >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-...
| goranmoomin wrote:
| 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...
| PaulDavisThe1st wrote:
| Aquamacs, which IME is the best GNU Emacs for macOS, is already
| a fork.
| anthk wrote:
| 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 wrote:
| 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.
| fiddlerwoaroof wrote:
| I wonder how hard it would be to run the pgtk version on macOS
| jrockway wrote:
| 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 wrote:
| Emacs in a terminal is the best.
| worik wrote:
| 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 wrote:
| 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 wrote:
| 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?
| stebalien wrote:
| 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.
| hollerith wrote:
| >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.
| iforgotpassword wrote:
| What terminal are you using that doesn't support a mouse?
| Or is it emacs that doesn't have mouse support?
| hollerith wrote:
| 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.
| robenkleene wrote:
| Looking at my config quickly, I think you probably need
| this:
|
| (xterm-mouse-mode 1)
| robenkleene wrote:
| 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.
| hollerith wrote:
| 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?
| robenkleene wrote:
| 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).
| hollerith wrote:
| I had no idea! Wow.
| pjm331 wrote:
| 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.
| robenkleene wrote:
| 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.
| xenodium wrote:
| 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-...
| kkylin wrote:
| 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]
| dwb wrote:
| 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...
| lygaret wrote:
| 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...
| semi-extrinsic wrote:
| Another example, if you run gunicorn with --preload on Macos,
| you need to export OBJC_DISABLE_INITIALIZE_FORK_SAFETY and some
| shenanigans.
| LooseMarmoset wrote:
| > Emacs: The macOS Bug
|
| I feel like there's a vi joke in this submission subject...
| algo_lover wrote:
| 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 wrote:
| 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 wrote:
| 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/
| xlii wrote:
| 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 wrote:
| 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.
| atkailash wrote:
| 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.
| setopt wrote:
| > Is there any other lisp/emacs like editor?
|
| There is Lem, an Emacs- like editor written in Common Lisp,
| which seems quite active.
| JoshTriplett wrote:
| 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.
| rayiner wrote:
| 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 wrote:
| 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?
___________________________________________________________________
(page generated 2025-07-30 23:01 UTC)