Comment by AceJohnny2 | Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

Parent Full thread

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

Edit: my comment below was uninformed, I see that Mituharu's port is up-do-date with Emacs 25, which is close enough to upstream for me.

Original:

Interesting! However, how closely does it follow upstream for... every other feature?

I'm using GNU Emacs because I've basically standardized my use of it across platforms. Gone are the days of XEmacs vs Emacs and all the small differences between them, and GNU Emacs' development pace has nicely picked up over the past 2-3 years since Stallman stepped down as maintainer.

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.

GNU Emacs is a political project, rooted in the free software movement. Too often people like you insult Stallman and ask for an Emacs that is a bit better technically in exchange for removing the goals of the GNU proejct. There's plenty of other software to use that cares about technical matters only.

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

Good point: instead of `brew install emacs-mac`, I should have written, `brew tap railwaycat/emacsmacport && brew install emacs-mac`.

I saw later in the thread that you're Daniel. I enjoy your emacs-devel posts and your back&forths with Eli/Stefan. I liked (and was in full agreement with) your commentary during Emacs dynamic modules dev, and I also enjoyed your recent demand paging post.

It's just too bad that you seldom get things to go your way.

Mitsuharu is amazing and have to agree that if you’re on macOS you should definitely be using his port. He’s actually already added some support for the new MacBook Pro touch bar. I've been using his port directly off his "work" branch for a good 2 years or so now and it’s always been rock solid.

No. You should be using the official emacs-x, not emacs-app, not Aquamacs, not Carbon or emacs-mac. I tried to work with them, but after a week I'll get terrible hand aches for their problematic keybindings.

The traditional x port flickers a bit, (dan just fixed it via xdbe, great!) but proper Ctrl-x, Command-x and just works as everywhere else. RMS politics are stupid, yes, but overall the official port is still the best.

Just to make sure everyone reading this can follow along: you are probably suggesting using Emacs on the X windowing system on OS X (which would of course require XQuartz to be running).

And by "problematic keybindings" you probably mean how most graphical Emacs packages on OS X use the Command modifier key to set the meta bit.

But Mitsuhara Emacs (or emacs-mac as you refer to it) lets you assign any "Emacs modifier bit" (control, meta, alt, hyper or super) to any of OS X's modifier keys (namely, control, option, command or fn) except for the shift key.

So for example if you're on a Macbook, but you are used to the key on the bottom left's being a control key, you would add (setq mac-function-modifier 'control) to your .emacs.

To use the option key as your meta key, (setq mac-option-modifier 'meta).

>The traditional x port flickers a bit

None of the other ports you mention have ever flickered in my experience. And running Emacs under X has the disadvantage that Emacs ends up looking quite different typographically than native OS X apps do.

I'm using an rMBP and the XQuartz treatment of text on there is literally painful -- simultaneously blurred and pixellated if that makes any sense. This isn't the hedonic treadmill effect with regards to the retina display as I have no problems using other systems with "standard" displays.

I agree that the latest XQuartz update forced me to try out the native emacs-app which had nicely looking fonts. But I couldn't store my selection of a good font, and the overall experience was awful. My hand still hurts.

With the latest XQuartz and emacs 25 only "Use System Font" looks good, before we had much more good fonts. Wonder what caused this regression.

This contradicts many years of my personal experience, and that of everyone I know. Yamamoto Mitsuharu's Emacs OSX port is by far better than mainline. And seriously, X on OSX? That's just insane.

You can reconfigure the keybindings however you'd like, on any version.

That's a good bug report. I haven't run Emacs on OS X (err, macOS) in ages, but I may have to start doing that once in a while soon. It's important to fix bugs like this. It's always possible to launder events between threads internally --- the w32 port of Emacs does something similar internally.

Reply on news.ycombinator.com