Hacker News Reader

Comment by uludag | Hacker News Reader

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.

View on HN

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?

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.

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.

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

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.

Reply on news.ycombinator.com