Re: Android port of Emacs

[Stefan Monnier <monnier@iro.umontreal.ca>]

[ Yes, I know, I'm coming late to this discussion, sorry.
  I don't intend to say much more about it.  ]

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

I have not looked closely at the branch itself, so take my opinion with
a grain of salt, but here it goes:

I don't think Emacs is currently very usable on Android because Emacs
evolved in a context of machines where the main input device is
a keyboard, with a mouse as secondary input device, and Android devices
that fit this description are basically limited to Chromebooks.

But for the same reason I think it's important to invest efforts in this
Android port: machines whose main input device is a touchscreen are not
going anywhere, so taking a longer-term perspective we should try and
make Emacs more usable on those machines, and currently that mostly
means Android machines.

> However, Android is a proprietary platform, so it isn't one
> of the systems that we are required to target.

I don't think we're required to target any platform at all, anyway :-)
[ I personally use LineageOS on my Android devices, and I don't consider
  it "proprietary" (tho I don't consider it fully Free either).  ]

> I also don't think Android (and smartphones in general) will become
> the main, or even important, platform for Emacs any time soon.

Agreed.  But I think it has the potential to become an important
platform in the long run (probably not to edit source code, but to run
things like Org mode).

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

FWIW, I'm not sure how useful/important it would be to include the
Android port in the Emacs tarball: I'd expect that anyone dedicated
enough to build his own Emacs-on-Android (that requires a fair bit more
effort than for other platforms, in my experience) would do so from Git.

>   . 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
>   . it requires non-trivial knowledge of the Android platform,
>     including its unique requirements and limitations

I think we should treat this the same way we do for the macOS or
MS-DOS support: there's always the threat that we'll remove that support
if noone steps up to combat bitrot.

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

This is the real issue, IMO.
We need to take a hard look here to see how to solve those problems.

Is there a set of bugs opened for those integration issues?
Or some place where we keep track of them?

That's not a deal breaker, I believe (after all, we have similar quirks
introduced by other ports, such as the /-vs-\ in file names, or the
fact that we resist the introduction of a `fork` primitive in ELisp
because of the problems implementing it on the w32 platform), but we
need to keep this as much as possible under control.

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

While I don't foresee hordes of people contributing to the port in the
future, no matter what we do, I suspect that if it becomes an "official"
port (with a usable release on F-Droid), we'll start seeing more people
contribute patches to improve Android support.
Probably not many patches to src/android*.c, but patches to things like
lisp/org/*.el, as well as new Android-specific *ELPA packages.

> An alternative would be for the Android support to be a separate
> project on Savannah.  Maybe in the long run this would be better?

The "mac port" experience is an anecdotal proof that it can be a valid
option, but Aquamacs is the other anecdotal proof that this tends to
have trouble keeping up with Emacs development and ends up forking and
then dying.

I'd rather include it in the main branch, to encourage its maintenance
and hope for mutual long term benefit, while making it clear that
if/when we have to choose between breaking this code or improving Emacs
for GNU/Linux, we'll choose the latter.

IOW, just as is already the case for Haiku, MS-DOS, ...


        Stefan