Android port of Emacs

Android port of Emacs

[Eli Zaretskii]

I apologize in advance for not bringing this up earlier.  However,
better late than later or never.

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.

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

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.

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.

Re: Android port of Emacs

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

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

As for the size of the Android port wrt other ports, here's what a tool
for counting lines of code reports on Android-specific files:

  $ cloc android*.c textconv.c ../java ../exec/*.ac ../exec/*.s \
    ../exec/*.c ../m4/ndk-build.m4 ../lisp/term/android-win.el 

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               13           5111           3702          16679
Java                            37           2055           1712           6118
Assembly                         6             23             86           1150
m4                               2            131             40            846
Bourne Shell                     1             54             62            252
XML                             10             81            148            232
make                             1             60             84            187
Lisp                             1             42             43            152
-------------------------------------------------------------------------------
SUM:                            71           7557           5877          25616
-------------------------------------------------------------------------------

and on MS Windows specific files:

  $ cloc w32*.c ../nt/* unexw32.c ../lisp/w32-*

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               22           6601           8580          34443
C/C++ Header                    25            290            393           1072
Lisp                             2             70             90            371
make                             2             62            112            164
XML                              2              0             10             70
DOS Batch                        3              7             35             32
-------------------------------------------------------------------------------
SUM:                            56           7030           9220          36152
-------------------------------------------------------------------------------

as such, I don't think it's really fair to claim that the Android port
is significantly larger than the others.

Re: Android port of Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]


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.

Seeing how many people struggle to get working org-mode support on
Android — the many attempts at mobile org — and that more and more
people only know Android and will never own a regular computer, I think
the Android port is a serious advantage.

We also do not need to support any proprietary platform with it, since
releases can be served via F-Droid that only provides Free Software.

> 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 that this would risk becoming stale. I’d rather see a somewhat
maintained port that moves slowly (but keeps working) than a separate
project that moves quickly until it stops and then breaks due to some
API change in Emacs which none of the Emacs developers spotted, because
it only affected an external project.

From my experience the maintenance work created by a big external
project is larger than if the project is part of the tree, because with
the external project compatibility problems are not detected by the
usual tooling directly during development.

Closing thought: one of the largest advantages of learning to use Emacs
instead of any other tool is that Emacs can follow you wherever you go.
Whatever the platform you may (be forced to?) use in the future, Emacs
will be there and your skills will be an advantage. The android port
closes a significant gap for this. I’ve seen several people move their
workflows to proprietary web applications because “then I can use it on
the tablet”. Emacs on Android can provide a viable alternative to that.

Emacs is where developers are, and nowadays many developers are on
Android for large parts of their time.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Android port of Emacs

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> Date: Fri, 16 Jun 2023 17:16:16 +0200
> 
> Seeing how many people struggle to get working org-mode support on
> Android — the many attempts at mobile org — and that more and more
> people only know Android and will never own a regular computer, I think
> the Android port is a serious advantage.
> 
> We also do not need to support any proprietary platform with it, since
> releases can be served via F-Droid that only provides Free Software.
> 
> > 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 that this would risk becoming stale. I’d rather see a somewhat
> maintained port that moves slowly (but keeps working) than a separate
> project that moves quickly until it stops and then breaks due to some
> API change in Emacs which none of the Emacs developers spotted, because
> it only affected an external project.
> 
> From my experience the maintenance work created by a big external
> project is larger than if the project is part of the tree, because with
> the external project compatibility problems are not detected by the
> usual tooling directly during development.
> 
> Closing thought: one of the largest advantages of learning to use Emacs
> instead of any other tool is that Emacs can follow you wherever you go.
> Whatever the platform you may (be forced to?) use in the future, Emacs
> will be there and your skills will be an advantage. The android port
> closes a significant gap for this. I’ve seen several people move their
> workflows to proprietary web applications because “then I can use it on
> the tablet”. Emacs on Android can provide a viable alternative to that.

Thanks, but what you say gives the POV of an Android user, not the POV
of the Emacs maintenance.  I have no doubt whatsoever that having
Emacs on Android will benefit Android users; my doubts are whether we
as the project should and can take upon ourselves this additional
maintenance burden, and promise the Android users that we will
maintain, let alone develop, this port for the years to come.

Re: Android port of Emacs

[Thomas Fitzsimmons]

Hi Eli and Po,

Eli Zaretskii <eliz@gnu.org> writes:

[...]

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

FWIW, I'm already using Emacs on GrapheneOS (a distribution of the
Android Open Source Project whose add-on components are all free and
open source software) for at least viewing text files, with M-x
server-start.  Great work Po!  I'd like to see the port mainlined so
that I can easily build/use the same version from the same branch on my
desktop and mobile computers.

My main worry about the port, from a maintainability standpoint, is how
to cross-compile Emacs for Android using entirely free software.  (For
an extra challenge, my workstation is PPC64, so I can't use pre-built
x86-64 binaries.)  Po, are there steps I can take using a free toolchain
to generate an APK that I can try on my device?

I have seen other Android projects that claim to be buildable only with
Gradle which AFAIK is free software, but they are Java-only, but I
haven't tried myself.  Can Emacs be built using gradlew?  Is the NDK
required to build Emacs for Android?

(Note, I am not arguing that needing a proprietary SDK should preclude
the Android port's inclusion though, since AFAIK it is not possible to
cross-compile Emacs for Macintosh operating systems using only free
tools.)

Thomas

Re: Android port of Emacs

[Eli Zaretskii]

> From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Cc: emacs-devel@gnu.org,  Po Lu <luangruo@yahoo.com>
> Date: Fri, 16 Jun 2023 11:49:29 -0400
> 
> My main worry about the port, from a maintainability standpoint, is how
> to cross-compile Emacs for Android using entirely free software.  (For
> an extra challenge, my workstation is PPC64, so I can't use pre-built
> x86-64 binaries.)  Po, are there steps I can take using a free toolchain
> to generate an APK that I can try on my device?
> 
> I have seen other Android projects that claim to be buildable only with
> Gradle which AFAIK is free software, but they are Java-only, but I
> haven't tried myself.  Can Emacs be built using gradlew?  Is the NDK
> required to build Emacs for Android?

Please start a new thread about these issues.  Let's not mix the
subject I raised here with practical questions of how to build and use
the Android port in this or that system configuration.

OK?

Re: Android port of Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

>> Closing thought: one of the largest advantages of learning to use Emacs
>> instead of any other tool is that Emacs can follow you wherever you go.
>> Whatever the platform you may (be forced to?) use in the future, Emacs
>> will be there and your skills will be an advantage. The android port
>> closes a significant gap for this. I’ve seen several people move their
>> workflows to proprietary web applications because “then I can use it on
>> the tablet”. Emacs on Android can provide a viable alternative to that.
>
> Thanks, but what you say gives the POV of an Android user, not the POV
> of the Emacs maintenance.  I have no doubt whatsoever that having
> Emacs on Android will benefit Android users; my doubts are whether we
> as the project should and can take upon ourselves this additional
> maintenance burden, and promise the Android users that we will
> maintain, let alone develop, this port for the years to come.

That’s not the view of an Android user (I do not currently use Android,
except as an offline two-factor device), but the view of a long term
Emacs user: It is a big advantage for me that Emacs will be wherever my
future life with computers takes me.

Having Emacs everywhere also allows me to avoid lock-in by whatever
platform I use. I may not always have the choice of the platform
(depending on what I do for a living), but by using Emacs I will be able
to preserve my choice to jump back to a libre platform without losing my
skills.

I do not see this as promising that the port will be developed in the
future — that always depends on a developer being interested in doing
that work — but from what Po Lu wrote it does not seem like a large
burden. And from my experience with Java (10 years for volunteer
projects and 5 years professional) 6000 lines of Java are not much. It’s
a pretty verbose language.

The main risk I see is in the toolchain.

@Po Lu: How hard is it to set up a development environment that can
create an apk from the Emacs sources — assuming no prior android
development experience? If it does take a while: are there ways to
reduce that?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Android port of Emacs

[Bob Rogers]

   From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
   Date: Fri, 16 Jun 2023 18:34:16 +0200

   Eli Zaretskii <eliz@gnu.org> writes:

   > Thanks, but what you say gives the POV of an Android user, not the POV
   > of the Emacs maintenance.  I have no doubt whatsoever that having
   > Emacs on Android will benefit Android users; my doubts are whether we
   > as the project should and can take upon ourselves this additional
   > maintenance burden, and promise the Android users that we will
   > maintain, let alone develop, this port for the years to come.

   That’s not the view of an Android user (I do not currently use Android,
   except as an offline two-factor device), but the view of a long term
   Emacs user: It is a big advantage for me that Emacs will be wherever my
   future life with computers takes me.

Hear, hear.  I hate my Android phone for many reasons, chief among them
is that it doesn't have Emacs.  I haven't been brave enough yet to try
Po Lu's port (largely because I'm such a phone idiot), but I'm sure I'll
need it sooner or later, because despite my resistance I'm being pushed
into greater dependence on my phone, so the handwriting is definitely on
the wall.  I would think that Android support would provide a measure of
future-proofing, if not for Emacs, then for Emacs users.

					-- Bob Rogers
					   http://www.rgrjr.com/

Re: Android port of Emacs

[chad]

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

We've seen a couple positions put forward that I will paraphrase as "I
personally see  strong potential in Emacs for Android, although I
don't/wouldn't really use it right away." As near as I can tell, these
positions are tangential to Eli's point which I will summarize as "The
Android port is great, and we should probably give it _some_ support, but
maybe that level is lower than everything expressed and implied by
incorporating it directly into the mainline emacs repository?"

I am personally sympathetic to both views, and (at the risk of
forking/hijacking the thread a bit), I would even go so far as to say that
Emacs as a project might benefit from spinning out at least the Android
port (which is new and very maintained, but has a very high bus factor) and
also the NS port (which is not new, shows some downsides of high bus-factor
parts, and has at least one well-maintained alternative outside the
mainline Emacs repo: the mac port).

As a technical matter, it seems like it's probably easier to maintain some
abstraction barriers along OS and window-system code by virtue of having a
single repo that supports 3-5 "variants", but in practice that _seems_ to
have mostly resulted in treating a quite old "posix-y-unix with X11" as the
baseline, and then adapting everything to that. This seems (again, I'm not
an expert here) to have caused some continuing pain with respect to GTK and
the pgtk port (particularly in the very high incidence of people using pgtk
in wayland+X environments where it's not supported, kinda works, and breaks
in not-so-rare corner cases).

Taking the NS port as an example, if the mainline were to drop support for
the ns port, this would nudge some macOS users over to the mac port, strand
some users of quite old macOS versions, and isolate the users of the
GNUStep port. My belief is that the mac port is already quite popular, the
people stuck on old mac OS X versions are already stuck with library and
compiler version issues, and the GNUStep port has very little actual usage
(I wouldn't be surprised to learn that "testing GNUStep support" is the
single largest user-base of GNUStep" at this point.)

Before discussing whether these tradeoffs are worth it or not, is anything
I've said above obviously wrong, under-informed, or out of date?

~Chad

[-- Attachment #2: Type: text/html, Size: 2537 bytes --]

Re: Android port of Emacs

[Po Lu]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> My main worry about the port, from a maintainability standpoint, is how
> to cross-compile Emacs for Android using entirely free software.  (For
> an extra challenge, my workstation is PPC64, so I can't use pre-built
> x86-64 binaries.)  Po, are there steps I can take using a free toolchain
> to generate an APK that I can try on my device?
>

Emacs doesn't require any proprietary software to be built on Android.
Providing a suitable Java compiler and pointing GCC or Clang to the
Android headers is sufficient.

The tools and headers are all free software and run on the RS/6000.

> I have seen other Android projects that claim to be buildable only with
> Gradle which AFAIK is free software, but they are Java-only, but I
> haven't tried myself.  Can Emacs be built using gradlew?  Is the NDK
> required to build Emacs for Android?

The build system used is based on Make, not Gradle.  Gradle has the
nasty habit of automatically downloading software you did not ask for.

Re: Android port of Emacs

[Po Lu]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> @Po Lu: How hard is it to set up a development environment that can
> create an apk from the Emacs sources — assuming no prior android
> development experience? If it does take a while: are there ways to
> reduce that?

Quickly enough, considering that I've also no prior Android development
experience.

Re: Android port of Emacs

[Po Lu]

chad <yandros@gmail.com> writes:

> We've seen a couple positions put forward that I will paraphrase as "I
> personally see strong potential in Emacs for Android, although I
> don't/wouldn't really use it right away." As near as I can tell, these
> positions are tangential to Eli's point which I will summarize as "The
> Android port is great, and we should probably give it _some_ support,
> but maybe that level is lower than everything expressed and implied by
> incorporating it directly into the mainline emacs repository?"

Incorporating code in Emacs doesn't mean that we are obligated to
support it or keep it working, it means that we will keep it working to
the extent that interested users provide changes to do so.

i.e. the DOS port was broken between 27.1 and 28.2, but that wasn't an
obstacle to keeping the code around.  Someone eventually fixed it.

> I am personally sympathetic to both views, and (at the risk of
> forking/hijacking the thread a bit), I would even go so far as to say
> that Emacs as a project might benefit from spinning out at least the
> Android port (which is new and very maintained, but has a very high
> bus factor) and also the NS port (which is not new, shows some
> downsides of high bus-factor parts, and has at least one
> well-maintained alternative outside the mainline Emacs repo: the mac
> port).

The Mac port (Carbon Emacs) being spun off was the result of its
maintainer refusing to maintain it for Emacs 23, then refusing to
co-operate with other Emacs developers who tried to adapt it to
multi-tty, and finally realizing that its replacement, the NS port, was
severely inadequate, and backtracking on the angry decision to abandon
it.

That's not an attitude we want to encourage for future Emacs
development.

> As a technical matter, it seems like it's probably easier to maintain
> some abstraction barriers along OS and window-system code by virtue of
> having a single repo that supports 3-5 "variants", but in practice
> that _seems_ to have mostly resulted in treating a quite old
> "posix-y-unix with X11" as the baseline, and then adapting everything
> to that. This seems (again, I'm not an expert here) to have caused
> some continuing pain with respect to GTK and the pgtk port
> (particularly in the very high incidence of people using pgtk in
> wayland+X environments where it's not supported, kinda works, and
> breaks in not-so-rare corner cases).

The GNU project porting policy is to make other operating systems (MS
Windows, VMS, MVS, etc) look like Unix.  And the reason X is treated as
the canonical window system is that X is a superset of every other
window system: it provides all their features, and then some more.

Problems with PGTK stem from the negligence of the GTK developers and
nothing else.

> Taking the NS port as an example, if the mainline were to drop support
> for the ns port, this would nudge some macOS users over to the mac
> port, strand some users of quite old macOS versions, and isolate the
> users of the GNUStep port. My belief is that the mac port is already
> quite popular, the people stuck on old mac OS X versions are already
> stuck with library and compiler version issues, and the GNUStep port
> has very

Those are not issues.  Emacs supports Clang 3.x and GCC 4.5.x (along
with period C libraries) just fine.

> little actual usage (I wouldn't be surprised to learn that "testing
> GNUStep support" is the single largest user-base of GNUStep" at this
> point.)

Perhaps, but then we did get one bug report from an actual user
recently.

Re: Android port of Emacs

[Konstantin Kharlamov]

On Fri, 2023-06-16 at 18:32 +0300, Eli Zaretskii wrote:
> 
> Thanks, but what you say gives the POV of an Android user, not the POV
> of the Emacs maintenance.  I have no doubt whatsoever that having
> Emacs on Android will benefit Android users; my doubts are whether we
> as the project should and can take upon ourselves this additional
> maintenance burden, and promise the Android users that we will
> maintain, let alone develop, this port for the years to come.

Increase of userbase may potentially result in new developers and maintainers.
OTOH, decrease of userbase (due to people having to use alternative editors)
will result in these potential devs/mainainers going to other projects that
provide features they need.

So the size of userbase has indirect influence to the amount of developers and
maintainers.

Re: Android port of Emacs

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Fri, 16 Jun 2023 17:19:05 -0400
> 
> Before discussing whether these tradeoffs are worth it or not, is anything I've said above obviously
> wrong, under-informed, or out of date? 

It is not, AFAIU.  But it is also not relevant to the issue that
bothers me.

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

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.

Everything else brought up here is not relevant.  I understand very
well the tremendous advantages of having Emacs support yet another
widely-used platform, and not only for the users of that platform, but
also for Emacs itself.  So posting opinions about those aspects
doesn't contribute to the discussion I'd like to have here, and
doesn't advance us as the project to making the decision, from my POV.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 17 Jun 2023 08:11:15 +0800
> 
> Incorporating code in Emacs doesn't mean that we are obligated to
> support it or keep it working, it means that we will keep it working to
> the extent that interested users provide changes to do so.

From my POV, adding a significant new port for a widely-used platform,
without a commitment to keep that port working for the observable
future, makes no sense whatsoever.  It's a decision to commit our
scarce resources when we know in advance that those resources will be
wasted on code with no future.

> i.e. the DOS port was broken between 27.1 and 28.2, but that wasn't an
> obstacle to keeping the code around.  Someone eventually fixed it.

MS-DOS is a dead platform.  It is good to keep its port alive if we
can, but no one will lament its bitrot.  Android is very different in
this regard.  So what happens with the MS-DOS port of Emacs is
entirely irrelevant to this discussion.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 17 Jun 2023 03:49:22 +0300
> 
> Increase of userbase may potentially result in new developers and maintainers.

Our experience with NS and w32 ports indicates this is a false hope.

Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> From my POV, adding a significant new port for a widely-used platform,
> without a commitment to keep that port working for the observable
> future, makes no sense whatsoever.

That's exactly what we're doing with all the ports to widely-used
proprietary systems: MS Windows, Mac OS, USG Unix, etc.  We don't commit
to keeping them working, only to keep them working to the extent that
their users do the same.

> It's a decision to commit our scarce resources when we know in advance
> that those resources will be wasted on code with no future.

The resources being committed are mine alone.  And how do we know that
the code has no future?

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: yandros@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 17 Jun 2023 14:38:16 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > From my POV, adding a significant new port for a widely-used platform,
> > without a commitment to keep that port working for the observable
> > future, makes no sense whatsoever.
> 
> That's exactly what we're doing with all the ports to widely-used
> proprietary systems: MS Windows, Mac OS, USG Unix, etc.  We don't commit
> to keeping them working, only to keep them working to the extent that
> their users do the same.

Those already exist, so we don't need to make any decisions about
them.  That's the difference.

> > It's a decision to commit our scarce resources when we know in advance
> > that those resources will be wasted on code with no future.
> 
> The resources being committed are mine alone.

I don't want to waste that as well: we have enough issues and future
developments in the relevant parts of X and GTK where we could use
your resources better.

> And how do we know that the code has no future?

If we don't seriously commit to maintaining it, that follows.

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.

Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Those already exist, so we don't need to make any decisions about
> them.  That's the difference.

Were these same concerns not brought to attention when they were
introduced?  Or when the PGTK port was first introduced in a
significantly worse state?

There is a maintainer of the Android port, with the time and the means
to actively pursue its development, and its code is deliberately
structured to make synchronizing with X trivial.  The port itself
benefits users of X as well, with improved support for certain types of
input methods and input devices.

> I don't want to waste that as well: we have enough issues and future
> developments in the relevant parts of X and GTK where we could use
> your resources better.

The Android port is in fact directly pertinent to many of those future
developments in X and GTK: for instance, it is currently not possible to
use Emacs 30 on a X server with only touch-screen input, but it is on
the feature/android branch.

Some of those changes are quite extensive, and unfortunately, I don't
have the time nor the motivation to separate them from the Android port,
as I don't have the means to test any of them on X.

> If we don't seriously commit to maintaining it, that follows.

I will, however.

Re: Android port of Emacs

[Po Lu]

I meant:

Po Lu <luangruo@yahoo.com> writes:

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

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: chad <yandros@gmail.com>,  emacs-devel@gnu.org
> Date: Sat, 17 Jun 2023 14:57:40 +0800
> 
> > 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?

I won't mind such a move, not at all.  We basically dropped the ball
on the NS port.

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

Haiku is a niche platform, so I don't think we should be bothered by
its fate in Emacs.

X and PGTK belong to our main target platform, so if we abandon those,
Emacs basically has no reason to exist.  Thus, comparing with those is
not useful, because we _must_ support those as best as we can.  We
don't have the same obligation to other platforms.

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

Your work is appreciated, but I'm unconvinced that it can make the
impact of this port easy enough to not break our backs.  Rather than
relying on beliefs, I'd like to rely on experience with other ports,
and on general experience with Emacs development.

Granted, this is a judgment call, which is why I brought this up in
the first place.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: yandros@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 17 Jun 2023 15:08:48 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Those already exist, so we don't need to make any decisions about
> > them.  That's the difference.
> 
> Were these same concerns not brought to attention when they were
> introduced?

Not that I know of, no.  But that doesn't mean we shouldn't have done
that, back then, if the situation was similar.

> Or when the PGTK port was first introduced in a significantly worse
> state?

PGTK is not relevant to this discussion, as I explained in another
message.

> The Android port is in fact directly pertinent to many of those future
> developments in X and GTK: for instance, it is currently not possible to
> use Emacs 30 on a X server with only touch-screen input, but it is on
> the feature/android branch.

That's not relevant: we could merge only those features from the
branch.

> Some of those changes are quite extensive, and unfortunately, I don't
> have the time nor the motivation to separate them from the Android port,
> as I don't have the means to test any of them on X.

Then I guess they are not so useful on X after all.

> > If we don't seriously commit to maintaining it, that follows.
> 
> I will, however.

Relying on a single person for developing a significant port is
something I would be very uncomfortable about.  We have bad experience
with that for other ports and significant features.  There's no reason
to repeat past mistakes if we believe this is a similar situation.

Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Besides, X, PGTK, and Haiku, seem to have basically a single developer
>> at present; we both know who that is.
>
> Haiku is a niche platform, so I don't think we should be bothered by
> its fate in Emacs.
>
> X and PGTK belong to our main target platform, so if we abandon those,
> Emacs basically has no reason to exist.  Thus, comparing with those is
> not useful, because we _must_ support those as best as we can.  We
> don't have the same obligation to other platforms.

X belongs to our main target platform, as it's a part of the GNU
operating system.  Wayland is a protocol developed by the Linux graphics
developers, but is not part of GNU: we maintain its support to the
extent that its users are willing to do so, as a nicety.

> Your work is appreciated, but I'm unconvinced that it can make the
> impact of this port easy enough to not break our backs.  Rather than
> relying on beliefs, I'd like to rely on experience with other ports,
> and on general experience with Emacs development.

I designed the Android port _with_ said experience in mind.  Including
design mistakes in the Haiku and PGTK ports that I have since fixed.

> Granted, this is a judgment call, which is why I brought this up in
> the first place.

So far, the only Emacs developers who have expressed an opinion here
have been you and I.  So perhaps we should bring some other voices here:
who has any names in mind?

Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That's not relevant: we could merge only those features from the
> branch.

I can't help with that, unfortunately.

> Then I guess they are not so useful on X after all.

Lars and many other users have asked for them in the past.  If you
search for ``XInput'' in this list's archives, you will see people
asking for them as far back as 2016.

> Relying on a single person for developing a significant port is
> something I would be very uncomfortable about.  We have bad experience
> with that for other ports and significant features.  There's no reason
> to repeat past mistakes if we believe this is a similar situation.

But currently, we are essentially relying on one person (or nobody at
all) to develop each of the ports in existence.  And most recent
significant C-level features in Emacs _are_ being developed by one
single person: Bidi reordering, native compilation, threads, et cetera.
In many of these cases, the features are related to a subject in which
only one Emacs developer specializes.

If we waited for two or more people to show up, nothing would ever get
done!

Re: Android port of Emacs

[Alfred M. Szmidt]

   > X and PGTK belong to our main target platform, so if we abandon those,
   > Emacs basically has no reason to exist.  Thus, comparing with those is
   > not useful, because we _must_ support those as best as we can.  We
   > don't have the same obligation to other platforms.

   X belongs to our main target platform, as it's a part of the GNU
   operating system.  Wayland is a protocol developed by the Linux graphics
   developers, but is not part of GNU: we maintain its support to the
   extent that its users are willing to do so, as a nicety.

Wayland is very much part of the GNU operating system, most GNU/Linux
systems already support it in some form or another, and it is the
replacment for X11 on literally all GNU systems in some time in the
future (seeing nobody is working on X11 anymore).

   So far, the only Emacs developers who have expressed an opinion here
   have been you and I.  So perhaps we should bring some other voices here:
   who has any names in mind?

I think it should be included.  If it doesn't get maintained, a call
can be made to get people to volunteer.  My only worry is how people
will install it, if it requires going through some propietery app
"store".

Re: Android port of Emacs

[Po Lu]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Wayland is very much part of the GNU operating system, most GNU/Linux
> systems already support it in some form or another, and it is the
> replacment for X11 on literally all GNU systems in some time in the
> future (seeing nobody is working on X11 anymore).

I am... well, I forsee myself being involved, if it stops working well
enough.

I've past experience with porting the X window system to a wide range of
systems.

>    So far, the only Emacs developers who have expressed an opinion here
>    have been you and I.  So perhaps we should bring some other voices here:
>    who has any names in mind?
>
> I think it should be included.  If it doesn't get maintained, a call
> can be made to get people to volunteer.

Thanks for your input.

> My only worry is how people will install it, if it requires going
> through some propietery app "store".

It doesn't: Emacs is distributed in the form of source code, and I also
provide installable binaries and their corresponding source code.

A free package repository is also distributing a very old snapshot from
February; they say updates will be easier for them if emacs.git provides
the Android port source code in the form of tagged releases.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 17 Jun 2023 15:33:16 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Your work is appreciated, but I'm unconvinced that it can make the
> > impact of this port easy enough to not break our backs.  Rather than
> > relying on beliefs, I'd like to rely on experience with other ports,
> > and on general experience with Emacs development.
> 
> I designed the Android port _with_ said experience in mind.  Including
> design mistakes in the Haiku and PGTK ports that I have since fixed.

I was talking about long-term experience of developing and maintaining
various ports in Emacs.  You cannot possibly have such an experience.

> > Granted, this is a judgment call, which is why I brought this up in
> > the first place.
> 
> So far, the only Emacs developers who have expressed an opinion here
> have been you and I.  So perhaps we should bring some other voices here:
> who has any names in mind?

Yes, please speak up.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 17 Jun 2023 15:41:18 +0800
> 
> > Relying on a single person for developing a significant port is
> > something I would be very uncomfortable about.  We have bad experience
> > with that for other ports and significant features.  There's no reason
> > to repeat past mistakes if we believe this is a similar situation.
> 
> But currently, we are essentially relying on one person (or nobody at
> all) to develop each of the ports in existence.  And most recent
> significant C-level features in Emacs _are_ being developed by one
> single person: Bidi reordering, native compilation, threads, et cetera.
> In many of these cases, the features are related to a subject in which
> only one Emacs developer specializes.

Once again:

  . there are jobs that we _must_ do, whatever the costs and the
    risks, and there are jobs that we can decide not to do
  . having problems in some parts of Emacs development doesn't mean we
    should add one more, if we don't have to

If we keep disregarding these simple truisms, this discussion will
have a lot of useless repetitions.  So let's be focused, and let's try
not to waste time on irrelevant aspects of this.

Re: Android port of Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
>> Date: Sat, 17 Jun 2023 03:49:22 +0300
>> 
>> Increase of userbase may potentially result in new developers and maintainers.
>
> Our experience with NS and w32 ports indicates this is a false hope.

I may only contribute some smaller things, but having Emacs available on
w32 kept me in Emacs when I had to use that system for a few months
around 2011.

There I realized that most workflows in Emacs keep working where most
others break.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Android port of Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]


Po Lu <luangruo@yahoo.com> writes:
>> I don't want to waste that as well: we have enough issues and future
>> developments in the relevant parts of X and GTK where we could use
>> your resources better.
>
> The Android port is in fact directly pertinent to many of those future
> developments in X and GTK: for instance, it is currently not possible to
> use Emacs 30 on a X server with only touch-screen input, but it is on
> the feature/android branch.
>
> Some of those changes are quite extensive, and unfortunately, I don't
> have the time nor the motivation to separate them from the Android port,
> as I don't have the means to test any of them on X.

So these need to be tested before merging would be viable at all.

Do you have time and motivation to fix bugs reported by people testing
your port on X desktop?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Android port of Emacs

[Po Lu]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> Po Lu <luangruo@yahoo.com> writes:
>>> I don't want to waste that as well: we have enough issues and future
>>> developments in the relevant parts of X and GTK where we could use
>>> your resources better.
>>
>> The Android port is in fact directly pertinent to many of those future
>> developments in X and GTK: for instance, it is currently not possible to
>> use Emacs 30 on a X server with only touch-screen input, but it is on
>> the feature/android branch.
>>
>> Some of those changes are quite extensive, and unfortunately, I don't
>> have the time nor the motivation to separate them from the Android port,
>> as I don't have the means to test any of them on X.
>
> So these need to be tested before merging would be viable at all.
>
> Do you have time and motivation to fix bugs reported by people testing
> your port on X desktop?

I do; I just don't have the time nor motivation to work on separating
the changes relevant for other systems from the branch.  It would become
even harder for me if it were turned into a separate project.

Re: Android port of Emacs

[Konstantin Kharlamov]

On Sat, 2023-06-17 at 09:20 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sat, 17 Jun 2023 03:49:22 +0300
> > 
> > Increase of userbase may potentially result in new developers and
> > maintainers.
> 
> Our experience with NS and w32 ports indicates this is a false hope.

To be fair, Emacs is notoriously hard to contribute to, so to have new devs/maintainers appear requires substantially larger increase of the userbase compared to an increase needed in other projects. Still worth a try though.

Re: Android port of Emacs

[Alfred M. Szmidt]

   > > Increase of userbase may potentially result in new developers and
   > > maintainers.
   > 
   > Our experience with NS and w32 ports indicates this is a false hope.

   To be fair, Emacs is notoriously hard to contribute to, so to have
   new devs/maintainers appear requires substantially larger increase
   of the userbase compared to an increase needed in other
   projects. Still worth a try though.

Notoriously hard?  It is one of the easiest projects, you send a patch, one
of the amazing people who work on Emacs looks over it, and if you have
your papers in order, it is commited or commented on.  That is not
very hard.

Best is to avoid such crazy overblown generalizations...

Re: Android port of Emacs

[Alfred M. Szmidt]

   > > Your work is appreciated, but I'm unconvinced that it can make the
   > > impact of this port easy enough to not break our backs.  Rather than
   > > relying on beliefs, I'd like to rely on experience with other ports,
   > > and on general experience with Emacs development.
   > 
   > I designed the Android port _with_ said experience in mind.  Including
   > design mistakes in the Haiku and PGTK ports that I have since fixed.

   I was talking about long-term experience of developing and maintaining
   various ports in Emacs.  You cannot possibly have such an experience.

One can view it as someone getting that long term experience, I tink
Po Lu has shown to be quite the long term hacker when it comes to GNU
Emacs.  Giving them the responsibility of said port is a good way to
nourish, and grown such experience.


But yeah, as in a previous message of Eli, there are jobs that have to
be done.  E.g., what happens if this port delays a release in some
manner (Po Lu not having the time to address the issue, or it is
complicated, whatever)?  

Does that delay the whole release of Emacs, is it addressed in a bug
fix release ... Maybe there could be made some rules about what
happens if the port (or any port) starts lagging behind.

Re: Android port of Emacs

[Gregory Heytings]

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

Indeed.  There is another data point that should, I believe, be mentioned: 
users who want to run Emacs on an Android device can already do so, with 
both its TUI and GUI, without any changes whatsoever on the Emacs side. 
See for instance this five years old Reddit post: 
https://www.reddit.com/r/emacs/comments/9m76ak/termux_package_emacsx/. 
That post mentions the "XServer XSDL" X server; a year later the Termux 
folks started the development of their own X server implementation for 
Android, Termux:X11.

Re: Android port of Emacs

[Po Lu]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> But yeah, as in a previous message of Eli, there are jobs that have to
> be done.  E.g., what happens if this port delays a release in some
> manner (Po Lu not having the time to address the issue, or it is
> complicated, whatever)?  
>
> Does that delay the whole release of Emacs, is it addressed in a bug
> fix release ... Maybe there could be made some rules about what
> happens if the port (or any port) starts lagging behind.

As with any proprietary system, we simply release Emacs with that port
broken.  It's no big deal: most of the 19.xx series was released with
VMS support broken, and only recently was 27.1 through 28.1 released
with a nonfunctional MS-DOS port.

But that is not likely to happen in the first place.

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Indeed.  There is another data point that should, I believe, be
> mentioned: users who want to run Emacs on an Android device can
> already do so, with both its TUI and GUI, without any changes
> whatsoever on the Emacs side. See for instance this five years old
> Reddit post:
> https://www.reddit.com/r/emacs/comments/9m76ak/termux_package_emacsx/. That
> post mentions the "XServer XSDL" X server; a year later the Termux
> folks started the development of their own X server implementation for
> Android, Termux:X11.

That's adequate to the same extent that Cygwin/X is adequate for running
Emacs.  Or actually much less adequate, seeing as that X server doesn't
support input methods, clipboard data other than text, or touch screen
devices.  Try to scroll a window without a keyboard or mouse wheel.

Also, that build is more or less broken:

  https://github.com/termux/termux-packages/issues/10083

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Indeed.  There is another data point that should, I believe, be
> mentioned: users who want to run Emacs on an Android device can
> already do so, with both its TUI and GUI, without any changes
> whatsoever on the Emacs side. See for instance this five years old
> Reddit post:
> https://www.reddit.com/r/emacs/comments/9m76ak/termux_package_emacsx/. That
> post mentions the "XServer XSDL" X server; a year later the Termux
> folks started the development of their own X server implementation for
> Android, Termux:X11.

That's adequate to the same extent that Cygwin/X is adequate for running
Emacs.  Or actually much less adequate, seeing as that X server doesn't
support input methods, clipboard data other than text, or touch screen
devices.  Try to scroll a window without a keyboard or mouse wheel.

Also, that build is more or less broken:

  https://github.com/termux/termux-packages/issues/10083

Re: Android port of Emacs

[Dmitry Gutov]

On 17/06/2023 09:00, Eli Zaretskii wrote:
> 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.

We shouldn't be afraid to deprecate and remove unmaintained ports. And 
we shouldn't (like Po already said) delay releases over them.

If we had a consensus on that, I guess the main concern that would 
remain is whether the Android port complicates the common code enough 
for it to be noticeable. Or, from another angle, whether removing the 
port will be a difficult operation because of having to excise those 
additions in the common code paths.

On the flip side, I suppose we should ask how many changes the Android 
port requires in the shared code at all. Because if there were none, 
maintaining the port in a separate repo, rebasing regularly (and perhaps 
automatically), would be a cake walk too.

Re: Android port of Emacs

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On the flip side, I suppose we should ask how many changes the Android
> port requires in the shared code at all. Because if there were none,
> maintaining the port in a separate repo, rebasing regularly (and
> perhaps automatically), would be a cake walk too.

The problem with this approach is that such a separate repository will
essentially be a fork.  That will be much more difficult for me compared
to keeping it in emacs.git, as it is now: if it does happen, I probably
will have to stop working on one or the other.

Re: Android port of Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Dmitry Gutov <dmitry@gutov.dev> writes:
>
>> On the flip side, I suppose we should ask how many changes the Android
>> port requires in the shared code at all. Because if there were none,
>> maintaining the port in a separate repo, rebasing regularly (and
>> perhaps automatically), would be a cake walk too.
>
> The problem with this approach is that such a separate repository will
> essentially be a fork.  That will be much more difficult for me compared
> to keeping it in emacs.git, as it is now: if it does happen, I probably
> will have to stop working on one or the other.

Why keeping the Android port on its own *branch* prevents it from being
on emacs.git? How that prevents distributing source tarballs and
binaries targeting Android from the official GNU Emacs site?

Keeping the Android port on its own branch even could have advantages
from the maintenance POV. The monolithic source model is not always the
most effective one.

We can try doing an *official* release of Emacs 30 for Android based on
the branch and see what happens on terms of user acceptance and
developer load, so hopefully after some time the maintainers (and the
developer(s)!) have actual facts as a basis for their decisions.

Po Lu: I installed your apk on a tablet today. I'm truly impressed, for
sure the feat required many ours of research and quite a bit of
inventiveness.

That said, if my understanding is correct, the port suffers from a
serious limitation (imposed by Android, of course) in that the user
can't install binaries and use them from Emacs on the usual way. An
Emacs that can't invoke git, gcc... is of little use to me, although I'm
sure that many users will find the port extremely convenient (Org users,
for instance.) Emacs on Termux has no such limitation, but it has its
own problems, starting with a terrible user interface.

I completely believe you when you say that the port will be maintained.
I have more doubts about Android itself, specifically about its
increasing restrictions, making Emacs even more constrained with each OS
release.

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It is clear that we want to support Emacs on Android, if that is feasible.
It is clear that, if the maintenance burden for us is too high, it would
be unfeasible.  This is the same as the situation for Windows, for MacOS,
and maybe for MSDOS as well if it is still of interest to users.

In each of these cases, the specific question of whether we can
bear the maintenance burden is a matter of details.  We can't decide
those questions by general arguments.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Dmitry Gutov]

On 18/06/2023 04:24, Po Lu wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> On the flip side, I suppose we should ask how many changes the Android
>> port requires in the shared code at all. Because if there were none,
>> maintaining the port in a separate repo, rebasing regularly (and
>> perhaps automatically), would be a cake walk too.
> The problem with this approach is that such a separate repository will
> essentially be a fork.  That will be much more difficult for me compared
> to keeping it in emacs.git, as it is now: if it does happen, I probably
> will have to stop working on one or the other.

What will the difficulty be? If it just comes down to running 'git pull 
upstream master' once in a while, then this can be a small price to pay.

If the merge conflicts are likely to be frequent, however, that's a 
different matter.

Re: Android port of Emacs

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> What will the difficulty be? If it just comes down to running 'git
> pull upstream master' once in a while, then this can be a small price
> to pay.

The difficulty lies the other requirements of a completely separate
project: the use of my personal inbox as a bug report address, the
unrelated bugs being reported there, having to distribute releases
myself on ftp.gnu.org, and in general the division of my attention
between Emacs and my own fork.

> If the merge conflicts are likely to be frequent, however, that's a
> different matter.

I've only seen three or four merge conflicts over the past few months,
all involving etc/NEWS.

Re: Android port of Emacs

[Eli Zaretskii]

> Date: Sun, 18 Jun 2023 04:10:35 +0300
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> We shouldn't be afraid to deprecate and remove unmaintained ports. And 
> we shouldn't (like Po already said) delay releases over them.
> 
> If we had a consensus on that

This is easier said than done.  In practice, we don't like to release
knowing that one of the platforms we care about is broken.  In fact, I
don't think it ever happened, not even with NS (MSDOS is not a
platform we care about, so it is not relevant.)  We might, of course,
release a broken port if we are unaware that it's broken, but that's
not the same thing.

> I guess the main concern that would remain is whether the Android
> port complicates the common code enough for it to be noticeable.

I invite you to review the results of

  git diff ...origin/feature/android

and make up your own mind about that.

Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> This is easier said than done.  In practice, we don't like to release
> knowing that one of the platforms we care about is broken.  In fact, I
> don't think it ever happened

How about VMS?  Some Emacs 19 releases were made knowing that it was
broken, and the same applied for 21.1 through 22.3.  Its support was
removed in 23.1.

Re: Android port of Emacs

[Gregory Heytings]

>> Indeed.  There is another data point that should, I believe, be 
>> mentioned: users who want to run Emacs on an Android device can already 
>> do so, with both its TUI and GUI, without any changes whatsoever on the 
>> Emacs side. See for instance this five years old Reddit post: 
>> https://www.reddit.com/r/emacs/comments/9m76ak/termux_package_emacsx/. 
>> That post mentions the "XServer XSDL" X server; a year later the Termux 
>> folks started the development of their own X server implementation for 
>> Android, Termux:X11.
>
> That's adequate to the same extent that Cygwin/X is adequate for running 
> Emacs.  Or actually much less adequate, seeing as that X server doesn't 
> support input methods, clipboard data other than text, or touch screen 
> devices.  Try to scroll a window without a keyboard or mouse wheel.
>

Sorry, but that's wrong, or at the very least exaggerated, AFAICS. 
Termux does support input methods (see e.g. 
https://wiki.termux.com/wiki/Touch_Keyboard), and Termux:X11 does of 
course support touch screen devices (see 
https://github.com/termux/termux-x11).  Please be factual, and add 
pointers to some external places.

I did not check your claim about "clipboard data other than text", I don't 
even know what that means.  I just tried to copy-paste a cat image from a 
browser (I tried both Firefox and Chrome) to Emacs on GNU/Linux, it did 
not work.  And even assuming that minor feature would work on GNU/Linux 
and not on Android, it would make life of Android users slightly less 
convenient, which does not seem a problem in itself.

>
> Also, that build is more or less broken:
>
> https://github.com/termux/termux-packages/issues/10083
>

A single bug report indicating that "sometimes when copy pasting text in 
emacs-x it freezes with clock icon." is not synonymous to "more or less 
broken" in my book.

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Sorry, but that's wrong, or at the very least exaggerated,
> AFAICS. Termux does support input methods (see
> e.g. https://wiki.termux.com/wiki/Touch_Keyboard

Termux does _not_ support such input methods: it only supports on-screen
keyboard programs, which are only capable of entering alphanumeric
characters and symbols.  Also, that page describes the use of of the
Termux terminal emulator, not the X server which they are developing.

You can easily verify this by installing any CJK input method and trying
to enable it inside a Termux or X11 window.  Don't assume that everyone
resides in an English speaking country, or one where alphabetical
writing systems are commonplace.

> ), and Termux:X11 does
> of course support touch screen devices (see
> https://github.com/termux/termux-x11).  Please be factual, and add
> pointers to some external places.

Only in the form of mouse pointer emulation, which is unusable.

> I did not check your claim about "clipboard data other than text", I
> don't even know what that means.  I just tried to copy-paste a cat
> image from a browser (I tried both Firefox and Chrome) to Emacs on
> GNU/Linux, it did not work.

Did you try `yank-media' in a message mode buffer?

> And even assuming that minor feature would work on GNU/Linux and not
> on Android, it would make life of Android users slightly less
> convenient, which does not seem a problem in itself.

There are many other differences: the ability to open files provided by
the Android file-system API (rather than the Unix VFS that is
intentionally limited by Android), and the ability to run user-installed
executables outside of the Termux (or Emacs) home directory, just to
name a few.

> A single bug report indicating that "sometimes when copy pasting text
> in emacs-x it freezes with clock icon." is not synonymous to "more or
> less broken" in my book.

It is, because yanking text from the clipboard is an operation users
perform very often.  And the fact that it breaks, and Emacs cannot even
display an error message, because the Termux port maintainers did not
import the Gnulib modules necessary for Emacs to do so, points to the
complete inadequacy of their port.

Unlike you, I investigated and tried the existing solutions and found
them inadequate for my real-world requirements before writing the
Android port.  So before you reply, I suggest you take some time to try
your so-called solution, with the requirements I outlined above in mind.

Perhaps then you will realize how badly it works, and why users are
responding so positively to the native Android windowing support.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  yandros@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 13:48:29 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is easier said than done.  In practice, we don't like to release
> > knowing that one of the platforms we care about is broken.  In fact, I
> > don't think it ever happened
> 
> How about VMS?  Some Emacs 19 releases were made knowing that it was
> broken

I wasn't around when Emacs 19 was being released, so I don't know.  I
was just a user back then.

Re: Android port of Emacs

[Sean Whitton]

Hello,

On Sat 17 Jun 2023 at 09:47AM +03, Eli Zaretskii wrote:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: yandros@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 17 Jun 2023 14:38:16 +0800
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > It's a decision to commit our scarce resources when we know in advance
>> > that those resources will be wasted on code with no future.
>>
>> The resources being committed are mine alone.
>
> I don't want to waste that as well: we have enough issues and future
> developments in the relevant parts of X and GTK where we could use
> your resources better.

But that's up to Po, not any of the rest of us, and it's orthogonal to
spinning it out to a separate Savannah project -- Po still gets to
choose how to divide his efforts between emacs.git and the new project!

-- 
Sean Whitton

Re: Android port of Emacs

[Thanos Apollo]

Eli Zaretskii <eliz@gnu.org> writes:

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

Does this mean emacs won't be supported on android devices anymore?

I love using emacs through termux especially for note taking during my
university lectures. In any case, thank you for your hard work and
dedication!

-- 
Thanos

Re: Android port of Emacs

[Dmitry Gutov]

On 18/06/2023 08:31, Eli Zaretskii wrote:
>> Date: Sun, 18 Jun 2023 04:10:35 +0300
>> Cc: emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> We shouldn't be afraid to deprecate and remove unmaintained ports. And
>> we shouldn't (like Po already said) delay releases over them.
>>
>> If we had a consensus on that
> 
> This is easier said than done.  In practice, we don't like to release
> knowing that one of the platforms we care about is broken.  In fact, I
> don't think it ever happened, not even with NS (MSDOS is not a
> platform we care about, so it is not relevant.)  We might, of course,
> release a broken port if we are unaware that it's broken, but that's
> not the same thing.

There might be a certain loss of face involved, but it really is better 
to have an Android port of at least some versions of Emacs than not have 
it at all, isn't it?

And if it's broken, we could as well announce that the Android release 
is "not ready" and will probably arrive at some later time [when/if it's 
fixed].

FWIW, I think the important part in this discussion is you and Po arrive 
at some more or less amenable conclusion, and whether the port is 
developed externally or internally is secondary.

It's fairly plausible that Android will become a desktop platform too 
not too far off in the future. Or desktop computing will migrate even 
more toward portable devices. We'll be more prepared either way.

>> I guess the main concern that would remain is whether the Android
>> port complicates the common code enough for it to be noticeable.
> 
> I invite you to review the results of
> 
>    git diff ...origin/feature/android
> 
> and make up your own mind about that.

I took a brief look, but couldn't come to a particular conclusion.

It's a large diff, and not all of it is "common" code. TBF the 
autotools/make additions look the scariest to me, but I'm not sure 
whether that's an objective opinion.

As far as the number/volume of Java files go, I'd recommend not paying 
much attention. Java *is* a verbose language, and at any point in the 
future we'll almost certainly find someone familiar with it (I have 2 
years with it under my belt myself, even if it was a decade ago).

Re: Android port of Emacs

[Dmitry Gutov]

On 18/06/2023 06:05, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> What will the difficulty be? If it just comes down to running 'git
>> pull upstream master' once in a while, then this can be a small price
>> to pay.
> 
> The difficulty lies the other requirements of a completely separate
> project: the use of my personal inbox as a bug report address, the
> unrelated bugs being reported there, having to distribute releases
> myself on ftp.gnu.org, and in general the division of my attention
> between Emacs and my own fork.

Ah, so you are worried about maintaining a separate project infrastructure.

Personally, I really recommend you try Gitlab/Github/SourceHut/Gogs/etc. 
If you can bear with using any of those, I'm almost certain that you 
will receive more and better bug reports through those, and maybe even 
additional contributors/maintainers.

But either way, like others said, developing the Android port in a 
separate branch -- or even in a separate repo -- doesn't necessarily 
preclude you from having access to Debbugs, ftp.gnu.org, and even the 
Emacs mailing lists. I'm sure most or all of those can be arranged.

>> If the merge conflicts are likely to be frequent, however, that's a
>> different matter.
> 
> I've only seen three or four merge conflicts over the past few months,
> all involving etc/NEWS.

Some larger time period could give more data, but so far it sounds like 
both conclusions can work relatively easily then: keeping Android port 
internally wouldn't result in too many additional conflicts for others 
to excise. But keeping it in external repo (or branch) shouldn't results 
in frequent conflicts either. And as a bonus, you don't have to use the 
same file for NEWS, so those 3-4 conflicts you mention would be avoided.

Re: Android port of Emacs

[Gregory Heytings]

>
> You can easily verify this by installing any CJK input method and trying 
> to enable it inside a Termux or X11 window.  Don't assume that everyone 
> resides in an English speaking country, or one where alphabetical 
> writing systems are commonplace.
>

A request to add a Chinese input method for Termux:X11 can be found at 
https://github.com/termux/termux-x11/issues/147, it was closed three 
months ago, after the person who filed the request said, after testing the 
feature, that "it works perfectly".

BTW, as you know Emacs has no less than 25 built-in input methods for 
Chinese, which only require a keyboard with alphanumeric characters.

>> and Termux:X11 does of course support touch screen devices (see 
>> https://github.com/termux/termux-x11).
>
> Only in the form of mouse pointer emulation, which is unusable.
>

What do you mean?  That page indicates that you can tap and swipe (with 
which you can scroll vertically or horizontally).

>
> There are many other differences: the ability to open files provided by 
> the Android file-system API (rather than the Unix VFS that is 
> intentionally limited by Android), and the ability to run user-installed 
> executables outside of the Termux (or Emacs) home directory, just to 
> name a few.
>

What does that mean in practice?  Two hours ago someone said in this 
thread "I love using emacs through termux", so how can you claim that it 
is "unusable", "completely inadequate" and "bad"?

>> A single bug report indicating that "sometimes when copy pasting text 
>> in emacs-x it freezes with clock icon." is not synonymous to "more or 
>> less broken" in my book.
>
> It is, because yanking text from the clipboard is an operation users 
> perform very often.  And the fact that it breaks, and Emacs cannot even 
> display an error message, because the Termux port maintainers did not 
> import the Gnulib modules necessary for Emacs to do so, points to the 
> complete inadequacy of their port.
>

That points to a possible improvement of Termux, not to a "complete 
inadequacy of their port".

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> A request to add a Chinese input method for Termux:X11 can be found at
> https://github.com/termux/termux-x11/issues/147, it was closed three
> months ago, after the person who filed the request said, after testing
> the feature, that "it works perfectly".

The last follow-up in that thread is an image displaying a Chinese
input method, with the composition functionality disabled, captioned ``a
sad story''.

Instead of making these statements, why not try yourself, as I have?
With Trime or Fcitx?

> BTW, as you know Emacs has no less than 25 built-in input methods for
> Chinese, which only require a keyboard with alphanumeric characters.

These input methods are inferior to other free input methods available
on X and Android.  I don't expect you to understand, seeing as you don't
write Chinese text.

> What do you mean?  That page indicates that you can tap and swipe
> (with which you can scroll vertically or horizontally).

Swiping with two fingers is not convenient and conflicts with dragging
to select text.  And, if I wanted editor modes, I wouldn't be using
Emacs.

> What does that mean in practice?  Two hours ago someone said in this
> thread "I love using emacs through termux", so how can you claim that
> it is "unusable", "completely inadequate" and "bad"?

It means that you are able to directly open files from an Android FTP
client in Emacs.

> That points to a possible improvement of Termux, not to a "complete
> inadequacy of their port".

It doesn't matter.  Right now, it is far from a substitute for the
Android port.

From the tone of your writing (not only here, also from your other
interactions, over the past several months), I'm beginning to suspect
that you have personal problems with me, and are deliberately trying to
mislead those who read this thread with irrelevant information.

So unless you actually use Android, the various Emacsen that are capable
of running there, and a good understanding of the code within the
feature/android branch, please stay out of this thread.  This is the
last follow-up I will post in response to you.

Re: Android port of Emacs

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Ah, so you are worried about maintaining a separate project infrastructure.
>
> Personally, I really recommend you try
> Gitlab/Github/SourceHut/Gogs/etc. If you can bear with using any of
> those, I'm almost certain that you will receive more and better bug
> reports through those, and maybe even additional
> contributors/maintainers.

The repository or issue tracker infrastructure is not really the
problem, having to observe a separate bug report address (and direct
unrelated bugs back to bug-gnu-emacs) is.  There's also the problem of
managing the copyright assignment paperwork: I don't have access to
copyright.list, so anyone who wants to work on the Android port will
have to go back and forth between me and emacs-devel, which adds
difficulty as well.

Those are just a few of the problems.

> But either way, like others said, developing the Android port in a
> separate branch -- or even in a separate repo -- doesn't necessarily
> preclude you from having access to Debbugs, ftp.gnu.org, and even the
> Emacs mailing lists. I'm sure most or all of those can be arranged.

[...]

> Some larger time period could give more data, but so far it sounds
> like both conclusions can work relatively easily then: keeping Android
> port internally wouldn't result in too many additional conflicts for
> others to excise. But keeping it in external repo (or branch)
> shouldn't results in frequent conflicts either. And as a bonus, you
> don't have to use the same file for NEWS, so those 3-4 conflicts you
> mention would be avoided.

There's also a certain mental burden associated with maintaining a
separate project, which I'm not comfortable with.  The same goes for the
notion of starting what is essentially a fork of Emacs: we've seen the
waste of resources that was XEmacs and is now the spin-off Carbon Emacs.

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But yeah, as in a previous message of Eli, there are jobs that have to
  > be done.  E.g., what happens if this port delays a release in some
  > manner (Po Lu not having the time to address the issue, or it is
  > complicated, whatever)?  

Android support is of secondary importance _to us_, for various
reasons, one being that it is a nonfree system and not worthy
of being treated as having high importance.

If we want to make a release, and the support for Android has a bug
that nobody around can fix at the time, I think we should (1) announce
widely that we seek someone to fix this problem, (2) wait around a
month or so, then (3) make the release with a note in it describing
the problem.

In the announcement we should explain that Android is a nonfree system
and thus morally should not have highest priority, with suitable
references to further info.  Teaching that idea is an important part
of our mission.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Manuel Giraud via Emacs development discussions.]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> So far, the only Emacs developers who have expressed an opinion here
>> have been you and I.  So perhaps we should bring some other voices here:
>> who has any names in mind?
>
> Yes, please speak up.

Hi,

I'm far from being an Emacs developer but here is my 2 cents anyway.  As
Eli said he would not be opposed to drop the NS port (for it to be
handled somewhere else), why not « trade » the NS port for the Android
one?  Should the Android port become stale (with zero dev or whatever),
we could later drop this port too?
-- 
Manuel Giraud

Re: Android port of Emacs

[Po Lu]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> I'm far from being an Emacs developer but here is my 2 cents anyway.  As
> Eli said he would not be opposed to drop the NS port (for it to be
> handled somewhere else), why not « trade » the NS port for the Android
> one?  Should the Android port become stale (with zero dev or whatever),
> we could later drop this port too?

FWIW, I'm in favor of dropping _none_ of the ports.  NS is in a bad
state, but is still much better than when it was first included: then,
multiple Emacs users reported it in a completely unusable state, not
even capable of running subprocesses without lock-ups, yet it still
replaced Carbon Emacs.

I feel obliged to mention, again, that when the NS port was installed,
there was no commitment from anyone to keep it maintained.  And it was
actually broken.

Re: Android port of Emacs

[Dmitry Gutov]

On 19/06/2023 03:39, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> Ah, so you are worried about maintaining a separate project infrastructure.
>>
>> Personally, I really recommend you try
>> Gitlab/Github/SourceHut/Gogs/etc. If you can bear with using any of
>> those, I'm almost certain that you will receive more and better bug
>> reports through those, and maybe even additional
>> contributors/maintainers.
> 
> The repository or issue tracker infrastructure is not really the
> problem, having to observe a separate bug report address (and direct
> unrelated bugs back to bug-gnu-emacs) is.  There's also the problem of
> managing the copyright assignment paperwork: I don't have access to
> copyright.list, so anyone who wants to work on the Android port will
> have to go back and forth between me and emacs-devel, which adds
> difficulty as well.

That shouldn't be a problem either: as a maintainer of a new project 
working under GNU with required CA, you'll be able to request access to 
the machine where the list resides. I have.

>> Some larger time period could give more data, but so far it sounds
>> like both conclusions can work relatively easily then: keeping Android
>> port internally wouldn't result in too many additional conflicts for
>> others to excise. But keeping it in external repo (or branch)
>> shouldn't results in frequent conflicts either. And as a bonus, you
>> don't have to use the same file for NEWS, so those 3-4 conflicts you
>> mention would be avoided.
> 
> There's also a certain mental burden associated with maintaining a
> separate project, which I'm not comfortable with.  The same goes for the
> notion of starting what is essentially a fork of Emacs: we've seen the
> waste of resources that was XEmacs and is now the spin-off Carbon Emacs.

My experience is that it's no that big a deal. And XEmacs was a very 
different affair.

But I can understand that maintaining a new project in the same 
directory tree can feel unnatural. If different toolkits could be 
structures as plugins, it would look more sensible, but we are ways off 
from that possibility, of course.

Re: Android port of Emacs

[Gregory Heytings]

>> A request to add a Chinese input method for Termux:X11 can be found at 
>> https://github.com/termux/termux-x11/issues/147, it was closed three 
>> months ago, after the person who filed the request said, after testing 
>> the feature, that "it works perfectly".
>
> The last follow-up in that thread is an image displaying a Chinese input 
> method, with the composition functionality disabled, captioned ``a sad 
> story''.
>

No, as anyone can see, the last follow-up in that thread is a reply from 
one of the Termux developers telling that user to use another touch 
keyboard to fix that problem.  Someone requests a Chinese input method in 
Termux, the Termux developers implement it, the person who made the 
request tests it and tells that "it works perfectly", and you still claim 
it doesn't work, using the factoid that someone else who apparently did 
not configure their device correctly posted a comment in that bug thread? 
And I'm the one who "deliberately tries to mislead those who read this 
thread with irrelevant information"?

>> What do you mean?  That page indicates that you can tap and swipe (with 
>> which you can scroll vertically or horizontally).
>
> Swiping with two fingers is not convenient and conflicts with dragging 
> to select text.
>

So your initial claim that Termux does not support touch screen devices 
and that you cannot scroll a window is false, it's only that scrolling 
with two fingers it not as convenient as scrolling with one finger?  And 
I'm the one who "deliberately tries to mislead those who read this thread 
with irrelevant information"?

>
> From the tone of your writing (not only here, also from your other 
> interactions, over the past several months), I'm beginning to suspect 
> that you have personal problems with me, and are deliberately trying to 
> mislead those who read this thread with irrelevant information.
>

That sentence very much looks like a rhetorical trick to discredit 
everything I said and could say.  I won't fall into that trap.

>
> So unless you actually use Android, the various Emacsen that are capable 
> of running there, and a good understanding of the code within the 
> feature/android branch, please stay out of this thread.
>

If the only people who are welcome in this thread are those you describe, 
it would be a monologue between you and yourself.  This thread was started 
by Eli, who wanted a "serious discussion" about the feature/android branch 
(sadly, it quickly derailed into a discussion about Emacs contributions in 
general).

I only mentioned a fact that should I believe be taken into consideration, 
which wasn't included in Eli's post, namely that Emacs can be (and is 
actually) used on Android devices without any of these changes.  You tried 
to contradict that fact by telling that Emacs running under Termux / 
Termux:X11 is "unusable", "completely inadequate" and "broken".

So far however, the few features that you said work better with the 
feature/android branch compared to a stock Emacs running under Termux / 
Termux:X11 (the ability to use M-x yank-media in message-mode, scrolling 
windows with one finger instead of two fingers, a more convenient CJK 
input method (?)) do not seem to justify, at least to me, your judgement 
that Emacs running under Termux / Termux:X11 is "unusable" and "far from a 
substitute for the Android port".

Re: Android port of Emacs

[Eli Zaretskii]

> From: Thanos Apollo <public@thanosapollo.com>
> Date: Sun, 18 Jun 2023 23:39:48 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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?
> 
> Does this mean emacs won't be supported on android devices anymore?

It isn't supported yet.  And we haven't yet made the decision whether
to include the Android code, which is currently on a separate branch
of the Emacs Git repository.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 19 Jun 2023 08:34:16 +0800
> 
> So unless you actually use Android, the various Emacsen that are capable
> of running there, and a good understanding of the code within the
> feature/android branch, please stay out of this thread.  This is the
> last follow-up I will post in response to you.

Is this going to be your style in discussing issues pertaining to the
Android port?  If so, I will decide not to land it right here and now.
Because it's extremely likely that most people who will ask or post
opinions or comment on the Android support will not have "a good
understanding of the code within the feature/android branch", and so
this unkind response could be a preview of what we are in for.  And
that is unacceptable, from my POV.

So please in the future make a point of respecting others who speak
about this more than the above indicates.  Gregory may or may not know
as much as you do about this, but he definitely invested some effort
into researching the issues, and should be commended for that, not
pounced upon.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 19 Jun 2023 16:22:09 +0800
> 
> I feel obliged to mention, again, that when the NS port was installed,
> there was no commitment from anyone to keep it maintained.  And it was
> actually broken.

Let's not present past mistakes (or what could be in hindsight
considered to be mistakes) as arguments for repeating those mistakes.
The purpose of my asking these controversial questions is precisely so
we try to make a decision before we are dragged into it by default.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Po Lu <luangruo@yahoo.com>,  emacs-devel@gnu.org
> Date: Mon, 19 Jun 2023 09:51:32 +0200
> 
> I'm far from being an Emacs developer but here is my 2 cents anyway.  As
> Eli said he would not be opposed to drop the NS port (for it to be
> handled somewhere else), why not « trade » the NS port for the Android
> one?  Should the Android port become stale (with zero dev or whatever),
> we could later drop this port too?

I don't see how this would help or solve anything.  Each port is
worked on by different people, so it isn't like dropping one will
free people to work on the other.

Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Is this going to be your style in discussing issues pertaining to the
> Android port?  If so, I will decide not to land it right here and now.
> Because it's extremely likely that most people who will ask or post
> opinions or comment on the Android support will not have "a good
> understanding of the code within the feature/android branch", and so
> this unkind response could be a preview of what we are in for.  And
> that is unacceptable, from my POV.

No, it's not -- the problem is that that research leaves much to be
desired: he is trying to debate technical details of the Android port
from the POV of an Android user, without possessing an understanding of
both the technical and user-interface issues involved.  Such debate is
not constructive, especially when Termux (the terminal emulator) is
regularly being conflated with the Termux X server.

> So please in the future make a point of respecting others who speak
> about this more than the above indicates.

OK.

> Gregory may or may not know as much as you do about this, but he
> definitely invested some effort into researching the issues, and
> should be commended for that, not pounced upon.

Then let me explain my position again: on touch-screen devices with
small screens, using PC input methods through an X server becomes an
exercise in frustration.  With the Android file-system APIs, many files
cannot be accessed through the Unix VFS alone.  On those devices, the
mouse pointer emulation provided by X is difficult to use, as it relies
on different series of counterintuitive gestures, and various different
input ``modes''.  Finally, various minor UI features, such as yanking
media, displaying dialog boxes while in the background or iconified,
automatically displaying the OSK when required, are not possible inside
an X server running on Android.

I experienced these problems with Termux first-hand, and they motivated
me to start writing a new port.

So far, nothing that was said in this thread refutes that.  And
hopefully, you can understand why I get extremely frustrated when the
nature of those problems is called into question, especially in the face
of positive feedback by many users.

Thanks.

Re: Android port of Emacs

[chad]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On Mon, Jun 19, 2023 at 9:14 PM Po Lu <luangruo@yahoo.com> wrote:

> I experienced these problems with Termux first-hand, and they motivated
> me to start writing a new port.[...]
>
> And
> hopefully, you can understand why I get extremely frustrated when the
> nature of those problems is called into question...


This is helpful, at least for me. In that spirit, I want to add that you
seemed to be claiming, in multiple messages and multiple different
wordings, that the termux+emacs solution was "broken", "unusable", and
"inadequate", and while I do presume those terms accurately describe *your*
experience, it definitely does not describe *everyone's* experience. I have
used it myself in the past, and I know several people who have used it for
years, some of which are still using it today.

This is perfectly fine -- different people have different goals, needs, and
criteria, of course. The problems come in, especially on
distributed messaging systems, when some people use words, phrasings, or
discussion style that tends to conflate one person's own
(valuable!) experience with the incontrovertible state of the universe for
everyone. Unfortunately for us mailing-list using humans, typical human
conversation tends to encode this sort of "scope" metadata in features that
are either _badly_ or _not at all_ conveyed by pure text, especially the
quick/interleaved sort of text usually found on forums, chat systems, and
mailing lists. (Interestingly, this is true of the large majority of, but
not every, human language!)

This sort of thing is where mailing lists (chat rooms, etc.) tend to run
into trouble.

I hope this helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 2174 bytes --]

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: gregory@heytings.org,  emacs-devel@gnu.org
> Date: Tue, 20 Jun 2023 09:13:42 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Is this going to be your style in discussing issues pertaining to the
> > Android port?  If so, I will decide not to land it right here and now.
> > Because it's extremely likely that most people who will ask or post
> > opinions or comment on the Android support will not have "a good
> > understanding of the code within the feature/android branch", and so
> > this unkind response could be a preview of what we are in for.  And
> > that is unacceptable, from my POV.
> 
> No, it's not -- the problem is that that research leaves much to be
> desired

People who are willing to look into an issue and bring up opinions or
suggestions aren't required to become experts before they speak up.
For example, if I'd allow myself such an attitude, I'd probably
refuse to speak with anyone about the display engine or the bidi code,
with the sole exception of Gerd.

> hopefully, you can understand why I get extremely frustrated when the
> nature of those problems is called into question, especially in the face
> of positive feedback by many users.

We as experts in some Emacs areas are required to suppress our
frustration in such cases and patiently explain why others are wrong.
the only justified exception is when the opponent behaves extremely
rudely.  Which was not the case here.

Re: Android port of Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Why keeping the Android port on its own *branch* prevents it from being
> on emacs.git? How that prevents distributing source tarballs and
> binaries targeting Android from the official GNU Emacs site?

I thought Eli proposed for me to move the port to its separate project
on Savannah, not on feature/android.

> Po Lu: I installed your apk on a tablet today. I'm truly impressed, for
> sure the feat required many ours of research and quite a bit of
> inventiveness.

Not really: Android is relatively straightforward, and thankfully Java
is easy for C programmers.  Thanks for the compliment.

> That said, if my understanding is correct, the port suffers from a
> serious limitation (imposed by Android, of course) in that the user
> can't install binaries and use them from Emacs on the usual way. An
> Emacs that can't invoke git, gcc... is of little use to me, although I'm
> sure that many users will find the port extremely convenient (Org users,
> for instance.) Emacs on Termux has no such limitation, but it has its
> own problems, starting with a terrible user interface.

The issues with installing and running binaries has been completely
solved: in fact, it is possible to build the entire Termux binary
repositories with the prefix changed to `org.gnu.emacs', and to run
the programs built directly from inside Emacs.

If anyone needs help with this, and the instructions in:

  https://github.com/termux/termux-packages/

don't help, please feel free to contact me off-list.  Thanks.

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We shouldn't be afraid to deprecate and remove unmaintained ports. And 
  > we shouldn't (like Po already said) delay releases over them.

Assuming that Po Lu continues to maintain the Android support, and
that we don't delay releases over them, the only issue is whether the
changes for Android cause trouble in the non-Android code that delays
a release.  How likely is that?  People will be able to try out
the changes on other systems and get problems fixed.  Once that is done,
maybe such problems will be rare and not a significant obstacle to
non-Android maintenance.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Please don't sink to personal attacks and speculation about possible
ignoble motives.  No one is perfectly rational, but doing a good job
of Emacs develment calls for us to make this discussion as rational as
it can be.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Gregory Heytings]

>
> he is trying to debate technical details of the Android port
>

No, I am not "trying to debate" anything.

Once again, my initial post in this thread only mentioned a fact that 
should probably be taken into consideration, and which wasn't listed in 
Eli's post, namely that Emacs can be used on Android devices without any 
of the changes in the Android feature branch, under Termux.

You tried to refute that, by claiming without any nuance that Emacs 
running under Termux is "unusable", "completely inadequate" and "broken". 
My only point has been that this is "wrong or exaggerated".  Someone else 
(Chad) confirmed that it is.

Re: Android port of Emacs

[Gregory Heytings]

>
> Please don't sink to personal attacks and speculation about possible 
> ignoble motives.  No one is perfectly rational, but doing a good job of 
> Emacs develment calls for us to make this discussion as rational as it 
> can be.
>

Why am I a recipient, and what's more the first recipient, of that post? 
Where do you see any "personal attack" or "speculation about possible 
ignoble motives" in my posts?

Re: Android port of Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, yandros@gmail.com, emacs-devel@gnu.org
> Date: Tue, 20 Jun 2023 20:50:54 -0400
> 
>   > We shouldn't be afraid to deprecate and remove unmaintained ports. And 
>   > we shouldn't (like Po already said) delay releases over them.
> 
> Assuming that Po Lu continues to maintain the Android support, and
> that we don't delay releases over them, the only issue is whether the
> changes for Android cause trouble in the non-Android code that delays
> a release.  How likely is that?  People will be able to try out
> the changes on other systems and get problems fixed.  Once that is done,
> maybe such problems will be rare and not a significant obstacle to
> non-Android maintenance.

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).  If we assume that this doesn't happen and
the port keeps being developed and maintained, there's nothing to
discuss, from my POV, because any useful feature is always welcome in
Emacs, and any breakage a new feature could cause is fixed soon
enough.

Re: Android port of Emacs

[Gregory Heytings]

>
> The issues with installing and running binaries has been completely 
> solved: in fact, it is possible to build the entire Termux binary 
> repositories with the prefix changed to `org.gnu.emacs', and to run the 
> programs built directly from inside Emacs.
>

IOW, users will run Termux under Emacs instead of running Emacs under 
Termux.  (Yes, that's a simplified way of presenting things, but it's the 
idea.)

Concretely speaking, this means that the same programs will be installed 
twice on the same device (which typically do not have a large storage 
capacity): in the /data/data/com.termux directory, and in the 
/data/data/org.gnu.emacs directory.

Concretely speaking, this also means that all programs installed in the 
/data/data/org.gnu.emacs directory need to be built from source, either on 
the Android device itself (but they typically have slow CPUs) or by 
cross-compiling them on a faster computer.

I've also looked at the "exec" subdirectory in the feature branch.  You 
may be aware that the hack you use there to circumvent Android's "write 
xor execute" security policy has been rejected by the Termux developers, 
and that in all likelihood that hole in Android's security policy will be 
patched sooner or later.

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> IOW, users will run Termux under Emacs instead of running Emacs under
> Termux.  (Yes, that's a simplified way of presenting things, but it's
> the idea.)

Termux (the terminal emulator) is not Termux, the package archive.

> Concretely speaking, this means that the same programs will be
> installed twice on the same device (which typically do not have a
> large storage capacity): in the /data/data/com.termux directory, and
> in the /data/data/org.gnu.emacs directory.
>
> Concretely speaking, this also means that all programs installed in
> the /data/data/org.gnu.emacs directory need to be built from source,
> either on the Android device itself (but they typically have slow
> CPUs) or by cross-compiling them on a faster computer.

The termux-packages repository provides several scripts which make this
process trivial.  The result is a `bootstrap-aarch64.zip' that only
needs to be extracted within Emacs.

> I've also looked at the "exec" subdirectory in the feature branch.
> You may be aware that the hack you use there to circumvent Android's
> "write xor execute" security policy has been rejected by the Termux
> developers, and that in all likelihood that hole in Android's security
> policy will be patched sooner or later.

Using a userspace ELF loader cannot be ``patched'' by Android security
policy as long as Android continues to allow ordinary user processes to
trace their children, and thus read and write process memory and
registers.

If you want to argue over this, I ask you to first describe in detail
the procedure used to execute binaries, and then how you propose to
prevent it from being used, while keeping the ability to debug programs.

Which, btw, is a solution Termux will have to adopt at some point,
because in the future, Android will no longer allow applications
targeting API level 29 to be installed.

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > A guy spends 1/7 of his time over 4 months to write an Android port, and
  > your immediate reaction is "we already had termux."

I am not an Android user, nor a Termux user.  I have no opinion about
how these ports compare.  But it is clear that seeing people's
disagreements as a matter of personal antagonism won't help us work
together.

Let's see them as disagreements, and strive to be the reasonable
people between whom disagreements can be resolved.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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.

Re: Android port of Emacs

[Gregory Heytings]

>> Concretely speaking, this means that the same programs will be 
>> installed twice on the same device (which typically do not have a large 
>> storage capacity): in the /data/data/com.termux directory, and in the 
>> /data/data/org.gnu.emacs directory.
>>
>> Concretely speaking, this also means that all programs installed in the 
>> /data/data/org.gnu.emacs directory need to be built from source, either 
>> on the Android device itself (but they typically have slow CPUs) or by 
>> cross-compiling them on a faster computer.
>
> The termux-packages repository provides several scripts which make this 
> process trivial.  The result is a `bootstrap-aarch64.zip' that only 
> needs to be extracted within Emacs.
>

If that process was as trivial as you say it is, distros would not exist. 
Users will have to do that every time they want to upgrade their packages. 
And the same programs will be installed twice on their device (unless they 
want to use Emacs exclusively).

>
> If you want to argue over this, I ask you to first describe in detail 
> the procedure used to execute binaries, and then how you propose to 
> prevent it from being used, while keeping the ability to debug programs.
>

I won't do that.  I'm not a student and you're not a teacher here.

>
> Which, btw, is a solution Termux will have to adopt at some point, 
> because in the future, Android will no longer allow applications 
> targeting API level 29 to be installed.
>

Not only will Termux not have to adopt that "solution", but they 
unequivocally said they will not do that, and they already have another 
solution, of which they say that it's the only correct solution.

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> If that process was as trivial as you say it is, distros would not
> exist. Users will have to do that every time they want to upgrade
> their packages. And the same programs will be installed twice on their
> device (unless they want to use Emacs exclusively).

And most users will wish to use Emacs exclusively: its features are much
richer than that of the Termux application.

> I won't do that.  I'm not a student and you're not a teacher here.

Then the only conclusion I can reach is that what you said earlier was
wrong.  Android security policy cannot prevent Emacs from executing
programs, as long as executing read-only binaries is permitted, ptrace
continues to work, and executable memory mappings to files can continue
to be made.  All of which are required for either LLDB or Chromium to
work, and both are explicitly supported as part of Android.

> Not only will Termux not have to adopt that "solution", but they
> unequivocally said they will not do that, and they already have
> another solution, of which they say that it's the only correct
> solution.

Their ``other solution'' is to rely on yet another feature obsoleted by
Android: sharing files between APK packages, using android:sharedUserId.

Its documentation says:

    This constant is deprecated as of API level 29.

    Shared user IDs cause non-deterministic behavior within the package
    manager. As such, their use is strongly discouraged and might be
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    removed in a future version of Android.  Instead, use proper
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    communication mechanisms, such as services and content providers, to
    facilitate interoperability between shared components.  Existing
    apps can't remove this value, as migrating off a shared user ID
    isn't supported. In these apps, add
    android:sharedUserMaxSdkVersion="32" to avoid using shared user ID
    on new user installs.

The reason Termux developers believe that ptrace-based solutions are
unsuitable, is because it violates their interpretation of Google Play
Store policy.  We are not interested in distributing Emacs through
proprietary platforms, and thus are not limited by those policies.

In an ironic twist, Termux developers stopped being able to upload
updates to the Play Store, shortly after their developers came to their
``conclusions'', as the Play Store placed a minimum target API
requirement on new applications and their updates -- updating their
target API level to the requirement would stop them from being able to
execute binaries.

In fact, the approach I have taken is the only approach that Android has
not discouraged or decided to remove in the future.

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.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 23 Jun 2023 17:05:36 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.

You are not answering any of the questions I raised.

It is not useful to reiterate stuff you or others already wrote.  It
doesn't advance this discussion, which is basically stagnant in the
same spot from the first moment I started it.  No one took the issues
I raise seriously.  Which may mean I'm imagining difficulties where
there are none, or it may mean no one here wants to look at this issue
through the eyes of project management.

Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> You are not answering any of the questions I raised.

Well, I've been reiterating the same stuff over and over, because you've
been doing the same thing.  We just don't agree on these issues, which
is why I asked Richard, a third party, to intervene.

> It is not useful to reiterate stuff you or others already wrote.  It
> doesn't advance this discussion, which is basically stagnant in the
> same spot from the first moment I started it.  No one took the issues
> I raise seriously.  Which may mean I'm imagining difficulties where
> there are none, or it may mean no one here wants to look at this issue
> through the eyes of project management.

I think that in the eyes of most people (me included), the downsides of
releasing Emacs with a port that is broken is negligible, if the port
itself is so unimportant that nobody steps up to fix it before the
release is made.  So, in fact, this is very much an imaginary issue:
either it will get fixed, or it will be broken -- and I've been trying
hard to make sure it won't be broken.  This is how most free software
treats ports to systems that aren't considered important, and is the
only proven way to remain portable while development is being undertaken
by volunteers.

Thanks.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rms@gnu.org,  emacs-devel@gnu.org
> Date: Fri, 23 Jun 2023 19:38:05 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You are not answering any of the questions I raised.
> 
> Well, I've been reiterating the same stuff over and over, because you've
> been doing the same thing.

I'm pointing, time and again, to the main issues that caused me to
start this, in the hope that someone will finally relate to those
issues and starts discussing them, instead of dancing around them.

> I think that in the eyes of most people (me included), the downsides of
> releasing Emacs with a port that is broken is negligible, if the port
> itself is so unimportant that nobody steps up to fix it before the
> release is made.  So, in fact, this is very much an imaginary issue:
> either it will get fixed, or it will be broken -- and I've been trying
> hard to make sure it won't be broken.  This is how most free software
> treats ports to systems that aren't considered important, and is the
> only proven way to remain portable while development is being undertaken
> by volunteers.

This description doesn't fit the reality.  People who use the NS port
are quite disappointed by the problems that don't get solved, and I as
the maintainer cannot remain indifferent to their plight.  It breaks
my heart that I can do almost nothing to facilitate the solution of
those problems.  And mind you, no one thinks the NS problems are
"unimportant", we are just unable to fix them, even though we all
agree they are grave and should be fixed ASAP.

So you might be indifferent to such problems, or consider them
"unimportant", but IMO any responsible maintainer will not; I
certainly am not.  And if we envision such problems to happen sooner
rather than later to the Android port, we may wish to decide whether
we want this now, before the danger becomes real -- as it became with
other similar features.

Re: Android port of Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

> For how long will that single-person support last?
> …
> 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.

This seems to be the core question: how likely is it to find a new
maintainer with Java and Android experience if Po Lu may (have to?) drop
out?

Since Java has consistenly been among the 4 most widely known languages
for the past 22 years (in the Tiobe index:
https://www.tiobe.com/tiobe-index/java/ ), finding someone with enough
Java skills to work on simple code should not be a problem. Finding a
person who enjoys starting into a complex Java codebase may be harder,
but if I understood Po Lu right, this won’t be required, because the
Java part is intentionally kept simple to prevent this.

For Android the situation is similar: Android is the most widespread
platform in the world, so the chance that there are Emacs developers who
have some Android experience from customer-projects is very high.

For Objective-C that’s different, because Objective-C is at position 24
in Tiobe right now and was replaced by Apple with Swift.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Android port of Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> This description doesn't fit the reality.  People who use the NS port
> are quite disappointed by the problems that don't get solved, and I as
> the maintainer cannot remain indifferent to their plight.  It breaks
> my heart that I can do almost nothing to facilitate the solution of
> those problems.  And mind you, no one thinks the NS problems are
> "unimportant", we are just unable to fix them, even though we all
> agree they are grave and should be fixed ASAP.
>
> So you might be indifferent to such problems, or consider them
> "unimportant", but IMO any responsible maintainer will not; I
> certainly am not.  And if we envision such problems to happen sooner
> rather than later to the Android port, we may wish to decide whether
> we want this now, before the danger becomes real -- as it became with
> other similar features.

I'm not indifferent to those problems with the NS port: I hope that some
day, they will be fixed.  However, Emacs development _should_ be
indifferent to them, as its goal is to develop a high quality text
editor for the GNU operating system, and not specifically others.

Which seems especially reasonable, considering that the reality of
volunteer-driven development is that every port will usually be stuck
with one maintainer, at least until that maintainer steps down.

Thanks.

Re: Android port of Emacs

[Dmitry Gutov]

On 23/06/2023 15:08, Eli Zaretskii wrote:
> This description doesn't fit the reality.  People who use the NS port
> are quite disappointed by the problems that don't get solved, and I as
> the maintainer cannot remain indifferent to their plight.  It breaks
> my heart that I can do almost nothing to facilitate the solution of
> those problems.

If we don't add the Android port, would that help the would-be users of 
it (whether the selected alternative is to move it outside the core, or 
not develop it anymore)? Probably not.

It seems more like you are concerned about having an extra thing on your 
plate, which is totally reasonable. And we've talked in the past about 
trying to make Emacs more modular (meaning, moving more stuff out). 
Unfortunately, platform ports are not in the category of things that are 
easy to split off. Not currently, at least.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rms@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 24 Jun 2023 09:19:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This description doesn't fit the reality.  People who use the NS port
> > are quite disappointed by the problems that don't get solved, and I as
> > the maintainer cannot remain indifferent to their plight.  It breaks
> > my heart that I can do almost nothing to facilitate the solution of
> > those problems.  And mind you, no one thinks the NS problems are
> > "unimportant", we are just unable to fix them, even though we all
> > agree they are grave and should be fixed ASAP.
> >
> > So you might be indifferent to such problems, or consider them
> > "unimportant", but IMO any responsible maintainer will not; I
> > certainly am not.  And if we envision such problems to happen sooner
> > rather than later to the Android port, we may wish to decide whether
> > we want this now, before the danger becomes real -- as it became with
> > other similar features.
> 
> I'm not indifferent to those problems with the NS port: I hope that some
> day, they will be fixed.  However, Emacs development _should_ be
> indifferent to them, as its goal is to develop a high quality text
> editor for the GNU operating system, and not specifically others.
> 
> Which seems especially reasonable, considering that the reality of
> volunteer-driven development is that every port will usually be stuck
> with one maintainer, at least until that maintainer steps down.

That's exactly the issue at hand, thank you.  I'd like very much to
hear people speak up about these aspects, not anything else.

Lars, Stefan, Robert, Martin, Mattias, Philip, Dmitry, João, and all
the rest of frequent contributors and developers: where are you?  I'd
love to hear your opinions on this.

Re: Android port of Emacs

[Eli Zaretskii]

> Date: Sat, 24 Jun 2023 04:39:31 +0300
> Cc: rms@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 23/06/2023 15:08, Eli Zaretskii wrote:
> > This description doesn't fit the reality.  People who use the NS port
> > are quite disappointed by the problems that don't get solved, and I as
> > the maintainer cannot remain indifferent to their plight.  It breaks
> > my heart that I can do almost nothing to facilitate the solution of
> > those problems.
> 
> If we don't add the Android port, would that help the would-be users of 
> it (whether the selected alternative is to move it outside the core, or 
> not develop it anymore)? Probably not.

It won't help them, but why does it have to be our problem to help
them?  They will need to seek the solution elsewhere (and at least
some solutions do exist, as was mentioned in this discussion).

> It seems more like you are concerned about having an extra thing on your 
> plate, which is totally reasonable.

Extra thing on our plate, yes.  We had similar discussions about
smaller additions, like the tree-sitter grammars, for example.
Basically, anything that is a significant additional scope for Emacs
maintenance should IMO be scrutinized very thoroughly, precisely
because we have very limited resources.  And this case is no
different.

Re: Android port of Emacs

[Sean Whitton]

Hello,

On Fri 23 Jun 2023 at 10:04AM +03, Eli Zaretskii wrote:

> 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 don't think anyone disagrees with you that it is worth thinking about
this.  The point of disagreement is just that you're weighing the
badness of releasing Emacs with a broken port much more heavily than
anyone else, that's all.  I wouldn't go as far as Po and say that the
problem is "imaginary", just that it's less bad than you think.

-- 
Sean Whitton

Re: Android port of Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

>> That said, if my understanding is correct, the port suffers from a
>> serious limitation (imposed by Android, of course) in that the user
>> can't install binaries and use them from Emacs on the usual way. An
>> Emacs that can't invoke git, gcc... is of little use to me, although I'm
>> sure that many users will find the port extremely convenient (Org users,
>> for instance.) Emacs on Termux has no such limitation, but it has its
>> own problems, starting with a terrible user interface.
>
> The issues with installing and running binaries has been completely
> solved: in fact, it is possible to build the entire Termux binary
> repositories with the prefix changed to `org.gnu.emacs', and to run
> the programs built directly from inside Emacs.

Building those binaries (and its dependencies) can be quite a chore. So
let's reverse the relation: can your port be built (toggling some
configure options, for instance) so it can be packaged as a regular
Termux binary? Which means that when executed from Termux the user would
have a "native" Android Emacs with access to all those external binaries
distributed by Termux.

Please excuse me if this question was already answered elsewhere, but
IMAO it is a very important point to clarify, as it would have a big
impact on usability.

Re: Android port of Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Building those binaries (and its dependencies) can be quite a chore. So
> let's reverse the relation: can your port be built (toggling some
> configure options, for instance) so it can be packaged as a regular
> Termux binary? Which means that when executed from Termux the user would
> have a "native" Android Emacs with access to all those external binaries
> distributed by Termux.

No, but it can (right now) be packaged with the "shared user ID" set to
that of Termux.  When installed along side a Termux build signed with
the same package signing key as Emacs, Emacs will be able to access
executable files installed by Termux.

BTW, it is quite simple to build Termux packages: changing some
environment variables and running `build-bootstrap.sh' is sufficient to
generate the bootstrap archive, and dpkg can then be used to install the
rest.

Hope that helped.

Re: Android port of Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Building those binaries (and its dependencies) can be quite a chore. So
>> let's reverse the relation: can your port be built (toggling some
>> configure options, for instance) so it can be packaged as a regular
>> Termux binary? Which means that when executed from Termux the user would
>> have a "native" Android Emacs with access to all those external binaries
>> distributed by Termux.
>
> No, but it can (right now) be packaged with the "shared user ID" set to
> that of Termux.  When installed along side a Termux build signed with
> the same package signing key as Emacs, Emacs will be able to access
> executable files installed by Termux.

If I understand correctly, this means that you can't start Emacs from
Termux, but a specially-built Emacs could be launched as any other
Android app and then it could invoke Termux applications. Isn't the
"installed alongside Termux" part a bit complicated? I mean, if it is
not possible for Termux to build, package and install your port
alongside their other packages, how the user could do that?

> BTW, it is quite simple to build Termux packages: changing some
> environment variables and running `build-bootstrap.sh' is sufficient to
> generate the bootstrap archive, and dpkg can then be used to install the
> rest.

How is that different from Termux themselves building and distributing
your port?

OTOH, I know from experience that creating, hosting and maintaining a
software distribution (and that would be what you are describing, IIUC)
is quite a lot of work, even when the number of packages is small-ish
(about 50-100 in my case, counting dependencies.) So having a
"hands-off" method for installing Emacs along with other software
packages is crucial for gaining a broad adoption.

> Hope that helped.

I'm progressing on my understanding, thank you.

Re: Android port of Emacs

[Robert Pluim]

>>>>> On Sat, 24 Jun 2023 09:54:09 +0300, Eli Zaretskii <eliz@gnu.org> said:
    Eli> Lars, Stefan, Robert, Martin, Mattias, Philip, Dmitry, João, and all
    Eli> the rest of frequent contributors and developers: where are you?  I'd
    Eli> love to hear your opinions on this.

I was going to stay out of this particular tar-pit, but just have two
remarks

- the NS port lost its maintainer quite some time ago: itʼs not gotten
  any worse
- despite what has been said in this thread, the NS port works fine
  (for me). So Iʼm either atypical or more tolerant of the issues

That combined leads me to think that adding the Android port in
mainline would be fine. If it breaks, so be it, as far as I can tell
itʼs not caused any big knock-on changes for other platforms.

Robert
-- 

Re: Android port of Emacs

[Alan Mackenzie]

Hello, Eli.

On Sat, Jun 24, 2023 at 09:54:09 +0300, Eli Zaretskii wrote:
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: rms@gnu.org,  emacs-devel@gnu.org
> > Date: Sat, 24 Jun 2023 09:19:30 +0800

> > Eli Zaretskii <eliz@gnu.org> writes:

> > > This description doesn't fit the reality.  People who use the NS port
> > > are quite disappointed by the problems that don't get solved, and I as
> > > the maintainer cannot remain indifferent to their plight.  It breaks
> > > my heart that I can do almost nothing to facilitate the solution of
> > > those problems.  And mind you, no one thinks the NS problems are
> > > "unimportant", we are just unable to fix them, even though we all
> > > agree they are grave and should be fixed ASAP.

> > > So you might be indifferent to such problems, or consider them
> > > "unimportant", but IMO any responsible maintainer will not; I
> > > certainly am not.  And if we envision such problems to happen sooner
> > > rather than later to the Android port, we may wish to decide whether
> > > we want this now, before the danger becomes real -- as it became with
> > > other similar features.

> > I'm not indifferent to those problems with the NS port: I hope that some
> > day, they will be fixed.  However, Emacs development _should_ be
> > indifferent to them, as its goal is to develop a high quality text
> > editor for the GNU operating system, and not specifically others.

> > Which seems especially reasonable, considering that the reality of
> > volunteer-driven development is that every port will usually be stuck
> > with one maintainer, at least until that maintainer steps down.

> That's exactly the issue at hand, thank you.  I'd like very much to
> hear people speak up about these aspects, not anything else.

> Lars, Stefan, Robert, Martin, Mattias, Philip, Dmitry, João, and all
> the rest of frequent contributors and developers: where are you?  I'd
> love to hear your opinions on this.

Well, I'm not sure whether or not I count as a frequent contributor, but
I'll answer anyway.

I think you're right to be a bit concerned - how many people in Emacs
have even the slightest hacking experience on Android?  I think an answer
of one would be concerning, but it seems not unlikely to be the case.

Again, how stable is Android at the moment?  Again, I don't know, not
being the owner of an Android device, but my impression is "not very", at
least in the sense that GTK, Wayland, NS, and so on, also don't seem very
stable, more like "rapidly changing".  All of these versions seem likely
to be needing a lot of love for the forseeable future.

All due respect to Po Lu for what he's already done for Emacs (including
reporting lots of CC Mode bugs ;-), but that has been over a period of
only two years.  My impression is that the longer somebody has been an
Emacs contributor, the longer they're likely to remain a long-time
contributor.  We could really do with a statistician to support/refute
that notion.

At the same time, having Android support in Emacs core would clearly be
beneficial.  Particularly if large-scale software development is about to
start happening on Android.

On whether or not to include Android support in Emacs, I feel very unsure
- I can see the arguments both for and against, and feel unable to
evaluate them.  I suspect most contributors here likewise feel uncertain,
and that is the main reason so few have so far expressed a view.

If it would be practicable firstly to try out Android support separate
from the Emacs code, and then move it in the event of a positive
experience I would suggest that.  But that would cost at least as much
extra effort as simply having it separate.

As I said, I don't feel able to express a strong opinion on the matter,
but that's ducking the issue.  My gut feeling is that the arguments for a
separate Android Emacs version are stronger than those for integrated
support, but that's not a judgment I could really defend very strongly.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Android port of Emacs

[Dmitry Gutov]

On 24/06/2023 10:06, Eli Zaretskii wrote:
>> It seems more like you are concerned about having an extra thing on your
>> plate, which is totally reasonable.
> Extra thing on our plate, yes.  We had similar discussions about
> smaller additions, like the tree-sitter grammars, for example.
> Basically, anything that is a significant additional scope for Emacs
> maintenance should IMO be scrutinized very thoroughly, precisely
> because we have very limited resources.  And this case is no
> different.

If I was making this choice, perhaps I'd make an emphasis on the port's 
usefulness. When accepting a significant body of code, whether it has 
one maintainer or several, we should generally be able to understand who 
are the users.

Have the most recent version published on f-droid, then wait a few weeks 
and maybe have a poll somewhere on the mailing lists and/or reddit.

Does f-droid have some private download stats? I couldn't find any, but 
they could be useful. What numbers to expect or require, though, I can't 
say.

The flip side, of course, is that for an arbitrary package written in 
Lisp but not widely useful, we can still halfway-accept it by putting on 
[NonGNU] ELPA. No such option here.

Re: Android port of Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> If I understand correctly, this means that you can't start Emacs from
> Termux, but a specially-built Emacs could be launched as any other
> Android app and then it could invoke Termux applications. Isn't the
> "installed alongside Termux" part a bit complicated? I mean, if it is
> not possible for Termux to build, package and install your port
> alongside their other packages, how the user could do that?

By configuring Emacs with:

  ./configure --with-shared-user-id=com.termux

I think.  Or perhaps org.termux?

> How is that different from Termux themselves building and distributing
> your port?

Termux only packages command-line applications, while programs using GUI
features can only be started by the system itself.

HTH.

> OTOH, I know from experience that creating, hosting and maintaining a
> software distribution (and that would be what you are describing, IIUC)
> is quite a lot of work, even when the number of packages is small-ish
> (about 50-100 in my case, counting dependencies.) So having a
> "hands-off" method for installing Emacs along with other software
> packages is crucial for gaining a broad adoption.

Well, if it helps, I'll see if I can scrape together some machines to
distribute packages built this way.

Re: Android port of Emacs

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> If I was making this choice, perhaps I'd make an emphasis on the
> port's usefulness. When accepting a significant body of code, whether
> it has one maintainer or several, we should generally be able to
> understand who are the users.
>
> Have the most recent version published on f-droid, then wait a few
> weeks and maybe have a poll somewhere on the mailing lists and/or
> reddit.
>
> Does f-droid have some private download stats? I couldn't find any,
> but they could be useful. What numbers to expect or require, though, I
> can't say.

F-Droid does not, but Sourceforge does.  I see around ~100 distinct
downloads each week, equalling around 14 users per day, from

  https://sourceforge.net/projects/android-ports-for-gnu-emacs/files/

Re: Android port of Emacs

[Po Lu]

Alan Mackenzie <acm@muc.de> writes:

> Well, I'm not sure whether or not I count as a frequent contributor, but
> I'll answer anyway.
>
> I think you're right to be a bit concerned - how many people in Emacs
> have even the slightest hacking experience on Android?  I think an answer
> of one would be concerning, but it seems not unlikely to be the case.

Well, you saw at least one other individual in this thread.

> If it would be practicable firstly to try out Android support separate
> from the Emacs code, and then move it in the event of a positive
> experience I would suggest that.  But that would cost at least as much
> extra effort as simply having it separate.

We have already had two months to try it out in the feature branch, on
top of the four months it took to develop it.

Re: Android port of Emacs

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> If I understand correctly, this means that you can't start Emacs from
>> Termux, but a specially-built Emacs could be launched as any other
>> Android app and then it could invoke Termux applications. Isn't the
>> "installed alongside Termux" part a bit complicated? I mean, if it is
>> not possible for Termux to build, package and install your port
>> alongside their other packages, how the user could do that?
>
> By configuring Emacs with:
>
>   ./configure --with-shared-user-id=com.termux
>
> I think.  Or perhaps org.termux?

Great.

>> How is that different from Termux themselves building and distributing
>> your port?
>
> Termux only packages command-line applications, while programs using GUI
> features can only be started by the system itself.
>
> HTH.

There is a Termux extension on the works for supporting X11 and Wayland,
so that can change on the future. Other projects (UserLand) provide a
graphical environment out of the box. I just tried Emacs on UserLand
(Emacs 28.2, the GTK build, from their Arch distribution), the
experience is not great, but it runs.

Installing Emacs as a separate step would not be an issue, but if the
user could launch your port from Termux/Userland or from elsewhere
having access to all those binaries, it would be a boom.

>> OTOH, I know from experience that creating, hosting and maintaining a
>> software distribution (and that would be what you are describing, IIUC)
>> is quite a lot of work, even when the number of packages is small-ish
>> (about 50-100 in my case, counting dependencies.) So having a
>> "hands-off" method for installing Emacs along with other software
>> packages is crucial for gaining a broad adoption.
>
> Well, if it helps, I'll see if I can scrape together some machines to
> distribute packages built this way.

Considering that we already have software distributions for Android,
that would be a waste of your time. And believe me, it is a lot of time,
building the packages is the easy part, the real work comes with the bug
reports.

Today I tried your port again for about an hour. It is obvious that you
use a hardware keyboard ;-) Emacs hides the on-screen keyboard too
often, even with touch-screen-display-keyboad set to `t': just try M-x
calc and do a simple operation. IMO Emacs should never hide the
on-screen keyboard, moreover when clicking with the finger over the
small clickable areas of menus and links is very difficult. And a quick
method to show the keyboard would be very welcome (having the volume
button trick to close Emacs is curious, I'm sure you have your reasons,
but if the keyboard is shown and the user can press C-g, isn't it better
than closing Emacs?)

Also, completion works weird: the sequence C-x b Mes TAB correctly
completes to *Messages*, but when ENTER is hit Emacs creates a buffer
names "Mes".

But those are minor issues that I'm sure will be resolved. I'm having
strong W32/Cygwin vibes. Nobody would say nowadays that the W32 port is
questionable because Cygwin exists. Likewise, this port shows lots of
potential as the right port for the general userbase that would like to
carry Emacs on our pockets.

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Could development of the Android port include writing documentation
of the same thoroughness and quality for that code?
That would make the work take longer, but it would be better
quality and more maintainable.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Dmitry Gutov]

On 25/06/2023 03:10, Po Lu wrote:

>> Does f-droid have some private download stats? I couldn't find any,
>> but they could be useful. What numbers to expect or require, though, I
>> can't say.
> F-Droid does not, but Sourceforge does.  I see around ~100 distinct
> downloads each week, equalling around 14 users per day, from
> 
>    https://sourceforge.net/projects/android-ports-for-gnu-emacs/files/

Sounds good to me, if those are real users, and not some scraper bots, 
of course.

Do you think most are tinkerers who use android with a hardware keyboard 
(as was suggested in this thread today), with tablets, maybe?

I'm curious about having Emacs on the phone myself, but last time I 
tried it (with Termux), having to use the on-screen keyboard didn't 
exactly make it a comparable experience.

Re: Android port of Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> Could development of the Android port include writing documentation
> of the same thoroughness and quality for that code?

The Android port already has a comparable amount of documentation, and
it's still being worked on.

Re: Android port of Emacs

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> There is a Termux extension on the works for supporting X11 and Wayland,
> so that can change on the future. Other projects (UserLand) provide a
> graphical environment out of the box. I just tried Emacs on UserLand
> (Emacs 28.2, the GTK build, from their Arch distribution), the
> experience is not great, but it runs.

Those programs run an X server, but have to be started by the system
anyway.  The experience is not good.

> Installing Emacs as a separate step would not be an issue, but if the
> user could launch your port from Termux/Userland or from elsewhere
> having access to all those binaries, it would be a boom.

If you start Emacs and keep it running, it will be able to access
binaries from Termux.  I think that is sufficient, but if it's not, I'll
try to figure out how to run emacsclient from Termux as well.

> Today I tried your port again for about an hour. It is obvious that you
> use a hardware keyboard ;-) 

Everyone seems to think that, but I don't.

> Emacs hides the on-screen keyboard too often, even with
> touch-screen-display-keyboad set to `t': just try M-x calc and do a
> simple operation.

That shouldn't happen; would you please try to determine what is calling
`frame-toggle-on-screen-keyboard' in that case?

> IMO Emacs should never hide the on-screen keyboard, moreover when
> clicking with the finger over the small clickable areas of menus and
> links is very difficult.

I've never found that difficult; perhaps the menu bar font size is too
small?

> And a quick method to show the keyboard would be very welcome (having
> the volume button trick to close Emacs is curious, I'm sure you have
> your reasons, but if the keyboard is shown and the user can press C-g,
> isn't it better than closing Emacs?)

The volume button doesn't close Emacs, it just quits and behaves
identically to C-g.

> Also, completion works weird: the sequence C-x b Mes TAB correctly
> completes to *Messages*, but when ENTER is hit Emacs creates a buffer
> names "Mes".

This is normal Emacs behavior.  Perhaps you have some customizations to
completion that you forgot to apply to Android?

> But those are minor issues that I'm sure will be resolved. I'm having
> strong W32/Cygwin vibes. Nobody would say nowadays that the W32 port is
> questionable because Cygwin exists. Likewise, this port shows lots of
> potential as the right port for the general userbase that would like to
> carry Emacs on our pockets.

Thanks.

Re: Android port of Emacs

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Sounds good to me, if those are real users, and not some scraper bots,
> of course.

I think not: the downloads are evenly distributed geographically, and
seem to concentrate on aarch64 builds.  If there were scrapers at all,
I'd expect the mips or mips64 builds to have downloads, but nobody
except me seems to have tried them at all.

> Do you think most are tinkerers who use android with a hardware
> keyboard (as was suggested in this thread today), with tablets, maybe?

I don't know.  My personal use is reading mail and editing code on a
mobile phone, while inside a crowded rail car, where no physical
keyboard can fit ;-)

Re: Android port of Emacs

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

> >> If I understand correctly, this means that you can't start Emacs from
> >> Termux, but a specially-built Emacs could be launched as any other
> >> Android app and then it could invoke Termux applications. Isn't the
> >> "installed alongside Termux" part a bit complicated? I mean, if it is
> >> not possible for Termux to build, package and install your port
> >> alongside their other packages, how the user could do that?
> >
> > By configuring Emacs with:
> >
> >   ./configure --with-shared-user-id=com.termux
> >
> > I think.  Or perhaps org.termux?

Based on my experience trying for several weeks,
https://github.com/ayatakesi/termux-emacs
https://qiita.com/ayatakesi/items/be1868d2f394d39f1e76

in addition to specify sharedUserId, it requires to change the Java
classpath(directory structure of java sourse files and classpath
references in sourse files).

The repository's README and article are written in Japanese, but I
believe it can be understood in English using Google Translate
(At least, its quality is  equivalent to the English text I would write.

Changes I made are all contained in the patch file.
https://github.com/ayatakesi/termux-emacs/blob/my/feature/android/my_emacs_feature_android.patch

> Today I tried your port again for about an hour. It is obvious that you
> use a hardware keyboard ;-) Emacs hides the on-screen keyboard too
> often, even with touch-screen-display-keyboad set to `t': just try M-x
> calc and do a simple operation. IMO Emacs should never hide the
> on-screen keyboard, moreover when clicking with the finger over the
> small clickable areas of menus and links is very difficult. And a quick
> method to show the keyboard would be very welcome (having the volume
> button trick to close Emacs is curious, I'm sure you have your reasons,
> but if the keyboard is shown and the user can press C-g, isn't it better
> than closing Emacs?)

In my case, it requires some changes to the source code in order to specify
how the soft keyboard should be displayed.
https://github.com/ayatakesi/termux-emacs/blob/test-20230624/my/feature/android/test-20230624.patch

Thanks.

[-- Attachment #2: Type: text/html, Size: 3586 bytes --]

Re: Android port of Emacs

[Jean Louis]

Just a notice, I have tried Emacs from F-Droid on multiple different
mobile devices, 2 of them DOCOMO, and other 2-3 and Emacs did not
work. It just kind of splash the screen with maybe white color and
aborts, it looks like it crushed every time. All permissions were
given.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port of Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Jun 2023 22:25:48 -0400
> 
>   >   (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.)
> 
> Could development of the Android port include writing documentation
> of the same thoroughness and quality for that code?

The main domain-specific knowledge for that port is how Android
systems are organized and work, and how application installation works
on those systems.  Such documentation cannot be usefully part of
Emacs, and the parts of it that can and should be in Emacs will have
to play the constant catchup game with the changes and developments in
the Android OS and environment, something that from my personal
experience with an Android-based smartphone changes a lot and at a
very fast pace.  And it doesn't help that the most crucial information
we need for making Emacs a reasonably well-behaved app on Android is
on the border of undocumented (if not over the border), as Android
AFAIU is not meant to be the host of such programs.

So I very much doubt that this particular aspect can be resolved
anywhere near completeness by having its documentation in Emacs, let
alone keeping that up-to-date to facilitate future development and
maintenance.

Re: Android port of Emacs

[Po Lu]

Takesi Ayanokoji <ayanokoji.takesi@gmail.com> writes:

> in addition to specify sharedUserId, it requires to change the Java
> classpath(directory structure of java sourse files and classpath
> references in sourse files).

Why is this necessary?

> The repository's README and article are written in Japanese, but I
> believe it can be understood in English using Google Translate
> (At least, its quality is  equivalent to the English text I would write.
>
> Changes I made are all contained in the patch file.
> https://github.com/ayatakesi/termux-emacs/blob/my/feature/android/my_emacs_feature_android.patch
>
>> Today I tried your port again for about an hour. It is obvious that you
>> use a hardware keyboard ;-) Emacs hides the on-screen keyboard too
>> often, even with touch-screen-display-keyboad set to `t': just try M-x
>> calc and do a simple operation. IMO Emacs should never hide the
>> on-screen keyboard, moreover when clicking with the finger over the
>> small clickable areas of menus and links is very difficult. And a quick
>> method to show the keyboard would be very welcome (having the volume
>> button trick to close Emacs is curious, I'm sure you have your reasons,
>> but if the keyboard is shown and the user can press C-g, isn't it better
>> than closing Emacs?)
>
> In my case, it requires some changes to the source code in order to specify how the soft keyboard should be displayed.
> https://github.com/ayatakesi/termux-emacs/blob/test-20230624/my/feature/android/test-20230624.patch
>
> Thanks.

With such a change, you won't be able to control the state of the
on-screen keyboard.  That wastes a lot of screen space when you are not
editing a buffer.

BTW, Ayanokoji-san, would you be interested in volunteering to help
maintain the Android port?

TIA.

Re: Android port of Emacs

[Po Lu]

Jean Louis <bugs@gnu.support> writes:

> Just a notice, I have tried Emacs from F-Droid on multiple different
> mobile devices, 2 of them DOCOMO, and other 2-3 and Emacs did not
> work. It just kind of splash the screen with maybe white color and
> aborts, it looks like it crushed every time. All permissions were
> given.

The version on F-Droid is from February.  You want:

  https://sourceforge.net/projects/android-ports-for-gnu-emacs/

which is updated each day with changes to the feature/android branch.

Re: Android port of Emacs

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

Hello, Po-san.

> Why is this necessary?
To be honest, I don't know why. At first, I tried just changing
sharedUserId and APK signature, but id that didn't work(cannnot access
files from both Emacs and Termux due to "Permission Denied").

> > In my case, it requires some changes to the source code in order to
specify how the soft keyboard should be displayed.
> >
https://github.com/ayatakesi/termux-emacs/blob/test-20230624/my/feature/android/test-20230624.patch
> With such a change, you won't be able to control the state of the
> on-screen keyboard.  That wastes a lot of screen space when you are not
> editing a buffer.
Yes, but I use soft keyboard that doesn't support force show/hide keyboard
like Hacker's keyboard(which can show/hide keyboard even when focus is on
no editable widget like Emacs' splash screen).

So after this patch applied, I use 'Back' buttons to hide keyboard, and
'Overview' to show hidden keyboard, again.

> BTW, Ayanokoji-san, would you be interested in volunteering to help
> maintain the Android port?
With pleasure.

Thanks.

[-- Attachment #2: Type: text/html, Size: 1772 bytes --]

Re: Android port of Emacs

[Po Lu]

Takesi Ayanokoji <ayanokoji.takesi@gmail.com> writes:

> To be honest, I don't know why. At first, I tried just changing
> sharedUserId and APK signature, but id that didn't work(cannnot access
> files from both Emacs and Termux due to "Permission Denied").

It worked for me.  But I will ask someone to look into this, as changing
the Java class path should not be necessary.

> Yes, but I use soft keyboard that doesn't support force show/hide
> keyboard like Hacker's keyboard(which can show/hide keyboard even when
> focus is on no editable widget like Emacs' splash screen).
>
> So after this patch applied, I use 'Back' buttons to hide keyboard,
> and 'Overview' to show hidden keyboard, again.

Perhaps you should try to adjust touch-screen.el to suit your
preferences; I'd be happy to see the changes.

> With pleasure.

Would you read and try to understand the code in src/android*.c, along
with the Java and resource XML files?  I'd like to see if the
documentation that has been written is sufficient for other Android
developers to understand.

Finally, we require copyright assignment to the FSF for changes to GNU
Emacs, which assists the FSF in its enforcement of the conditions placed
by the GPL on its redistribution.  If you will be working on Emacs, it
would be prudent to start the paperwork now, as we cannot accept any
significant changes before it is complete.

Eli, could you send Ayanokoji-san the assignment forms?

TIA.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, Eli Zaretskii
>  <eliz@gnu.org>,
>  emacs-devel@gnu.org
> Date: Sun, 25 Jun 2023 18:21:21 +0800
> 
> Eli, could you send Ayanokoji-san the assignment forms?

Form sent off-list.

Re: Android port of Emacs

[Björn Bidar]

From my point of view I welcome the Android port. I welcome it because
of the possible improvements to mobile usage. Android isn't my platform
of choice but any improvements that also could benefit mobile Linux are
welcome.

The Java part is unavoidable for Android ports, any program is affected
even those using C++ which don't have to deal with the limitations of
Bionic so much (e.g. those using Qt).
If abstracted good many Android specific issues can be even fixed
without knowing Java.

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This description doesn't fit the reality.  People who use the NS port
  > are quite disappointed by the problems that don't get solved, and I as
  > the maintainer cannot remain indifferent to their plight.

Please steel yourself.  We can't take on the responsibility to _help
all users_ because it is more than we can do.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

Hello, Po-san.

> Perhaps you should try to adjust touch-screen.el to suit your
> preferences; I'd be happy to see the changes.

Customizable variable touch-screen-display-keyboard solves my problem,
thanks!

> Would you read and try to understand the code in src/android*.c, along
> with the Java and resource XML files?  I'd like to see if the
> documentation that has been written is sufficient for other Android
> developers to understand.

Well, I will try.

Thanks.

2023年6月25日(日) 午後7:21 Po Lu <luangruo@yahoo.com>:

> Takesi Ayanokoji <ayanokoji.takesi@gmail.com> writes:
>
> > To be honest, I don't know why. At first, I tried just changing
> > sharedUserId and APK signature, but id that didn't work(cannnot access
> > files from both Emacs and Termux due to "Permission Denied").
>
> It worked for me.  But I will ask someone to look into this, as changing
> the Java class path should not be necessary.
>
> > Yes, but I use soft keyboard that doesn't support force show/hide
> > keyboard like Hacker's keyboard(which can show/hide keyboard even when
> > focus is on no editable widget like Emacs' splash screen).
> >
> > So after this patch applied, I use 'Back' buttons to hide keyboard,
> > and 'Overview' to show hidden keyboard, again.
>
> Perhaps you should try to adjust touch-screen.el to suit your
> preferences; I'd be happy to see the changes.
>
> > With pleasure.
>
> Would you read and try to understand the code in src/android*.c, along
> with the Java and resource XML files?  I'd like to see if the
> documentation that has been written is sufficient for other Android
> developers to understand.
>
> Finally, we require copyright assignment to the FSF for changes to GNU
> Emacs, which assists the FSF in its enforcement of the conditions placed
> by the GPL on its redistribution.  If you will be working on Emacs, it
> would be prudent to start the paperwork now, as we cannot accept any
> significant changes before it is complete.
>
> Eli, could you send Ayanokoji-san the assignment forms?
>
> TIA.
>

[-- Attachment #2: Type: text/html, Size: 2954 bytes --]

Re: Android port of Emacs

[Gregory Heytings]

[-- Attachment #1: Type: text/plain, Size: 3504 bytes --]


>> If that process was as trivial as you say it is, distros would not 
>> exist. Users will have to do that every time they want to upgrade their 
>> packages. And the same programs will be installed twice on their device 
>> (unless they want to use Emacs exclusively).
>
> And most users will wish to use Emacs exclusively: its features are much 
> richer than that of the Termux application.
>

It seems to me that you extrapolate too much from your own experience. 
Óscar, who started this subthread, now said both that the process of 
building the Termux packages is not at all "trivial" but rather "quite a 
chore", and that he wants to continue to use Termux.

Independently of his or mine experience, Emacs is, in any case, not 
suitable replacement for GIMP or Audacity, for instance.

>>> If you want to argue over this, I ask you to first describe in detail 
>>> the procedure used to execute binaries, and then how you propose to 
>>> prevent it from being used, while keeping the ability to debug 
>>> programs.
>>
>> I won't do that.  I'm not a student and you're not a teacher here.
>
> Then the only conclusion I can reach is that what you said earlier was 
> wrong.
>

The correct conclusion would have been that I don't want to play by your 
"you should first demonstrate your technical knowledge before speaking 
here" rule.

>> Not only will Termux not have to adopt that "solution", but they 
>> unequivocally said they will not do that, and they already have another 
>> solution, of which they say that it's the only correct solution.
>
> Their ``other solution'' is to rely on yet another feature obsoleted by 
> Android: sharing files between APK packages, using android:sharedUserId.
>
> [...]
>
> In fact, the approach I have taken is the only approach that Android has 
> not discouraged or decided to remove in the future.
>

There is a huge difference between using an obsoleted and discouraged, but 
still supported, feature, that merely "might be removed in a future 
version of Android" (which does not mean "will be removed"), and using a 
hack to directly violate the explicit "write xor execute" security policy.

Despite the fact that it is obsoleted and discouraged, its intended use 
(distributing an app with optional add-ons instead of distributing a large 
monolithic app) seems legitimate, so it is also possible (and IMO 
probable) that if that feature is indeed removed at some point, another 
mechanism to achieve the same goal will exist.  (And yes, I am aware that 
other similar mechanisms already exist, but AFAIK you cannot achieve the 
exact same goal with any of the already existing ones.)

How can you believe that you alone know better, and unquestionably so, 
than a whole team of developers, who have been working on the Android 
platform and have been developing Termux for several years, and who 
carefully considered (and publicly discussed) all alternative solutions, 
including the one you have taken, before deciding which one they would 
adopt?

And, by the way, why do you provide an android-use-exec-loader variable to 
disable that hack, and do you explain in its docstring that it "may prove 
to be problematic for various different reasons", if it is indeed a good 
solution?  Its most obvious limit, apart from the overhead it introduces, 
is that, given that a ptrace'd process cannot ptrace'd again, it becomes 
impossible to use a debugger with that hack.

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> It seems to me that you extrapolate too much from your own
> experience. Óscar, who started this subthread, now said both that the
> process of building the Termux packages is not at all "trivial" but
> rather "quite a chore", and that he wants to continue to use Termux.
>
> Independently of his or mine experience, Emacs is, in any case, not
> suitable replacement for GIMP or Audacity, for instance.

Emacs is a better terminal emulator than Termux.

> The correct conclusion would have been that I don't want to play by
> your "you should first demonstrate your technical knowledge before
> speaking here" rule.

So why are you making (false) claims about the _technical_ details of
process execution?

> There is a huge difference between using an obsoleted and discouraged,
> but still supported, feature, that merely "might be removed in a
> future version of Android" (which does not mean "will be removed"),

With the track record of the Android developers, it _will_ be removed.
Installing programs targeting API level 22 has already been removed in
the next version of Android, and that minimum requirement will be
steadily raised in the future.

> and using a hack to directly violate the explicit "write xor execute"
> security policy.

GNU does not take other software's fascist security policies seriously.
This is why RMS distributes Emacs files world-writable, for example.

> Despite the fact that it is obsoleted and discouraged, its intended
> use (distributing an app with optional add-ons instead of distributing
> a large monolithic app) seems legitimate, so it is also possible (and
> IMO probable) that if that feature is indeed removed at some point,
> another mechanism to achieve the same goal will exist.  (And yes, I am
> aware that other similar mechanisms already exist, but AFAIK you
> cannot achieve the exact same goal with any of the already existing
> ones.)

Android discourages add-ons from using executables in the first place.
Binder IPC (similar to Mach RPC) is their recommended solution for such
add-ons.

> How can you believe that you alone know better, and unquestionably so,
> than a whole team of developers, who have been working on the Android
> platform and have been developing Termux for several years, and who
> carefully considered (and publicly discussed) all alternative
> solutions, including the one you have taken, before deciding which one
> they would adopt?

Because I have different priorities from the Termux developers.  I am
not interested in considering the limitations of Google Play Store
policy, for example.

> And, by the way, why do you provide an android-use-exec-loader
> variable to disable that hack, and do you explain in its docstring
> that it "may prove to be problematic for various different reasons",
> if it is indeed a good solution?  Its most obvious limit, apart from
> the overhead it introduces, is that, given that a ptrace'd process
> cannot ptrace'd again, it becomes impossible to use a debugger with
> that hack.

gdbserver is installed in /system/bin, so it can be run without process
tracing.  Otherwise, I'd have implemented a pass-through, just as in
proot (which, BTW, is used by a port of Vim to Android.)

Besides that, if su is installed on the Android device in question
(which is uncommon), Emacs can simply change its security context to
`trusted_app'.  For obvious reasons, su cannot work if it is being
ptraced.

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Could development of the Android port include writing documentation
  > > of the same thoroughness and quality for that code?

  > The Android port already has a comparable amount of documentation, and
  > it's still being worked on.

That is good.  The question is, is it feasible to bring this to the
same level of learnabiluty as the redisplay code?  Including the
knowledge about the interfaces it depends on?  That would, according
to Eli, solve the problem he is worried about.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The main domain-specific knowledge for that port is how Android
  > systems are organized and work, and how application installation works
  > on those systems.  Such documentation cannot be usefully part of
  > Emacs, and the parts of it that can and should be in Emacs will have
  > to play the constant catchup game with the changes and developments in
  > the Android OS and environment, something that from my personal
  > experience with an Android-based smartphone changes a lot and at a
  > very fast pace.

It will have to be up to Android users that want to run Emacs.

                     And it doesn't help that the most crucial information
  > we need for making Emacs a reasonably well-behaved app on Android is
  > on the border of undocumented (if not over the border), as Android
  > AFAIU is not meant to be the host of such programs.

That's the stuff that would be useful to document in the Emacs Android
port.  The people who can write it are Android experts capable of
making that port work -- capable of figuring out how to make that port
work,

It seems unavoidable that, in the absence of such people, the port
could not be maintained.  The most we can do is invite such people to
show up and do the job.  Then it will be out of our hands, and we will
have no reason to feel bad if they don't.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Android port of Emacs

[Filipp Gunbin]

On 24/06/2023 09:54 +0300, Eli Zaretskii wrote:

[...]

> Lars, Stefan, Robert, Martin, Mattias, Philip, Dmitry, João, and all
> the rest of frequent contributors and developers: where are you?  I'd
> love to hear your opinions on this.

I certainly don't count as a frequent contributor (and never used
Android, except one tablet long ago), but still.  What concerns me is
the target audience of Android port.  Why would you use Emacs on
Android?  There're various Android devices around me - mainly phones and
TVs, but I wouldn't do any serious practical work on them.  If you have
Android phone/tablet, then to use Emacs you perhaps need a separate
keyboard and display.  I doubt that would cost less than a laptop
capable of running Emacs.

To me, a reasonable approach would be to distribute separate Android
port, and then, if there're enough people using it, consider including
Android support in core.

One more note regarding Android (mostly a rumour).  I work in online
cinema, and for years we had problems supporting various TV platforms.
It once appeared that more and more vendors switch to Android, and
that's good - less work for us.  But now most of them are just creating
their own custom platforms - to avoid licensing costs put on them by
Google.

Filipp.

Re: Android port of Emacs

[Po Lu]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> I certainly don't count as a frequent contributor (and never used
> Android, except one tablet long ago), but still.  What concerns me is
> the target audience of Android port.  Why would you use Emacs on
> Android?  There're various Android devices around me - mainly phones and
> TVs, but I wouldn't do any serious practical work on them.

I would; or rather, I do.

> If you have Android phone/tablet, then to use Emacs you perhaps need a
> separate keyboard and display.  I doubt that would cost less than a
> laptop capable of running Emacs.

That's not true.  Support for on-screen keyboards and touch screen
devices (both on X and Android) is part of the Android port.

> One more note regarding Android (mostly a rumour).  I work in online
> cinema, and for years we had problems supporting various TV platforms.
> It once appeared that more and more vendors switch to Android, and
> that's good - less work for us.  But now most of them are just creating
> their own custom platforms - to avoid licensing costs put on them by
> Google.

Android TV is 100% proprietary software; Android itself is not, so you
don't see this with devices running regular Android.

Re: Android port of Emacs

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

Hello,



> the target audience of Android port.  Why would you use Emacs on
> Android?
>

During the early days of smartphones, I had a hesitation to consolidate the
functionality of important business-related, phone feature into devices
that could crash
due to game apps. However, eventually, I ended up abandoning dedicated
telephone devices and started using smartphones. The first programmable
device
I ever laid my hands on was a small pocket computer called PC-1245. Even as
I
started using desktop and laptop PC later on, I always have interest
in mobile devices like Zaurus.

 I feel that such small, high-performance devices embody the future I
envisioned as a child. My smartphone has a Linux application called Termux
installed, but even when I was involved in programming development, I never
used the command line as much as I do in my daily life now since I first
encountered the PC-Unix clone about 20 years ago. In addition to various
applications for processing documents, images, music, and networks, even
AI, I think it would be great to have programmable applications that
centralize communication between the user and the device installed on the
device.

(Above was wrote and translated from Japanese to English by chatgpt-shell
on Emacs on Android duaring my lunch time.)

Thanks.

>

[-- Attachment #2: Type: text/html, Size: 2177 bytes --]

Re: Android port of Emacs

[Jean Louis]

* Filipp Gunbin <fgunbin@fastmail.fm> [2023-06-29 23:36]:
> I certainly don't count as a frequent contributor (and never used
> Android, except one tablet long ago), but still.  What concerns me is
> the target audience of Android port.  Why would you use Emacs on
> Android?  There're various Android devices around me - mainly phones and
> TVs, but I wouldn't do any serious practical work on them.  If you have
> Android phone/tablet, then to use Emacs you perhaps need a separate
> keyboard and display.  I doubt that would cost less than a laptop
> capable of running Emacs.

Using Emacs on Android is for same reasons as on other operating
systems. For writing text, writing SMS, controlling SMS messages,
sending them, controlling calls, initiating calls, marketing,
receiving and sending e-mails, running cron jobs, collecting reports,
collecting GPS data, optimizing images, sorting files,and X number of
other uses!

I am sure that your usage case do not fall there. You need no Emacs on
Android. And I need it, as I have those above use cases.

Android devices are small and easy to power by USB and that USB may be
also powered by solar energy, unlike many desktop computers.

Finally, Android has many forks, including fully free software:

List of custom Android distributions - Wikipedia:
https://en.wikipedia.org/wiki/List_of_custom_Android_distributions

NOT HAVING Emacs on Android is terrible experience.

> One more note regarding Android (mostly a rumour).  I work in online
> cinema, and for years we had problems supporting various TV platforms.
> It once appeared that more and more vendors switch to Android, and
> that's good - less work for us.  But now most of them are just creating
> their own custom platforms - to avoid licensing costs put on them by
> Google.

See above, there are many Android based distributions not paying anything to Google!


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port of Emacs

[Jean Louis]

* Po Lu <luangruo@yahoo.com> [2023-06-25 08:59]:
> The version on F-Droid is from February.  You want:
> 
>   https://sourceforge.net/projects/android-ports-for-gnu-emacs/
> 
> which is updated each day with changes to the feature/android branch.

Where is direct APK file?


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port of Emacs

[Po Lu]

Jean Louis <bugs@gnu.support> writes:

> * Po Lu <luangruo@yahoo.com> [2023-06-25 08:59]:
>> The version on F-Droid is from February.  You want:
>> 
>>   https://sourceforge.net/projects/android-ports-for-gnu-emacs/
>> 
>> which is updated each day with changes to the feature/android branch.
>
> Where is direct APK file?

Please see the instructions at:

  https://sourceforge.net/projects/android-ports-for-gnu-emacs/files/

Re: Android port of Emacs

[Stefan Monnier]

[ 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

Re: Android port of Emacs

[Stefan Monnier via Emacs development discussions.]

> I love using emacs through termux especially for note taking during my
> university lectures. In any case, thank you for your hard work and
> dedication!

This discussion is not bout the Termux version of Emacs (which just
uses a TTY-only version of Emacs, and doesn't require any special
support on our side, it's all "plain old POSIX"), but about the
version of Emacs that runs in full GUI mode on Android (and thus has to
deal with Android's GUI).


        Stefan

Re: Android port of Emacs

[Stefan Monnier via Emacs development discussions.]

> Indeed.  There is another data point that should, I believe, be mentioned:
> users who want to run Emacs on an Android device can already do so, with
> both its TUI and GUI, without any changes whatsoever on the Emacs side. See
> for instance this five years old Reddit post:
> https://www.reddit.com/r/emacs/comments/9m76ak/termux_package_emacsx/. That
> post mentions the "XServer XSDL" X server; a year later the Termux folks
> started the development of their own X server implementation for Android,
> Termux:X11.

FWIW, I tried to use that but found it unbearable.  I can't remember all
the annoyances, but there were many, and AFAIK there is no way for *us*
to fix them.

I do encourage people to contribute to the "X server on Android" to try
and make the X11 build of Emacs usable on Android, but seeing how even
the native X11 server's own maintenance is lacking manpower I wouldn't
hold my breath.  I also suspect that no matter how hard we/they work at
it, it'll never work really well simply because of the "impedance
mismatch" between the Android APIs and X11's.

IOW, I think the Termux approach will inevitably remain a crutch.
It's been a handy crutch in the absence of a real Android port, but the
Android port offers a much better user experience, and should make it
possible to write Emacs packages that are actually pleasant to use on
a smartphone.


        Stefan

Re: Android port of Emacs

[Stefan Monnier via Emacs development discussions.]

>> Incorporating code in Emacs doesn't mean that we are obligated to
>> support it or keep it working, it means that we will keep it working to
>> the extent that interested users provide changes to do so.
>
> From my POV, adding a significant new port for a widely-used platform,
> without a commitment to keep that port working for the observable
> future, makes no sense whatsoever.  It's a decision to commit our
> scarce resources when we know in advance that those resources will be
> wasted on code with no future.

IIUC here you're referring to the stream of Android-specific bug reports
that will inevitably come in.  Indeed, that's a problem, since we can
expect that most of those users will tend to be "far" from
being developers.  So we'd need to make sure these bug reports can be
easily recognized.


        Stefan

Re: Android port of Emacs

[Gregory Heytings]

> Emacs is a better terminal emulator than Termux.

That's a too assertive statement.  _Your opinion_ is that Emacs is a 
better terminal emulator than Termux, and that's fine.  Others have 
dissenting, and equally respectable, opinions.

Even if everyone agreed that Emacs is a better terminal emulator than 
Termux, it would not change the fact that Emacs is not a suitable 
replacement for programs such as GIMP or Audacity, which means that users 
who would want to use both Emacs and one of these programs would have to 
install the Termux distro twice.  Which is the problem I pointed to 
initially (or rather, a part of that problem).

>> The correct conclusion would have been that I don't want to play by 
>> your "you should first demonstrate your technical knowledge before 
>> speaking here" rule.
>
> So why are you making (false) claims about the _technical_ details of 
> process execution?
>

I am not.  FTR, what I said is "in all likelihood that hole in Android's 
security policy [the fact that the "write xor execute" policy can be 
circumvented with a hack] will be patched sooner or later".  I maintain 
what I said.  Obviously I can't read in Android developer's minds, so I 
don't know how they will do that.  It is also possible that they will not 
do anything, but if they decide to do something, they could, for example, 
set kernel.yama.ptrace_scope=2, and grant the ptrace capability only to a 
few selected executables.

>
> I am not interested in considering the limitations of Google Play Store 
> policy, for example.
>

The Google Play Store policy is not what is being discussed here, it does 
not directly impact apps that are installed on an Android device.  What is 
being discussed is Android's security policy, which is (or rather: will 
be) enforced on Android devices, independently of the origin of the app.

>> And, by the way, why do you provide an android-use-exec-loader variable 
>> to disable that hack, and do you explain in its docstring that it "may 
>> prove to be problematic for various different reasons", if it is indeed 
>> a good solution?  Its most obvious limit, apart from the overhead it 
>> introduces, is that, given that a ptrace'd process cannot ptrace'd 
>> again, it becomes impossible to use a debugger with that hack.
>
> gdbserver is installed in /system/bin, so it can be run without process 
> tracing.
>

That is inaccurate and misleading.

First, you may be aware that GDB was deprecated, and has now been removed 
from Android.  What Android now provides instead is lldb-server.

Second, lldb-server is not always installed in /system/bin, on some/many 
devices it is not installed at all.  When it is not installed, it can be 
manually installed in /data/local/tmp, but in that case it cannot be used 
by Emacs.

Third, even when lldb-server is installed in /system/bin, the main 
problem, which is not to run a debugger without ptrace'ing the debugger 
itself, but to start the program that is being debugged, is not solved: 
the debugger has to exec that program, but it is in a writable directory, 
so that will be denied by the "write xor execute" security policy.

And you do not explain why you provide an android-use-exec-loader variable 
to disable the hack, and why you explain in its docstring that it "may 
prove to be problematic for various different reasons", if it is indeed a 
good solution.

>
> Besides that, if su is installed on the Android device in question 
> (which is uncommon), Emacs can simply change its security context to 
> `trusted_app'.  For obvious reasons, su cannot work if it is being 
> ptraced.
>

That's irrelevant: this whole discussion, and your hack, are pointless if 
we assume rooted Android devices, on which by definition all security 
measures can be turned off.

Re: Android port of Emacs

[Gregory Heytings]

>> There is another data point that should, I believe, be mentioned: users 
>> who want to run Emacs on an Android device can already do so, with both 
>> its TUI and GUI, without any changes whatsoever on the Emacs side.
>
> FWIW, I tried to use that but found it unbearable.  I can't remember all 
> the annoyances, but there were many, and AFAIK there is no way for *us* 
> to fix them.
>

Many users try to use Emacs and find it unbearable ;-)

More seriously, IMO "unbearable" is too vague.  Which X server did you 
try, with which keyboard if you used a soft keyboard, and with which Emacs 
version?  And which annoyances do you remember?  The Termux:X11 X server 
is under active development, so I'd suggest to try again, and to report 
the annoyances you still experience.

Re: Android port of Emacs

[Stefan Monnier]

[ Talking about Emacs-on-Android via Termux:X11: ]
>> FWIW, I tried to use that but found it unbearable.  I can't remember all
>> the annoyances, but there were many, and AFAIK there is no way for *us* to
>> fix them.
[...]
> More seriously, IMO "unbearable" is too vague.  Which X server did you try,
> with which keyboard if you used a soft keyboard, and with which Emacs
> version?  And which annoyances do you remember?  The Termux:X11 X server is
> under active development, so I'd suggest to try again, and to report the
> annoyances you still experience.

I don't see Termux:X11 as a good long term strategy for Emacs support on
Android, and I find the current `feature/android` already works better
so it's not a good short term option for me any more either.
So I have currently no incentive to contribute bug reports to that project.
But I'm glad it exists and I wish it well :-)


        Stefan

Re: Android port of Emacs

[Gregory Heytings]

>>> FWIW, I tried to use that but found it unbearable.  I can't remember 
>>> all the annoyances, but there were many, and AFAIK there is no way for 
>>> *us* to fix them.
>>
>> More seriously, IMO "unbearable" is too vague.  Which X server did you 
>> try, with which keyboard if you used a soft keyboard, and with which 
>> Emacs version?  And which annoyances do you remember?  The Termux:X11 X 
>> server is under active development, so I'd suggest to try again, and to 
>> report the annoyances you still experience.
>
> I don't see Termux:X11 as a good long term strategy for Emacs support on 
> Android, and I find the current `feature/android` already works better 
> so it's not a good short term option for me any more either. So I have 
> currently no incentive to contribute bug reports to that project. But 
> I'm glad it exists and I wish it well :-)
>

I was not suggesting that you should report bugs to Termux:X11, I was 
asking for something more detailed than "unbearable", which contradicts 
what others said in this thread.

Also, I hope you realize that with the feature/android port you need to 
compile all external programs you need from their sources.

Re: Android port of Emacs

[Spencer Baugh]

Po Lu <luangruo@yahoo.com> writes:
> Óscar Fuentes <ofv@wanadoo.es> writes:
>> Today I tried your port again for about an hour. It is obvious that you
>> use a hardware keyboard ;-) 
>
> Everyone seems to think that, but I don't.

Out of curiosity, which Android software keyboard do you use?  It sounds
like it would be worth trying it.

As a total tangent on the topic of keyboards and input on Android, it
would be nice if completion was integrated with the autocorrect word
suggestion UI element that many Android keyboards have.  Currently when
typing in M-x I get suggestions for regular English words, which seems
wasteful.  Although from some quick searching the web, I don't see a way
to customize this.  Maybe at the very least we could disable the
autocorrect suggestion UI element when typing into M-x?

Re: Android port of Emacs

[Po Lu]

Spencer Baugh <sbaugh@janestreet.com> writes:

> Out of curiosity, which Android software keyboard do you use?

Fcitx for Chinese text and AnySoftKeyboard for English.

> As a total tangent on the topic of keyboards and input on Android, it
> would be nice if completion was integrated with the autocorrect word
> suggestion UI element that many Android keyboards have.  Currently when
> typing in M-x I get suggestions for regular English words, which seems
> wasteful.  Although from some quick searching the web, I don't see a way
> to customize this.  Maybe at the very least we could disable the
> autocorrect suggestion UI element when typing into M-x?

Sadly, there appears to be no interface for Emacs to provide completion
information to the input method itself.  However, the input method
eventually remembers commands you frequently type and offers them as
completions, making its completions useful.

Re: Android port of Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]


Gregory Heytings <gregory@heytings.org> writes:

>>> There is another data point that should, I believe, be mentioned:
>>> users who want to run Emacs on an Android device can already do so,
>>> with both its TUI and GUI, without any changes whatsoever on the
>>> Emacs side.
>>
>> FWIW, I tried to use that but found it unbearable.  I can't remember
>> all the annoyances, but there were many, and AFAIK there is no way
>> for *us* to fix them.
>>
>
> Many users try to use Emacs and find it unbearable ;-)
>
> More seriously, IMO "unbearable" is too vague.  Which X server did you
> try, with which keyboard if you used a soft keyboard, and with which
> Emacs version?  And which annoyances do you remember?  The Termux:X11
> X server is under active development, so I'd suggest to try again, and
> to report the annoyances you still experience.

I would already consider it an improvement to have an official Emacs
version that’s less complex to install *right* on Android.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Android port of Emacs

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]


Po Lu <luangruo@yahoo.com> writes:

>> Today I tried your port again for about an hour. It is obvious that you
>> use a hardware keyboard ;-) 
>
> Everyone seems to think that, but I don't.

To back Po up here, the port is usable with software keyboards too IMO.
Perhaps the only thing that's missing is an (optional) way to input
modifiers without needing keyboards to support them directly, similar to
Termux, and to bring up the keyboard at any point, even when in RO text.
It is possible that these features exist and that I missed them, though.

It was immediately clear to me, however, that there won't be much direct
translation from a desktop workflow to Android, so I skipped directly to
tweaking various GUI elements, which might be why I can't sympathize
with the usability assessment some people had.  This will be some work
for users and developers of Emacs and packages for Emacs in the long
run, to provide a more pointer-approachable UI, however.

I think that, in general, this port shows Emacs as an organizer and note
taker more than as a programming tool, so the lowered accessibility to
advanced text entry shouldn't be too grave, though both are possible,
especially with a hardware keyboard.

What's also missing is the Info viewer reflowing to fill the screen, but
this is a fault in the Info format rather than Emacs.  This has been the
case for a long time but the form-factor on Android is somewhat novel,
so it was never that noticeable.

I've written some code already that uses the Widget library to get a
competent workflow for note-taking and capturing (though I've not
completed this yet), and from my testing, the port (even as it was some
months ago) can be used quite competently.

Overall, I think that the port shows great potential, and can't
sympathize with the reasons for its omission, especially for a system
which isn't always nonfree, as Po seems to be willing to maintain it
long-term.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port of Emacs

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> To back Po up here, the port is usable with software keyboards too IMO.
> Perhaps the only thing that's missing is an (optional) way to input
> modifiers without needing keyboards to support them directly, similar to
> Termux

IMHO, it's not Emacs's job to, in essence, provide another virtual
keyboard in addition to what the user has already installed.  People who
need these modifier keys can use any of the software keyboards that
provide options to display them: AnySoftKeyboard, Hackers Keyboard, et
cetera.

> , and to bring up the keyboard at any point, even when in RO text.
> It is possible that these features exist and that I missed them, though.

This exists, see the option `touch-screen-display-keyboard'.

> It was immediately clear to me, however, that there won't be much direct
> translation from a desktop workflow to Android, so I skipped directly to
> tweaking various GUI elements, which might be why I can't sympathize
> with the usability assessment some people had.  This will be some work
> for users and developers of Emacs and packages for Emacs in the long
> run, to provide a more pointer-approachable UI, however.

Yes, I strongly recommend that people using the Android port without a
mouse or keyboard refrain from hiding any of the display elements that
are often disabled , especially the menu bar.

> I think that, in general, this port shows Emacs as an organizer and note
> taker more than as a programming tool, so the lowered accessibility to
> advanced text entry shouldn't be too grave, though both are possible,
> especially with a hardware keyboard.

Well, I've been using Emacs as both a note taking tool, and as a mail
and news reader.  The nature of my work means that responding to mail
naturally requires some programming, so to each his own ;-)

> What's also missing is the Info viewer reflowing to fill the screen, but
> this is a fault in the Info format rather than Emacs.  This has been the
> case for a long time but the form-factor on Android is somewhat novel,
> so it was never that noticeable.

Perhaps adjusting the fill column while building documentation for
packaging on Android would be a suitable temporary solution for this.

However, I'd really like to see a form of word wrapping that does not
take new line characters into account at all, allowing filled text to be
refilled to fit windows at redisplay time.  I plan to investigate
implementing this some time.

> I've written some code already that uses the Widget library to get a
> competent workflow for note-taking and capturing (though I've not
> completed this yet), and from my testing, the port (even as it was some
> months ago) can be used quite competently.
>
> Overall, I think that the port shows great potential, and can't
> sympathize with the reasons for its omission, especially for a system
> which isn't always nonfree, as Po seems to be willing to maintain it
> long-term.

Thanks for your input.

Re: Android port of Emacs

[Dmitry Gutov]

On 02/07/2023 08:09, Po Lu wrote:
> Spencer Baugh<sbaugh@janestreet.com>  writes:
> 
>> Out of curiosity, which Android software keyboard do you use?
> Fcitx for Chinese text and AnySoftKeyboard for English.
> 

Ok, so you use AnySoftKeyboard with the "Terminal" layout? That took 
some time to find.

How do you input M-x? That would require the keyboard to stick around 
when there is no active input, right?

Do you know if we can associate a particular keyboard app with Emacs, 
and use a different one with other apps?

Re: Android port of Emacs

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Ok, so you use AnySoftKeyboard with the "Terminal" layout? That took
> some time to find.

I use the US English layout by default, but switch to the Terminal
layout when I need cursor keys.

> How do you input M-x? That would require the keyboard to stick around
> when there is no active input, right?

I select Edit -> Execute Command from the menu bar.  (This option only
exists on the branch.)

> Do you know if we can associate a particular keyboard app with Emacs,
> and use a different one with other apps?

IIRC some versions of Android offer such an option, but I looked through
Settings (on LineageOS 18.1) and did not find anything promising.

Thanks.

Re: Android port of Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Spencer Baugh <sbaugh@janestreet.com>,  emacs-devel@gnu.org
> Date: Sun, 02 Jul 2023 20:59:05 +0800
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> > How do you input M-x? That would require the keyboard to stick around
> > when there is no active input, right?
> 
> I select Edit -> Execute Command from the menu bar.  (This option only
> exists on the branch.)

Did you see how JuiceSSH does that?  Its keyboard add-on is very
convenient in use with Emacs, when I need to SSH into a remote host.
It has keys for Ctrl, Alt, Home/End, PgUp/Pgn, ESC, and arrow keys.
Very convenient.

Re: Android port of Emacs

[Dmitry Gutov]

On 02/07/2023 15:59, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> Ok, so you use AnySoftKeyboard with the "Terminal" layout? That took
>> some time to find.
> 
> I use the US English layout by default, but switch to the Terminal
> layout when I need cursor keys.

So you generally make do without Alt/Ctrl/Tab?

>> How do you input M-x? That would require the keyboard to stick around
>> when there is no active input, right?
> 
> I select Edit -> Execute Command from the menu bar.  (This option only
> exists on the branch.)

Nice, thanks.

And I've just found that the "x" button on the toolbar acts as an okay 
replacement for C-g when inside minibuffer.

>> Do you know if we can associate a particular keyboard app with Emacs,
>> and use a different one with other apps?
> 
> IIRC some versions of Android offer such an option, but I looked through
> Settings (on LineageOS 18.1) and did not find anything promising.

That's too bad.

It might be handy to have an Emacs-specific keyboard, with whole 
sequences (such as M-x/C-x/C-c/C-h) assigned to single buttons.

Re: Android port of Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]


Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> To back Po up here, the port is usable with software keyboards too IMO.
>> Perhaps the only thing that's missing is an (optional) way to input
>> modifiers without needing keyboards to support them directly, similar to
>> Termux
>
> IMHO, it's not Emacs's job to, in essence, provide another virtual
> keyboard in addition to what the user has already installed.  People who
> need these modifier keys can use any of the software keyboards that
> provide options to display them: AnySoftKeyboard, Hackers Keyboard, et
> cetera.

Could we provide toolbar-buttons for modifiers via a minor mode?

(I just tried to find a way to send C-x with a command but did not find
it …)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Android port of Emacs

[Ant]

I had some idea in this regard: either remap physical buttons 
(Volume-up/volume-down) or toolbar icons to modifiers/prefix keys. For 
the toolbar, you could put it in bottom position (Po Lu added support 
for this recently in feature/android) so that it would behave similarly 
to the modifiers bar in Termux.

Re: Android port of Emacs

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 4435 bytes --]


Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> To back Po up here, the port is usable with software keyboards too IMO.
>> Perhaps the only thing that's missing is an (optional) way to input
>> modifiers without needing keyboards to support them directly, similar to
>> Termux
>
> IMHO, it's not Emacs's job to, in essence, provide another virtual
> keyboard in addition to what the user has already installed.  People who
> need these modifier keys can use any of the software keyboards that
> provide options to display them: AnySoftKeyboard, Hackers Keyboard, et
> cetera.

I agree, but the angle of "the status quo of this platform can't do
Emacs justice without this feature" outweighs that in my mind.

I expect that most people, including myself, that'd be interested in the
Android port have established muscle memory, and so, would benefit from
continuing to use the same keyboard they had used for a long time.

>> , and to bring up the keyboard at any point, even when in RO text.
>> It is possible that these features exist and that I missed them, though.
>
> This exists, see the option `touch-screen-display-keyboard'.

Ah!  Thanks, that's helpful.

>> It was immediately clear to me, however, that there won't be much direct
>> translation from a desktop workflow to Android, so I skipped directly to
>> tweaking various GUI elements, which might be why I can't sympathize
>> with the usability assessment some people had.  This will be some work
>> for users and developers of Emacs and packages for Emacs in the long
>> run, to provide a more pointer-approachable UI, however.
>
> Yes, I strongly recommend that people using the Android port without a
> mouse or keyboard refrain from hiding any of the display elements that
> are often disabled , especially the menu bar.
>
>> I think that, in general, this port shows Emacs as an organizer and note
>> taker more than as a programming tool, so the lowered accessibility to
>> advanced text entry shouldn't be too grave, though both are possible,
>> especially with a hardware keyboard.
>
> Well, I've been using Emacs as both a note taking tool, and as a mail
> and news reader.  The nature of my work means that responding to mail
> naturally requires some programming, so to each his own ;-)
>
>> What's also missing is the Info viewer reflowing to fill the screen, but
>> this is a fault in the Info format rather than Emacs.  This has been the
>> case for a long time but the form-factor on Android is somewhat novel,
>> so it was never that noticeable.
>
> Perhaps adjusting the fill column while building documentation for
> packaging on Android would be a suitable temporary solution for this.
>
> However, I'd really like to see a form of word wrapping that does not
> take new line characters into account at all, allowing filled text to be
> refilled to fit windows at redisplay time.  I plan to investigate
> implementing this some time.

I'm not sure that's enough to fix the shortcomings of the Info format.
I had intended to work on an Info file format that can be parsed
(almost) just as easily as the current one, but that does not strip
formatting as much as the current one does, this summer; sadly, it seems
that I vastly underestimated how busy my schedule will be.

There's some discussion about this in TODO.HTML in the Texinfo Git
repository, though that focuses on replacing the info-at-rest format
with HTML, which I'm not sure I like yet.  There's a possibility that we
could use CSS heavily to define new elements and similar, to lose less
semantically, and so, to be able to recover formatting in a less
web-oriented fashion for display in the Emacs and standalone info
viewer, but I haven't explored that idea yet.

>> I've written some code already that uses the Widget library to get a
>> competent workflow for note-taking and capturing (though I've not
>> completed this yet), and from my testing, the port (even as it was some
>> months ago) can be used quite competently.
>>
>> Overall, I think that the port shows great potential, and can't
>> sympathize with the reasons for its omission, especially for a system
>> which isn't always nonfree, as Po seems to be willing to maintain it
>> long-term.
>
> Thanks for your input.

Thank you for your work :-)

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port of Emacs

[Stefan Monnier]

> Also, I hope you realize that with the feature/android port you need to
>  compile all external programs you need from their sources.

Not if/when it's distributed/installed as part of Termux :-)


        Stefan

Re: Android port of Emacs

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

On Sun, Jul 2, 2023, 09:16 Dmitry Gutov <dmitry@gutov.dev> wrote:

> On 02/07/2023 15:59, Po Lu wrote:
> > Dmitry Gutov <dmitry@gutov.dev> writes:
> >
> >> Ok, so you use AnySoftKeyboard with the "Terminal" layout? That took
> >> some time to find.
> >
> > I use the US English layout by default, but switch to the Terminal
> > layout when I need cursor keys.
>
> So you generally make do without Alt/Ctrl/Tab?
>
> >> How do you input M-x? That would require the keyboard to stick around
> >> when there is no active input, right?
> >
> > I select Edit -> Execute Command from the menu bar.  (This option only
> > exists on the branch.)
>
> Nice, thanks.
>
> And I've just found that the "x" button on the toolbar acts as an okay
> replacement for C-g when inside minibuffer.
>
> >> Do you know if we can associate a particular keyboard app with Emacs,
> >> and use a different one with other apps?
> >
> > IIRC some versions of Android offer such an option, but I looked through
> > Settings (on LineageOS 18.1) and did not find anything promising.
>
> That's too bad.
>
> It might be handy to have an Emacs-specific keyboard, with whole
> sequences (such as M-x/C-x/C-c/C-h) assigned to single buttons.
>

It seems to me that toolbar would be the place for such things, rather than
something platform specific.

Actually we could even have toolbar buttons for
event-apply-control-modifier and so on. Then a normal keyboard could work
very well.

Although moving the toolbar to the bottom of the screen on Android (as I
saw some feature mentioned) would help with that. And increasing the size
of the icons...

>

[-- Attachment #2: Type: text/html, Size: 2469 bytes --]

Re: Android port of Emacs

[Dmitry Gutov]

On 02/07/2023 18:45, Spencer Baugh wrote:

>     It might be handy to have an Emacs-specific keyboard, with whole
>     sequences (such as M-x/C-x/C-c/C-h) assigned to single buttons.
> 
> 
> It seems to me that toolbar would be the place for such things, rather 
> than something platform specific.
> 
> Actually we could even have toolbar buttons for 
> event-apply-control-modifier and so on. Then a normal keyboard could 
> work very well.
> 
> Although moving the toolbar to the bottom of the screen on Android (as I 
> saw some feature mentioned) would help with that. And increasing the 
> size of the icons...

Yep, you've just described platform-specific UI details. How the Android 
port implements that (natively in Java or with Lisp using the standard 
toolbar) is secondary, but adapting to the specific form-factor (and the 
proximity to the on-screen keyboard) has its benefits.

Eli mentioned JuiceSSH (which for some reason doesn't install on my 
phone, listing itself as "not available") and it has this on the 
screenshots: 
https://play-lh.googleusercontent.com/1rhvZxZHx_IraiVLzqjYHwM1M3lm_HRsTCd_S4VSyEqzr-uNqThx63MtSdrgpDEJBos=w5120-h2880. 
IOW, a bunch of special keys that usually have Emacs bindings but are 
absent on the standard on-screen keyboards.

Here's also a screenshot of Termius: 
https://play-lh.googleusercontent.com/XUYZvSuW9FH9WbwHuZVkhgb5f1Qgx-2WZy_fkQJhziiiA7PS0yw7rywz2vm0RlQCLwSN=w5120-h2880

It also provides easier access to some of those buttons. I haven't 
installed either yet, so not sure how they are implemented (keyboard 
hints or not), maybe also rendered in-app.

Re: Android port of Emacs

[Dmitry Gutov]

On 02/07/2023 19:29, Dmitry Gutov wrote:
> On 02/07/2023 18:45, Spencer Baugh wrote:
> 
>>     It might be handy to have an Emacs-specific keyboard, with whole
>>     sequences (such as M-x/C-x/C-c/C-h) assigned to single buttons.
>>
>>
>> It seems to me that toolbar would be the place for such things, rather 
>> than something platform specific.
>>
>> Actually we could even have toolbar buttons for 
>> event-apply-control-modifier and so on. Then a normal keyboard could 
>> work very well.
>>
>> Although moving the toolbar to the bottom of the screen on Android (as 
>> I saw some feature mentioned) would help with that. And increasing the 
>> size of the icons...
> 
> Yep, you've just described platform-specific UI details. How the Android 
> port implements that (natively in Java or with Lisp using the standard 
> toolbar) is secondary, but adapting to the specific form-factor (and the 
> proximity to the on-screen keyboard) has its benefits.
> 
> Eli mentioned JuiceSSH (which for some reason doesn't install on my 
> phone, listing itself as "not available") and it has this on the 
> screenshots: 
> https://play-lh.googleusercontent.com/1rhvZxZHx_IraiVLzqjYHwM1M3lm_HRsTCd_S4VSyEqzr-uNqThx63MtSdrgpDEJBos=w5120-h2880. IOW, a bunch of special keys that usually have Emacs bindings but are absent on the standard on-screen keyboards.
> 
> Here's also a screenshot of Termius: 
> https://play-lh.googleusercontent.com/XUYZvSuW9FH9WbwHuZVkhgb5f1Qgx-2WZy_fkQJhziiiA7PS0yw7rywz2vm0RlQCLwSN=w5120-h2880
> 
> It also provides easier access to some of those buttons. I haven't 
> installed either yet, so not sure how they are implemented (keyboard 
> hints or not), maybe also rendered in-app.

And here's another example: 
https://play-lh.googleusercontent.com/ZjqY_bYIuWan8ZHOU7Cv0utQEe6j0wRg50nr8c5_WVS2KBvklragHcD_aWm_KJg8RW7o=w5120-h2880

That's xterm app inside DaRemote. While it has 2 rows of buttons, it's 
still pretty compact.

Re: Android port of Emacs

[Spencer Baugh]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Sun, Jul 2, 2023, 12:30 Dmitry Gutov <dmitry@gutov.dev> wrote:

> On 02/07/2023 18:45, Spencer Baugh wrote:
>
> >     It might be handy to have an Emacs-specific keyboard, with whole
> >     sequences (such as M-x/C-x/C-c/C-h) assigned to single buttons.
> >
> >
> > It seems to me that toolbar would be the place for such things, rather
> > than something platform specific.
> >
> > Actually we could even have toolbar buttons for
> > event-apply-control-modifier and so on. Then a normal keyboard could
> > work very well.
> >
> > Although moving the toolbar to the bottom of the screen on Android (as I
> > saw some feature mentioned) would help with that. And increasing the
> > size of the icons...
>
> Yep, you've just described platform-specific UI details.
>
Not necessarily: other touchscreen, no-keyboard platforms could use them
too.

>

[-- Attachment #2: Type: text/html, Size: 1419 bytes --]

Re: Android port of Emacs

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> So you generally make do without Alt/Ctrl/Tab?

That's correct.  I've also fixed lots of packages (like Gnus, Calc, and
CC Mode) to work with only touch screen input on the branch.

> And I've just found that the "x" button on the toolbar acts as an okay
> replacement for C-g when inside minibuffer.

Yes, that was its intended purpose too.

> It might be handy to have an Emacs-specific keyboard, with whole
> sequences (such as M-x/C-x/C-c/C-h) assigned to single buttons.

I agree.  I don't have anything close to an idea about how to write one,
however.

Thanks.

Re: Android port of Emacs

[Po Lu]

Spencer Baugh <sbaugh@janestreet.com> writes:

> It seems to me that toolbar would be the place for such things, rather
> than something platform specific.
>
> Actually we could even have toolbar buttons for
> event-apply-control-modifier and so on. Then a normal keyboard could
> work very well.
>
> Although moving the toolbar to the bottom of the screen on Android (as
> I saw some feature mentioned) would help with that. And increasing the
> size of the icons...

This sounds reasonable, but I think we wouldn't be able to fit enough
items into the tool bar to represent each modifier without it wrapping.

Re: Android port of Emacs

[Po Lu]

Arsen Arsenović <arsen@aarsen.me> writes:

> I agree, but the angle of "the status quo of this platform can't do
> Emacs justice without this feature" outweighs that in my mind.
>
> I expect that most people, including myself, that'd be interested in the
> Android port have established muscle memory, and so, would benefit from
> continuing to use the same keyboard they had used for a long time.

I think I will look into providing modifier keys using the tool bar.

Re: Android port of Emacs

[Jean Louis]

* Po Lu <luangruo@yahoo.com> [2023-06-30 08:14]:
> Please see the instructions at:
> 
>   https://sourceforge.net/projects/android-ports-for-gnu-emacs/files/

I got it. Though to install it is not easy, it requires me to know
which system I have, which CPU, which Android version, and I am not
used to it when installing applications from F-Droid.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port of Emacs

[Jean Louis]

* Dmitry Gutov <dmitry@gutov.dev> [2023-07-02 15:52]:
> On 02/07/2023 08:09, Po Lu wrote:
> > Spencer Baugh<sbaugh@janestreet.com>  writes:
> > 
> > > Out of curiosity, which Android software keyboard do you use?
> > Fcitx for Chinese text and AnySoftKeyboard for English.
> > 
> 
> Ok, so you use AnySoftKeyboard with the "Terminal" layout? That took some
> time to find.
> 
> How do you input M-x? That would require the keyboard to stick around when
> there is no active input, right?

https://f-droid.org/en/packages/org.pocketworkstation.pckeyboard/

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port of Emacs

[Dmitry Gutov]

On 04/07/2023 15:34, Jean Louis wrote:
> * Dmitry Gutov<dmitry@gutov.dev>  [2023-07-02 15:52]:
>> On 02/07/2023 08:09, Po Lu wrote:
>>> Spencer Baugh<sbaugh@janestreet.com>   writes:
>>>
>>>> Out of curiosity, which Android software keyboard do you use?
>>> Fcitx for Chinese text and AnySoftKeyboard for English.
>>>
>> Ok, so you use AnySoftKeyboard with the "Terminal" layout? That took some
>> time to find.
>>
>> How do you input M-x? That would require the keyboard to stick around when
>> there is no active input, right?
> https://f-droid.org/en/packages/org.pocketworkstation.pckeyboard/

Thank you. That still leaves the problem of only using this for Emacs, 
but not other apps.

Re: Android port of Emacs

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]


Po Lu <luangruo@yahoo.com> writes:

> I think I will look into providing modifier keys using the tool bar.

Thank you!

Have a lovely day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Android port of Emacs

[Jean Louis]

* Dmitry Gutov <dmitry@gutov.dev> [2023-07-04 18:48]:
> On 04/07/2023 15:34, Jean Louis wrote:
> > * Dmitry Gutov<dmitry@gutov.dev>  [2023-07-02 15:52]:
> > > On 02/07/2023 08:09, Po Lu wrote:
> > > > Spencer Baugh<sbaugh@janestreet.com>   writes:
> > > > 
> > > > > Out of curiosity, which Android software keyboard do you use?
> > > > Fcitx for Chinese text and AnySoftKeyboard for English.
> > > > 
> > > Ok, so you use AnySoftKeyboard with the "Terminal" layout? That took some
> > > time to find.
> > > 
> > > How do you input M-x? That would require the keyboard to stick around when
> > > there is no active input, right?
> > https://f-droid.org/en/packages/org.pocketworkstation.pckeyboard/
> 
> Thank you. That still leaves the problem of only using this for Emacs, but
> not other apps.

Emacs application we discuss about is usable with any keyboard.

Hackers Keyboard is also usable with any other application.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Android port of Emacs

[Ant]

* Po Lu:

 > I think I will look into providing modifier keys using the tool bar.


Thank you for the addition. They for sure make Emacs for Android (or 
handheld devices in general) much more comfortable to use.

The fact that having a modifier on temporarily overrides the text 
conversion style is very handy. I'd like to have modifiers on physical 
keys too, so I chose to re-use some of your functions:

(define-key local-function-key-map (kbd "<volume-up>") 
#'tool-bar-event-apply-meta-modifier)

(define-key local-function-key-map (kbd "<volume-down>") 
#'tool-bar-event-apply-control-modifier)

And it works good, except when I want both modifiers on: pressing 
<volume-up> and then <volume-down> is recognized as M-<volume-down>.  
The tool-bar-apply-modifiers function does address this issue and in 
fact it is possible to activate multiple modifiers through the new tool 
bar feature, but I'm unable to dig further and try to make it fit with 
physical keys.

I just wanted to address this for everyone who wants to insert modifiers 
on Emacs for Android. And also, thank you again Po Lu for the addition.

Re: Android port of Emacs

[Po Lu]

Ant <ar0x2ff@gmail.com> writes:

> * Po Lu:
>
>> I think I will look into providing modifier keys using the tool bar.
>
>
> Thank you for the addition. They for sure make Emacs for Android (or
> handheld devices in general) much more comfortable to use.
>
> The fact that having a modifier on temporarily overrides the text
> conversion style is very handy. I'd like to have modifiers on physical
> keys too, so I chose to re-use some of your functions:
>
> (define-key local-function-key-map (kbd "<volume-up>")
> #'tool-bar-event-apply-meta-modifier)
>
> (define-key local-function-key-map (kbd "<volume-down>")
> #'tool-bar-event-apply-control-modifier)
>
> And it works good, except when I want both modifiers on: pressing
> <volume-up> and then <volume-down> is recognized as M-<volume-down>. 
> The tool-bar-apply-modifiers function does address this issue and in
> fact it is possible to activate multiple modifiers through the new
> tool bar feature, but I'm unable to dig further and try to make it fit
> with physical keys.
>
> I just wanted to address this for everyone who wants to insert
> modifiers on Emacs for Android. And also, thank you again Po Lu for
> the addition.

The key to applying multiple modifier keys simultaneously is this part
of the function `modifier-bar-buttons':

          (let* ((modifiers init-modifier-list) event1
                 (overriding-text-conversion-style nil)
                 (event (read-event)))
            ;; Combine any more modifier key presses.
            (while (eq event 'tool-bar)
              (setq event1 (event-basic-type (read-event)))
              ;; Reject unknown tool bar events.
              (unless (memq event1 '(alt super hyper shift control meta))
                (user-error "Unknown tool-bar event %s" event1))
              ;; If `event' is the name of a modifier key, apply that
              ;; modifier key as well.
              (unless (memq event1 modifiers)
                (push event1 modifiers)
                ;; This list is used to check which tool bar buttons
                ;; need to be enabled.
                (push event1 modifier-bar-modifier-list))
              ;; Update the tool bar to disable the modifier button
              ;; that was read.
              (force-mode-line-update)
              (redisplay)
              ;; Read another event.
              (setq event (read-event)))

To allow applying multiple modifier keys, you must also check if the
basic type of the event read is either `volume-up' or `volume-down', and
push the appropriate modifier key to `modifiers' and
`modifier-bar-modifier-list' if that is so.  You might want to include
your own version of this function in your customizations, since it's not
exactly relevant to the modifier bar.

Thanks.

Re: Android port of Emacs

[Bryce]

I use Unexpected Keyboard.

Re: Android port of Emacs

[Gregory Heytings]

>>> How do you input M-x? That would require the keyboard to stick around 
>>> when there is no active input, right?
>>
>> I select Edit -> Execute Command from the menu bar.  (This option only 
>> exists on the branch.)
>
> Did you see how JuiceSSH does that?  Its keyboard add-on is very 
> convenient in use with Emacs, when I need to SSH into a remote host. It 
> has keys for Ctrl, Alt, Home/End, PgUp/Pgn, ESC, and arrow keys. Very 
> convenient.
>

Guess what?  Such a keyboard add-on is built-in in both Termux and 
Termux:X11, and what's more it is fully configurable.

Re: Android port of Emacs

[Gregory Heytings]

>>> FWIW, I tried to use [Emacs on Android via Termux:X11] but found it 
>>> unbearable.  I can't remember all the annoyances, but there were many, 
>>> and AFAIK there is no way for *us* to fix them. [...] I have currently 
>>> no incentive to contribute bug reports to that project.
>>
>> I was not suggesting that you should report bugs to Termux:X11, I was 
>> asking for something more detailed than "unbearable", which contradicts 
>> what others said in this thread.
>
> [No reply.]
>

Do you really have nothing more concrete than "unbearable"?

Also, is it not possible that between the moment you tried to use 
Termux:X11 (which started only four years ago and is under active 
development) and now, it has improved, perhaps significantly so?

>> Also, I hope you realize that with the feature/android port you need to 
>> compile all external programs you need from their sources.
>
> Not if/when it's distributed/installed as part of Termux :-)
>

What do you mean?  We're discussing the feature/android branch, not some 
hypothetical variant of it.  For that branch, you need to compile all 
external programs you need from their sources, see e.g. 
https://lists.gnu.org/archive/html/help-gnu-emacs/2023-07/msg00152.html.

What I guess you mean, and what would indeed be possible in theory, is to 
build that branch as an app that shares the same user id as the Termux 
app... but that in turn means that it needs to be signed with the same 
certificate as the Termux app.  So you'd have to convince the Termux 
developers to do that (why would they put that on their shoulders?), or 
alternatively to convince the F-Droid maintainers to do that.  In both 
cases that Emacs would depend on the goodwill of another project to remain 
available.

Re: Android port of Emacs

[Stefan Monnier]

>>> I was not suggesting that you should report bugs to Termux:X11, I was
>>> asking for something more detailed than "unbearable", which contradicts
>>> what others said in this thread.
> Do you really have nothing more concrete than "unbearable"?

No, indeed.  To get something more concrete I'd have to invest more time
to try it again.

> Also, is it not possible that between the moment you tried to use Termux:X11
> (which started only four years ago and is under active development) and
> now, it has improved, perhaps significantly so?

I'm sure it's possible, and I'm really glad they work on this.
I just don't see this as a reason not to include the `feature/android`
code into the main branch of Emacs.

AFAICT you're the one who's saying we should choose one
(Emacs-via-Termux/X11) over the other (Emacs/Android).  I want both.
[ I've also been known to want Emacs's codebase to move towards being
  able to support various GUIs at the same time from the same Emacs
  process.  ]


        Stefan

Re: Android port of Emacs

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Do you really have nothing more concrete than "unbearable"?

How about, for starters, that creating a frame in Emacs results in it
being displayed within the X server, and not as a separate window
managed by Android?  And that Termux, currently supporting only Android
8.0 and later, is incapable of running on the latest release of any FSF
approved Android distribution?

There are also countless other features not offered by running Emacs
within an X server on Android: IMEs, support for the Android virtual
filesystem, opening attachments from other programs, touch screen
support, et cetera.

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> Guess what?  Such a keyboard add-on is built-in in both Termux and
> Termux:X11, and what's more it is fully configurable.

Guess what?  modifier-bar-mode was recently implemented in the
feature/android branch, and is fully configurable through Emacs Lisp.

Re: Android port of Emacs

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> AFAICT you're the one who's saying we should choose one
> (Emacs-via-Termux/X11) over the other (Emacs/Android).  I want both.
> [ I've also been known to want Emacs's codebase to move towards being
>   able to support various GUIs at the same time from the same Emacs
>   process.  ]

I've uploaded prebuilts to

  https://sourceforge.net/projects/android-ports-for-gnu-emacs/files/termux

which can access Termux files and program data.  Brief installation
instructions are also provided in the README.

Would someone please test to see if they work?

Re: Android port of Emacs

[Gregory Heytings]

>
> AFAICT you're the one who's saying we should choose one 
> (Emacs-via-Termux/X11) over the other (Emacs/Android).
>

To set the record straight: no, that's not what I was telling.  I was not 
objecting the inclusion of the Android branch, what I objected to is the 
way Termux was portrayed.  It's a project to which tens if not hundreds of 
people contributed during almost a decade, and I find the way it was 
depicted here inappropriate (to say it charitably).  I'm the only one who 
protested, so I guess I'm the only one to think that.

Many people (I believe O(1000) people, given the results of the latest 
Emacs survey), including (full disclosure) myself, use Emacs inside 
Termux, either in the Termux terminal or with Termux:X11, and it works 
perfectly for them.  See for example Artur Malabarba's blog report [1], 
under which someone asked him "Can you see any theoretical advantage that 
a Native Emacs on Android might have?", to which he replied "I don't 
really see any obvious advantages, except maybe performance."  And that 
was in 2016, in the meantime the situation has improved, in particular 
with Termux:X11 (in which, unlike what has been claimed, input methods 
work perfectly well, and which supports touch events just fine).

There is no need to belittle a project to support another project.  Each 
one has its strengths and weaknesses.  Given how my feedback has been 
received in this thread however, I will not further detail what I believe 
are the respective strengths and weaknesses of these two projects.

[1] http://endlessparentheses.com/running-emacs-on-android.html

Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

> performance."  And that was in 2016,

Many people evidently disagree with his assessment, Stefan and I
included.  Would I have spent eight months of my time writing such a
port otherwise?

> in the meantime the situation has improved, in particular with
> Termux:X11 (in which, unlike what has been claimed, input methods work
> perfectly well, and which supports touch events just fine).

Really?  Can you demonstrate Fcitx5 for Android, Trime, or GBoard
working?  Or something as simple as the English input method's
auto-correct.

My standards for ``working'' refer to operating on the buffer text
itself displayed within Emacs itself, rather than to any transient text
input field provided by the Termux app.  As you well know, this is how
text editing works with input methods on the X desktop.

To utilize input methods on Android, a widget must provide an
implementation of the `getInputConnection' virtual function, and
implement each of the hooks within the input connection returned.

Where exactly in:

  https://github.com/termux/termux-x11/blob/master/app/src/main/java/com/termux/x11/LorieView.java

do you see any of this being performed?

Concerning touch events, the question is now moot since the
feature/android branch was merged.  Prior to that, Emacs could only
employ the X server's mouse event emulation.

All of this doesn't even begin to cover the other features offered by
the Android port, encompassing everything from direct access to the
Android filesystem to operating on Free versions of Android old enough
that support for them has been removed from Termux.

Re: Android port of Emacs

[Eric S Fraga]

On Thursday, 10 Aug 2023 at 11:28, Gregory Heytings wrote:
> I'm the only one who protested, so I guess I'm the only one to think
> that.

You're not alone.  And, more generally, I rely on Emacs via termux daily
(on a mobile device that has a physical keyboard) and I don't
particularly find anything missing that the native port will give me,
but that's me and my particular use case (portable org mode basically).
Not that I'm against a native port.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-08-07) on Debian 12.1

Re: Android port of Emacs

[Stefan Monnier]

> Termux was portrayed.  It's a project to which tens if not hundreds of
> people contributed during almost a decade, and I find the way it was
> depicted here inappropriate (to say it charitably).  I'm the only one who
> protested, so I guess I'm the only one to think that.

I think you misunderstood: I can't speak for others, but while I wasn't
happy with my experience trying to use Emacs on Termux/X11, I'm
a very happy user of Termux in general.


        Stefan

Re: Android port of Emacs

[Eli Zaretskii]

> From: Eric S Fraga <e.fraga@ucl.ac.uk>
> Date: Thu, 10 Aug 2023 14:26:07 +0100
> 
> On Thursday, 10 Aug 2023 at 11:28, Gregory Heytings wrote:
> > I'm the only one who protested, so I guess I'm the only one to think
> > that.
> 
> You're not alone.  And, more generally, I rely on Emacs via termux daily
> (on a mobile device that has a physical keyboard) and I don't
> particularly find anything missing that the native port will give me,
> but that's me and my particular use case (portable org mode basically).
> Not that I'm against a native port.

I don't understand the need for reviving this old thread.  The feature
branch was landed on master, so the Android build is now supported,
and barring any catastrophes, will be released with Emacs 30.  It is
futile to keep arguing about this, so would people please stop?