Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I wonder whether the Android port of Emacs, which is being developed
> by Po Lu for the past few months, should be part of the upstream Emacs
> and whether it should be distributed as part of the Emacs release
> tarballs.  The advantage of having the Android support bundled is that
> we allow people to build the Android port right out of the release
> tarball.  However, Android is a proprietary platform, so it isn't one
> of the systems that we are required to target.  I also don't think
> Android (and smartphones in general) will become the main, or even
> important, platform for Emacs any time soon.

It's worth mentioning that this port of Emacs runs just as well on the
free Android-based systems, such as Replicant.  Whether or not enough
people use them is up to debate, and sadly my opinion is that those
systems are used so rarely that they should not be put into
consideration.

> There are some significant disadvantages of the Android support:
>
>   . it makes the Emacs distribution significantly larger (I think no
>     other port, not even the MS-Windows or macOS ports, add so much
>     stuff to the distribution)

I believe most of the code stems from Gnulib, and most of that is
vasnprintf-posix and its assorted dependencies.

>   . significant portions of the Android support are (and AFAIU must
>     be) implemented in Java, which is not used anywhere else in Emacs;
>     Emacs developers are therefore not expected to be Java experts,
>     and we have no Java-oriented coding conventions in Emacs

Similarly, the Nextstep port is written in Objective-C, an object
oriented language similar to Java.

In the Android port, care has been taken to keep as much logic as
possible written in C, with only the bare minimum required written in
Java.  For example, the font backend which is actually used
(sfntfont-android.c), and much of the bitmap copy code, is written in C.
In contrast to Nextstep, no Lisp functions are implemented in any non-C
language.

Additionally, the Java code is also written to minimize the use of Java
specific features in the language, and a 900-line (to be expanded)
write-up is provided on the specifics of both reading and writing Java
code and connecting it to the corresponding C code.

>   . it requires non-trivial knowledge of the Android platform,
>     including its unique requirements and limitations

The interfaces between Java and the rest of Emacs are designed to
closely resemble the X window system.

As a result, the C-level input, windowing and graphics code is more or
less a direct translation from xterm.c and xfns.c.  It was intended for
Emacs developers who do not need to change Android-specific code to only
require basic knowledge of X.

>   . its integration adds some non-trivial hair to many existing Emacs
>     APIs and processing, whose purpose is only clear if one considers
>     the special Android quirks

I can only think of two specific quirks: file management and the `exec'
helper binary.  The former is not so different, and much closer to
Unix-like systems, than the Unix emulations in msdos.c and w32.c (not to
mention the numerous special cases under DOS_NT in fileio.c), while the
latter seems is not much different from the `cmdproxy' binary found in
NTEmacs.

They are all well behaved and stay out of the way of system independent
code parts of Emacs.

>   . currently, we have a single developer who understands the
>     specifics of the Android port and works on developing it; it is
>     not good for Emacs to depend on a single individual for a port
>     that should be kept alive and up-to-date for the observable future

That's still a significantly better situation than the NS port, which
seems to have zero people who really understand it.

> Given these IMO significant downsides, I wonder whether we should
> maintain the Android support as part of the upstream project.  It
> sounds like a non-trivial maintenance burden that relies on a single
> developer.  Should we really commit ourselves to this additional work,
> from now on?
>
> An alternative would be for the Android support to be a separate
> project on Savannah.  Maybe in the long run this would be better?
>
> I think this deserves a serious discussion and a more-or-less
> agreed-upon decision, before we decide to land the Android branch and
> thus commit ourselves to supporting the Android port.
>
> Once again, apologies for bringing this up so late.  When the work on
> this port started, I had no idea the result will be anywhere near
> where it is today, or I would speak up much earlier.

Here are some more facts to put the maintenance burden into perspective:

  - The Android port is being developed by one person in his limited
    spare time, and even under those circumstances was completed in 4
    months.  Synchronizing it with other changes being made to Emacs is
    trivial: even as it stands right now (in a feature branch), less
    than 5 minutes of my time are required to merge the master branch
    and prepare new prebuilt binaries each morning.

  - Problems posed by the Android platform have already been solved, and
    the solutions are likely to benefit users of other systems as well:
    input method and touch-screen support come in to mind.

  - There are many free software programmers with Android development
    expertise, especially when compared to those who have experience
    developing for systems such as DJGPP.  Thus, if necessary, it should
    be much easier to locate a replacement Android port maintainer than
    one for the MS-DOS port.

  - More commentary on the Android port is going to be written before it
    is installed.

If the Android port is installed, other Emacs developers are invited to
make changes without consideration towards the Android port.  I will
correct the fall-out, or the Android port will be broken.

Thanks.