Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> The macOS/NS code is already written, and likewise the w32 code.  It
> took us many years to come up with that, but, incrementally, we did.
> So arguing that those platforms nowadays have lots of LOC doesn't
> help.  Moreover, the code specific to these two ports, by and large,
> closely resembles the corresponding parts of X code (xfns.c, xterm.c),

Just as androidterm.c is almost a direct translation of xterm.c, just as
androidfns.c is to xfns.c.  While OTOH, the NS port does not even try.

However, W32 requires extensive changes to file IO and subprocess
creation.  Android does not require as many.  Both platforms require C
constructs that are foreign to GNU and Unix programmers: count the
number of function pointers in w32xfns.c, and the amount of set-up code
involving W32-specific C APIs.

The NS port also shares a distinction with the Android port: a large
quantity of its code is written in a language other than C.  However, NS
was deliberately written to maximize the use of Objective-C features
within parts that are normally implemented in C, such as RIF functions
and event handling logic.  This mistake is what makes it decidedly non
trivial to move changes from X to NS, and is why (until the intervention
of yours truly) it was incapable of displaying glyph overhangs, image
reliefs, or the tab bar.

> with rather minimal deviations in the w32 case and more significant
> deviations in the case of NS.  And even so, the w32 and NS ports are
> already problematic: the former has basically a single
> maintainer/developer (yours truly), the latter doesn't have even that.

Then, perhaps, the NS port should be developed by ``other people'', in
another project?

Besides, X, PGTK, and Haiku, seem to have basically a single developer
at present; we both know who that is.

> The results are clear, if not for everyone: the w32 port falls behind
> in features, and the NS port is basically already badly broken, having
> unacceptable display problems on at least some modern systems.

The NS port is ``basically already badly broken'' due to bad choices
taken by the NS port developers, as I've explained above.

> So what bothers me is whether we as the project should take another
> such port upon ourselves, instead of leaving it to others to develop
> and maintain it outside of the upstream project.  Because if we take
> it upon ourselves, I don't see any way of making sure the Android port
> will not go the way of w32 and NS soon enough, maybe the moment we
> land it.

The same is much less likely to happen with the Android port, because it
is essentially built on top of a replica of the X APIs.

Anyway, having intentionally designed the Android port to minimize the
requirements placed on the part of Emacs developers, I cannot help but
believe that your concerns are undue.

thanks.