> I have my own data point in this discussion. Back in May, there was a long thread on Emacs-Devel about removing ns-do-applescript from the Next Step branch. The problem, according to the instigator, was that applescript runs only on macOS which is not a free operating system—although it does represent over 25% of Emacs users—and therefore ns-do-applescript should not be in Emacs.
This isn't the first time that free-software spite has led Emacs developers to disable perfectly good features. Back in 2016, Emacs developers deliberately prevented color emoji from being displayed on the macOS port because Linux (and other free software platforms) didn't support color fonts at the time.
Emacs is a GNU tool, right? Why should they be forced to merge patches that don't relate to the GNU software ecosystem? Adding Applescript compatibility means that contributors who maintain that code require proprietary hardware to fix these issues. The GNU project forbids members from spending donation money on proprietary hardware, even for debugging purposes. You're better off asking why MacOS doesn't have support for EXT4, just because "all the work is already done for them"
If color emojis and Applescript compatibility is such a huge deal, the license explicitly allows you to fork Emacs with these changes merged. Knowing MacOS developers, they'll probably even charge you for it too (which the license graciously permits as well).
> Why should they be forced to merge patches that don't relate to the GNU software ecosystem?
They don't need to. Color emoji worked by default until it was deliberately broken. AppleScript support currently exists and works; what was being proposed is that it be removed simply because it interacts with a feature which is unique to a non-free operating system.
> Adding Applescript compatibility means that contributors who maintain that code require proprietary hardware to fix these issues.
You seem to be working towards the conclusion that Free Software should only be usable within a fully Free environment, which is pretty thoroughly out of step with the expectations and requirements of actual users.
> what was being proposed is that it be removed simply because it interacts with a feature which is unique to a non-free operating system.
Right. Why should the GNU maintainers be responsible for maintaining code that only executes in a proprietary runtime? If you want these features, you should petition your Emacs distributor to package it. Otherwise, this is a silly fight over who's responsible for what. GNU developers are no more responsible for ensuring MacOS compatibility than Apple is responsible for ensuring GNU compliance.
> You seem to be working towards the conclusion that Free Software should only be usable within a fully Free environment
No, but all Free Software should work as-expected in a Free environment. Mac users should be well-familiar with the advantages of writing tight-knit native software.
> Why should the GNU maintainers be responsible for maintaining code that only executes in a proprietary runtime?
It didn't need maintenance. The only reason being put forth for removing it was that it interacted with a feature of a non-free OS.
> GNU developers are no more responsible for ensuring MacOS compatibility...
I'm unsure what you're trying to say here.
Are you trying to draw a line between "GNU developers" and other developers? If so, who are those other developers?
Are you trying to suggest that the developers of GNU Emacs should start ignoring all bugs reported running their software on macOS (or Windows, for that matter) because they aren't responsible for "ensuring compatibility"? If so, who is responsible for that? Is anyone?
> No, but all Free Software should work as-expected in a Free environment.
Non sequitur. What I'm arguing here is that Free Software should not deliberately cripple itself or discard features simply to match the limitations it would have if running under a Free operating system. That sort of thing just makes Free Software look bad; it isn't going to convince anyone that life would be better with a Free operating system.
There already is a fork of Emacs for MacOS, which I and others on this site have been using for many years (me since 2010) because this isn't the first time the Emacs project has neglected or outright sabotaged Emacs on MacOS:
One time (roughly 2012) FSF Emacs was in such a bad state that you couldn't interact with it at all: it would display as small, un-resizable window, but nothing I did would cause anything sensible to appear inside the window.
Whether `ls` is the BSD-derived ls that is shipped with MacOS or GNU ls has effects on how well Dired works, and a similar thing applies for M-x grep and M-x compile, but coreutils has no bearing on whether Emacs can successfully draw a window (frame in Emacs terminology) on the screen that is functional enough to, e.g., echo the user's keystrokes.
I know that because I used to have GNU coreutils installed on my Mac, then I was a Linux user for a little while, and now I am back on a different Mac, but I have yet to bother installing GNU coreutils on this Mac and I notice no difference. Also, I've been using Emacs since 1991.
But yes, I am almost sure I had GNU coreutils installed when I had the very pathological problems with FSF Emacs circa 2012.
This isn't the first time that free-software spite has led Emacs developers to disable perfectly good features. Back in 2016, Emacs developers deliberately prevented color emoji from being displayed on the macOS port because Linux (and other free software platforms) didn't support color fonts at the time.
http://xahlee.info/emacs/misc/emacs_macos_emoji.html