Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> 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

Android documentation is freely available, and the Android code in Emacs
is fairly well documented.

> 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.)

Just as someone could study Android from the reference manuals at:

  https://developer.android.com/reference

and standard C, POSIX, and Java materials.  Though that is hardly
necessary: for most Emacs maintenance work, only an understanding of X
will be necessary.  Xlib functions translate to Android ones through
simple substitution; for the most part, replacing `X' with `android_'
and removing arguments that expect a Display or Screen.

> 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?

I pointed out that we have Objective-C in the NS port, not because that
inherently makes using Java a good idea, but because it demonstrates
that the use of a non-C language in GUI code does not lead to problems.

While NS has severe problems, they are not caused by the use of
Objective-C.  And NS uses Objective-C to a far greater extent than the
Android port uses Java, with many Lisp and redisplay primitives
implemented in that language, which are all implemented in C as direct
translations of xterm.c or xfns.c in the Android port.

> 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.

How many people will have to step up to maintain the Android port?
Because if 5, 10, or even 20 people do so, they may all still leave for
greener pastures.

This problem is solved by making the Android port trivially
comprehensible for programmers who are familiar with
platform-independent parts of Emacs, not by counting the number of
people who are currently involved.  I say we are already there.

Thanks.