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.
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.
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.
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?
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.
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.
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
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.
Aquamacs, which IME is the best GNU Emacs for macOS, is already a fork.
that kind of inflexible ideology is one of the reasons why i avoid emacs in general
Tbh I'd avoid MacOS if I can't run emacs on it.
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.
~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.
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.
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
"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....