Re: Android port of Emacs

[Po Lu]

chad <yandros@gmail.com> writes:

> We've seen a couple positions put forward that I will paraphrase as "I
> personally see strong potential in Emacs for Android, although I
> don't/wouldn't really use it right away." As near as I can tell, these
> positions are tangential to Eli's point which I will summarize as "The
> Android port is great, and we should probably give it _some_ support,
> but maybe that level is lower than everything expressed and implied by
> incorporating it directly into the mainline emacs repository?"

Incorporating code in Emacs doesn't mean that we are obligated to
support it or keep it working, it means that we will keep it working to
the extent that interested users provide changes to do so.

i.e. the DOS port was broken between 27.1 and 28.2, but that wasn't an
obstacle to keeping the code around.  Someone eventually fixed it.

> I am personally sympathetic to both views, and (at the risk of
> forking/hijacking the thread a bit), I would even go so far as to say
> that Emacs as a project might benefit from spinning out at least the
> Android port (which is new and very maintained, but has a very high
> bus factor) and also the NS port (which is not new, shows some
> downsides of high bus-factor parts, and has at least one
> well-maintained alternative outside the mainline Emacs repo: the mac
> port).

The Mac port (Carbon Emacs) being spun off was the result of its
maintainer refusing to maintain it for Emacs 23, then refusing to
co-operate with other Emacs developers who tried to adapt it to
multi-tty, and finally realizing that its replacement, the NS port, was
severely inadequate, and backtracking on the angry decision to abandon
it.

That's not an attitude we want to encourage for future Emacs
development.

> As a technical matter, it seems like it's probably easier to maintain
> some abstraction barriers along OS and window-system code by virtue of
> having a single repo that supports 3-5 "variants", but in practice
> that _seems_ to have mostly resulted in treating a quite old
> "posix-y-unix with X11" as the baseline, and then adapting everything
> to that. This seems (again, I'm not an expert here) to have caused
> some continuing pain with respect to GTK and the pgtk port
> (particularly in the very high incidence of people using pgtk in
> wayland+X environments where it's not supported, kinda works, and
> breaks in not-so-rare corner cases).

The GNU project porting policy is to make other operating systems (MS
Windows, VMS, MVS, etc) look like Unix.  And the reason X is treated as
the canonical window system is that X is a superset of every other
window system: it provides all their features, and then some more.

Problems with PGTK stem from the negligence of the GTK developers and
nothing else.

> Taking the NS port as an example, if the mainline were to drop support
> for the ns port, this would nudge some macOS users over to the mac
> port, strand some users of quite old macOS versions, and isolate the
> users of the GNUStep port. My belief is that the mac port is already
> quite popular, the people stuck on old mac OS X versions are already
> stuck with library and compiler version issues, and the GNUStep port
> has very

Those are not issues.  Emacs supports Clang 3.x and GCC 4.5.x (along
with period C libraries) just fine.

> little actual usage (I wouldn't be surprised to learn that "testing
> GNUStep support" is the single largest user-base of GNUStep" at this
> point.)

Perhaps, but then we did get one bug report from an actual user
recently.