Re: Android port of Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 22 Jun 2023 21:47:14 -0400
> 
>   > This side-steps the issue which actually prompted me to start this
>   > thread of discussion.  The issue that bothered me is why should we
>   > commit ourselves to including a significant feature which complicates
>   > Emacs, if it might soon enough become unmaintained (due to several of
>   > its aspects I described).
> 
> I think that is a valid concern.  But if Po Lu says that he wants to keeo
> working on it and make it good enough to achieve popularity, I suggest
> that makes the effort of installing it a good investment.

For how long will that single-person support last?

We have bad experience with depending on single persons for specific
expertise in important areas.  For example, GTK was essentially
unmaintained until recently, because the one person who knew about it
resigned from Emacs maintenance.  The NS port is in that status now:
serious problems are solved only by sheer luck, if at all.

Basically, any area in Emacs that requires extensive external domain
knowledge that cannot be acquired reasonably easily by reading some
freely-available documentation, and/or that's implemented in code not
documented well enough, will become unmaintained if the single person
who currently supports it goes on to greener pasture.  (Someone
brought up redisplay and bidi as such examples, but that's false:
those are well documented in Emacs and the requisite external
knowledge is in standard documents that can be studied and understood
with reasonably small effort.  For example, if bidi.c loses its sole
maintainer, someone could study the UBA in UAX#9 and reimplement it
from scratch, using the large commentaries in bidi.c and xdisp.c as
guidance.)

When I started this discussion, I thought we'd want to learn from past
experience, and expected some discussion of how to learn from the past
and whether this case is somehow different or not.  Instead, all I
hear is that the Android port will be a useful feature (true, but
never a question in my eyes), and how we already made similar
(mistaken?) judgments in other cases.  E.g., I point out that a
significant part of the Android support is written in Java, so Emacs
maintainers will need to be proficient in Java or rely on others for
making decisions, and in response I'm told that we already have
Objective C in the NS port.  IOW: we already made similar decisions in
the past, so let's keep doing the same in the future as well.  Are we
not supposed to learn from the past?  Are we not supposed to apply
past experience to similar situations, not just reiterating the same
decision-making processes with quite probably the same outcomes?

Here we once again have a situation where a single enthusiast says
he'll be working and supporting this new useful feature indefinitely.
And we again make the same decision: if he says so, then it must be
so, and there's nothing to worry about.  The potential negative
outcomes are neglected as improbable, in direct contradiction of past
experience, which clearly says otherwise.

How many cases with such unwanted outcome do we need to see happening
before our eyes before we conclude that what happened in the past can
very well happen in the future, all the well-intentioned enthusiasts
notwithstanding, and before we start applying that conclusion to our
decision-making process?

But maybe I'm the only one who is bothered by the fact that we never,
as a project, raise the head above the water level and look farther
into the future than just tomorrow or the day after?  In which case
I'll stop talking about this and accept the fact the others aren't
bothered.  After all, I don't own this project, I'm just the steward;
if the community decides to go with this, the community will bear the
consequences, whether good or bad.