Related to the topic of "Emacs is a terminal program with lots of clever hacks to run in a GUI", I recently encountered a big problem on macOS 10.12 "Sierra", which I found reported at [1]

The crux of it is that macOS became more strict about what you were doing in GUI- vs non-GUI-threads, and now asserts if you fetch GUI events (I think?) in not the main thread, because of the risk of memory corruption. Ostensibly.

This bug only manifests if you compile Emacs on 10.12 (so if you install the "emacs-app" in MacPorts, for example), because then it'll link against the asserting framework. If you use Emacs from another source that compiles it on 10.11 (such as from https://emacsformacosx.com/), then it links against an older framework that doesn't have the assert, and it'll work "fine".

Considering the fractal accumulation of "clever hacks" that make Emacs work on modern GUI systems, I'm curious to see how this issue will be resolved, because I doubt it's something so simple where Emacs has proper separation of GUI vs non-GUI threads, as QED by the article ;)

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24678

This issue is aleady solved in Yamamoto Mitsuharu's Emacs OSX port (https://bitbucket.org/mituharu/emacs-mac) which if you use Emacs on OSX is what you should be running (rather than the "official" OSX branch).

The OSX support in the mainline Emacs repo (which emacsformacosx.com and aquamacs use) is a third class citizen, since very few people work on it and Stallman is always quick to remind the rest that Linux (sorry GNU/Linux) remains the priority rather than those pesky non-free OSes. The end result is that the official OSX Emacs is perpetually buggy (check emacs-devel, it breaks all the time) and lacks a lot of useful features that are available through new OSX APIs. To make matters worse, Stallman has demanded that _useful features be removed_ from the OSX branch, because _Linux doesn't have equivalent APIs_. It was disappointing to see them following through with these removals.

On the other hand, the Yamamoto Mitsuharu port is rock-solid, functionality is not removed cause Stallman said so, is actively worked on (Yamamoto was the old Carbon Emacs maintainer and knows what he's doing) and uses the latest OSX APIs. It has had flicker-free double-buffering for years, smooth (pixel-based) scrolling with inertia, integrated AppleScript bridge, integrated Apple event support, HiDPI, ligatures, graphics/SVG/animations through ImageKit, proper C-g handling, dictionary service support, proper fullscreen, and I could go on and on and on [1] ..

TL;DR

If you're using Emacs on OSX, you should be running Yamamoto's port.

[1] https://bitbucket.org/mituharu/emacs-mac/raw/892fa7b2501a403...

I really wish we'd just make Yamamoto's work the official OS X Emacs and merge it

I think johnw tried at some point but Yamamoto isn't very excited at the prospect, and who would really blame him? Keeping his work out of the main branch gives him the freedom he needs to focus on technical matters and introduce support for new features as they're being exposed by OSX APIs.

As long as Stallman holds sway over Emacs and can demand that one cripple his own work for _political reasons_ , I don't see this situation changing. I'm just glad that Yamamoto did not fall for the "lowest common denominator" approach and has enough pride in his own work to do things as he sees fit.

Thanks for the informative comment.

Even so, it would help if Homebrew reassigned the "emacs" package name to the Emacs fork by Yamamoto Mitsuharu.

(The way it is now, when you install with `brew install emacs`, you get FSF emacs; to get Mitsuharu Emacs, you have to know to say `brew install emacs-mac` instead.)

`brew install emacs-mac` alone didn't work for me. Solution here:

https://github.com/railwaycat/homebrew-emacsmacport