Android port

Android port

[Po Lu]

I believe the Android port of Emacs is now more or less feature
complete.

It can be found on the feature/android branch of the Emacs repository,
and should support all (mipsel, arm, armv7l, mips64, aarch64 and x86)
Android devices capable of running Android 2.2 or later.  You can obtain
a check out of that code like so:

  $ git clone git://git.sv.gnu.org/emacs.git -b feature/android

Please give it as much testing as you can on real hardware from many
different Android vendors.  Follow the instructions in INSTALL.android
to build and install Emacs for your specific device.  In addition,
please submit patches and report editing modes that do not work well
with the input methods of various on screen keyboards, along with other
bugs, using ``M-x report-emacs-bug RET.''

The answers to various common questions (such as ``how to access
external storage'', or ``where does Emacs put its init.el'') are in the
Android appendix of the Emacs manual in the branch.

Prebuilt binaries will be made available shortly, but please do not
expect them to contain all dependencies with which Emacs can be built.
At present, I don't recommend using binaries from f-droid.org, since
they are out of date, but I will ask the f-droid packagers to rectify
that problem.

I will post this news to comp.emacs; please post this to other forums
frequented by Emacs users as well.

Re: Android port

[Eric S Fraga]

On Friday, 17 Feb 2023 at 19:51, Po Lu wrote:
> I believe the Android port of Emacs is now more or less feature
> complete.

Excellent.  Thank you!

> Prebuilt binaries will be made available shortly, but please do not
> expect them to contain all dependencies with which Emacs can be built.
> At present, I don't recommend using binaries from f-droid.org, since
> they are out of date, but I will ask the f-droid packagers to rectify
> that problem.

I look forward to having these binaries available.  I had already
installed an earlier version from f-droid but would like to test this
latest version.  Note that I am testing on a system probably more suited
to Emacs than the typical phone as mine has a physical keyboard: Planet
Computers Gemini.  Screenshot of Emacs on that phone:

https://fediscience.org/@ericsfraga/109863360504898593

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-02-14) on Debian 11.5

Re: Android port

[Arsen Arsenović]

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

Hi,

Po Lu <luangruo@yahoo.com> writes:

> I believe the Android port of Emacs is now more or less feature
> complete.
>
> It can be found on the feature/android branch of the Emacs repository,
> and should support all (mipsel, arm, armv7l, mips64, aarch64 and x86)
> Android devices capable of running Android 2.2 or later.  You can obtain
> a check out of that code like so:
>
>   $ git clone git://git.sv.gnu.org/emacs.git -b feature/android
>
> Please give it as much testing as you can on real hardware from many
> different Android vendors.  Follow the instructions in INSTALL.android
> to build and install Emacs for your specific device.  In addition,
> please submit patches and report editing modes that do not work well
> with the input methods of various on screen keyboards, along with other
> bugs, using ``M-x report-emacs-bug RET.''
>
> The answers to various common questions (such as ``how to access
> external storage'', or ``where does Emacs put its init.el'') are in the
> Android appendix of the Emacs manual in the branch.
>
> Prebuilt binaries will be made available shortly, but please do not
> expect them to contain all dependencies with which Emacs can be built.
> At present, I don't recommend using binaries from f-droid.org, since
> they are out of date, but I will ask the f-droid packagers to rectify
> that problem.
>
> I will post this news to comp.emacs; please post this to other forums
> frequented by Emacs users as well.

Thanks for the effort.  I was quite excited for this.

For now, I was trying to make an out-of-tree build without gnutls.  This
configuration appears to be broken (though, not due to gnutls):

  make[2]: Entering directory '/home/arsen/gnu/emacs-android/build/java'
  make[2]: *** No rule to make target '../java/Makefile.in', needed by 'Makefile'.  Stop.
  make[2]: Leaving directory '/home/arsen/gnu/emacs-android/build/java'

I'll report a fix when I come up with one.

Have a lovely day.
-- 
Arsen Arsenović

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

Re: Android port

[Po Lu]

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

> Hi,
>
> Po Lu <luangruo@yahoo.com> writes:
>
>> I believe the Android port of Emacs is now more or less feature
>> complete.
>>
>> It can be found on the feature/android branch of the Emacs repository,
>> and should support all (mipsel, arm, armv7l, mips64, aarch64 and x86)
>> Android devices capable of running Android 2.2 or later.  You can obtain
>> a check out of that code like so:
>>
>>   $ git clone git://git.sv.gnu.org/emacs.git -b feature/android
>>
>> Please give it as much testing as you can on real hardware from many
>> different Android vendors.  Follow the instructions in INSTALL.android
>> to build and install Emacs for your specific device.  In addition,
>> please submit patches and report editing modes that do not work well
>> with the input methods of various on screen keyboards, along with other
>> bugs, using ``M-x report-emacs-bug RET.''
>>
>> The answers to various common questions (such as ``how to access
>> external storage'', or ``where does Emacs put its init.el'') are in the
>> Android appendix of the Emacs manual in the branch.
>>
>> Prebuilt binaries will be made available shortly, but please do not
>> expect them to contain all dependencies with which Emacs can be built.
>> At present, I don't recommend using binaries from f-droid.org, since
>> they are out of date, but I will ask the f-droid packagers to rectify
>> that problem.
>>
>> I will post this news to comp.emacs; please post this to other forums
>> frequented by Emacs users as well.
>
> Thanks for the effort.  I was quite excited for this.
>
> For now, I was trying to make an out-of-tree build without gnutls.  This
> configuration appears to be broken (though, not due to gnutls):
>
>   make[2]: Entering directory '/home/arsen/gnu/emacs-android/build/java'
>   make[2]: *** No rule to make target '../java/Makefile.in', needed by 'Makefile'.  Stop.
>   make[2]: Leaving directory '/home/arsen/gnu/emacs-android/build/java'
>
> I'll report a fix when I come up with one.
>
> Have a lovely day.

Out of tree builds are currently not supported because of some specifics
related to the ``aapt'' tool and ``ndk-build'' system used by Android.

I'd not attempt wasting time trying to fix that.

Re: Android port

[Arsen Arsenović]

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

Hi,

Po Lu <luangruo@yahoo.com> writes:

> Out of tree builds are currently not supported because of some specifics
> related to the ``aapt'' tool and ``ndk-build'' system used by Android.
>
> I'd not attempt wasting time trying to fix that.

Sure.  In-tree worked as expected, and I see Emacs on the phone.  I'll
try porting more tangible parts of my scripts in a few days.

Thanks.
-- 
Arsen Arsenović

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

Re: Android port

[tomas]

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

On Fri, Feb 17, 2023 at 07:51:42PM +0800, Po Lu wrote:
> I believe the Android port of Emacs is now more or less feature
> complete.

Not an Android user here, but: this is huge. Thanks a lot!

Cheers
-- 
t

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

Re: Android port

[Arsen Arsenović]

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

Hi,

While building initially, I got some make errors that looked like they
were from a race, for example:

    GEN         execinfo.h
  mv: cannot stat 'execinfo.h-t': No such file or directory

Further confirming my suspicion that these are coming from a race is
Emacs compiling fine if make is reinvoked, and that a non-parallel make
build works fine.

I figured this was a fluke initially, but, I reproduced the issue today.
You can fetch the build log from here:
https://www.aarsen.me/~arsen/emacs-races.script

There also appears to be a dependency missing between generating the APK
and running the pdumper, or such, since I could re-run make after make
concluded in the nonparallel case.

This seems pretty reproducible on my machine, I suspect due to the large
number of -t files utilized in Gnulib.

-- 8< --

While I'm around, I was also thinking about how to enable using the
modifier keys on virtual keyboards without modifiers.  I was considering
mapping a key, say, KEYCODE_VOLUME_DOWN to ESC if pressed and Ctrl if
held in combination with another key, hence, the sequence Press VolDown,
Release VolDown, Press VolDown, Type x, Release VolDown would be parsed
as ESC C-x, or C-M-x.  Do you know if this is possible?  All methods
that I know rely on external tools (XKB configs, AHK, ...) that are not
available on android.

Thanks in advance.
-- 
Arsen Arsenović

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

Re: Android port

[Po Lu]

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

> Hi,
>
> While building initially, I got some make errors that looked like they
> were from a race, for example:
>
>     GEN         execinfo.h
>   mv: cannot stat 'execinfo.h-t': No such file or directory
>
> Further confirming my suspicion that these are coming from a race is
> Emacs compiling fine if make is reinvoked, and that a non-parallel make
> build works fine.
>
> I figured this was a fluke initially, but, I reproduced the issue today.
> You can fetch the build log from here:
> https://www.aarsen.me/~arsen/emacs-races.script
>
> There also appears to be a dependency missing between generating the APK
> and running the pdumper, or such, since I could re-run make after make
> concluded in the nonparallel case.

This should not be a problem, since the dumping happens on-device on
Android.

> This seems pretty reproducible on my machine, I suspect due to the large
> number of -t files utilized in Gnulib.

I will look into this, thanks.

> While I'm around, I was also thinking about how to enable using the
> modifier keys on virtual keyboards without modifiers.  I was considering
> mapping a key, say, KEYCODE_VOLUME_DOWN to ESC if pressed and Ctrl if
> held in combination with another key, hence, the sequence Press VolDown,
> Release VolDown, Press VolDown, Type x, Release VolDown would be parsed
> as ESC C-x, or C-M-x.  Do you know if this is possible?  All methods
> that I know rely on external tools (XKB configs, AHK, ...) that are not
> available on android.

I'm not sure how to do this, since those keys are not ``meta modifiers''
on the system.

I'd recommend an on screen keyboard which has those modifier keys
instead.

Re: Android port

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Hi,
>>
>> While building initially, I got some make errors that looked like they
>> were from a race, for example:
>>
>>     GEN         execinfo.h
>>   mv: cannot stat 'execinfo.h-t': No such file or directory
>>
>> Further confirming my suspicion that these are coming from a race is
>> Emacs compiling fine if make is reinvoked, and that a non-parallel make
>> build works fine.
>>
>> I figured this was a fluke initially, but, I reproduced the issue today.
>> You can fetch the build log from here:
>> https://www.aarsen.me/~arsen/emacs-races.script
>>
>> There also appears to be a dependency missing between generating the APK
>> and running the pdumper, or such, since I could re-run make after make
>> concluded in the nonparallel case.
>
> This should not be a problem, since the dumping happens on-device on
> Android.
>
>> This seems pretty reproducible on my machine, I suspect due to the large
>> number of -t files utilized in Gnulib.
>
> I will look into this, thanks.
>
>> While I'm around, I was also thinking about how to enable using the
>> modifier keys on virtual keyboards without modifiers.  I was considering
>> mapping a key, say, KEYCODE_VOLUME_DOWN to ESC if pressed and Ctrl if
>> held in combination with another key, hence, the sequence Press VolDown,
>> Release VolDown, Press VolDown, Type x, Release VolDown would be parsed
>> as ESC C-x, or C-M-x.  Do you know if this is possible?  All methods
>> that I know rely on external tools (XKB configs, AHK, ...) that are not
>> available on android.
>
> I'm not sure how to do this, since those keys are not ``meta modifiers''
> on the system.
>
> I'd recommend an on screen keyboard which has those modifier keys
> instead.

Please see if the parallel build has been fixed.  Thanks.

Re: Android port

[Arsen Arsenović]

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

Hi,

Po Lu <luangruo@yahoo.com> writes:

> Please see if the parallel build has been fixed.  Thanks.

One build passed fine, so my guess is yes.  I'll let it spin for a bit
with GNU Make's --shuffle, too, and report if anything comes up.

Thanks!

Have a lovely day.
-- 
Arsen Arsenović

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

Re: Android port

[Arsen Arsenović]

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

Hi,

Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Hi,
>>
>> While building initially, I got some make errors that looked like they
>> were from a race, for example:
>>
>>     GEN         execinfo.h
>>   mv: cannot stat 'execinfo.h-t': No such file or directory
>>
>> Further confirming my suspicion that these are coming from a race is
>> Emacs compiling fine if make is reinvoked, and that a non-parallel make
>> build works fine.
>>
>> I figured this was a fluke initially, but, I reproduced the issue today.
>> You can fetch the build log from here:
>> https://www.aarsen.me/~arsen/emacs-races.script
>>
>> There also appears to be a dependency missing between generating the APK
>> and running the pdumper, or such, since I could re-run make after make
>> concluded in the nonparallel case.
>
> This should not be a problem, since the dumping happens on-device on
> Android.

Ah, OK.

>> This seems pretty reproducible on my machine, I suspect due to the large
>> number of -t files utilized in Gnulib.
>
> I will look into this, thanks.
>
>> While I'm around, I was also thinking about how to enable using the
>> modifier keys on virtual keyboards without modifiers.  I was considering
>> mapping a key, say, KEYCODE_VOLUME_DOWN to ESC if pressed and Ctrl if
>> held in combination with another key, hence, the sequence Press VolDown,
>> Release VolDown, Press VolDown, Type x, Release VolDown would be parsed
>> as ESC C-x, or C-M-x.  Do you know if this is possible?  All methods
>> that I know rely on external tools (XKB configs, AHK, ...) that are not
>> available on android.
>
> I'm not sure how to do this, since those keys are not ``meta modifiers''
> on the system.
>
> I'd recommend an on screen keyboard which has those modifier keys
> instead.

Indeed, that'd require some state tracking, for instance, on press reset
a special-as-ctrl flag and set a special-held flag, if anything else is
typed interpret it as C-<N> if special-held is set and set
special-as-ctrl, and on key release, reset special-held and emit an ESC
if special-as-ctrl is reset.

I'm not aware of a better solution because, as you said, these keys
aren't modifiers, and register as normal keypresses.

My thinking here is that providing an alternative for folk who don't use
virtual keyboards with modifier keys already (which is, most likely,
almost everyone) could ease their transition and help them with muscle
memory.

Have a splendid day.
-- 
Arsen Arsenović

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

Re: Android port

[Arsen Arsenović]

[-- Attachment #1.1: Type: text/plain, Size: 4216 bytes --]

Hi,

I encountered another one:

  javac -classpath "/home/arsen/Android/Sdk/platforms/android-Tiramisu/android.jar:." -target 1.7 -source 1.7 -Xlint:d
  eprecation org/gnu/emacs/EmacsContextMenu.java
  warning: [options] bootstrap class path not set in conjunction with -source 7
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  org/gnu/emacs/EmacsContextMenu.java:265: error: cannot find symbol
      final Holder<Boolean> rc;
            ^
    symbol:   class Holder
    location: class EmacsContextMenu
  org/gnu/emacs/EmacsContextMenu.java:267: error: cannot find symbol
      rc = new Holder<Boolean> ();
               ^
    symbol:   class Holder
    location: class EmacsContextMenu
  2 errors
  4 warnings
  make[2]: *** [Makefile:261: org/gnu/emacs/EmacsContextMenu.class] Error 1 shuffle=2758590628

I tried replicating with that shuffle= value, but it seems that I did
not get lucky twice.  However, I believe I have the reason why:

  ~/gnu/emacs-android2 130 $ grep -r --include='*.java' Holder
  java/org/gnu/emacs/EmacsService.java:class Holder<T>
  java/org/gnu/emacs/EmacsService.java:    final Holder<EmacsView> view;
  java/org/gnu/emacs/EmacsService.java:    view = new Holder<EmacsView> ();
  java/org/gnu/emacs/EmacsService.java:    final Holder<ClipboardManager> manager;
  java/org/gnu/emacs/EmacsService.java:    manager = new Holder<ClipboardManager> ();
  java/org/gnu/emacs/EmacsDialog.java:    final Holder<Boolean> rc;
  java/org/gnu/emacs/EmacsDialog.java:    rc = new Holder<Boolean> ();
  java/org/gnu/emacs/EmacsContextMenu.java:    final Holder<Boolean> rc;
  java/org/gnu/emacs/EmacsContextMenu.java:    rc = new Holder<Boolean> ();

There is no dependency between these Holder<T> users and the .java that
provides it:

  ~/gnu/emacs-android2/java$ rm org/gnu/emacs/EmacsDialog.class
  ~/gnu/emacs-android2/java$ make org/gnu/emacs/EmacsDialog.class
    JAVAC    org/gnu/emacs/EmacsDialog.class
  warning: [options] bootstrap class path not set in conjunction with -source 7
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  org/gnu/emacs/EmacsDialog.java:302: error: cannot find symbol
      final Holder<Boolean> rc;
            ^
    symbol:   class Holder
    location: class EmacsDialog
  org/gnu/emacs/EmacsDialog.java:304: error: cannot find symbol
      rc = new Holder<Boolean> ();
               ^
    symbol:   class Holder
    location: class EmacsDialog
  2 errors
  4 warnings
  make: *** [Makefile:261: org/gnu/emacs/EmacsDialog.class] Error 1
  ~/gnu/emacs-android2/java 2 $ rm org/gnu/emacs/EmacsService.class; make org/gnu/emacs/EmacsService.class
    JAVAC    org/gnu/emacs/EmacsService.class
  warning: [options] bootstrap class path not set in conjunction with -source 7
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  4 warnings
  ~/gnu/emacs-android2/java$ make org/gnu/emacs/EmacsDialog.class
    JAVAC    org/gnu/emacs/EmacsDialog.class
  warning: [options] bootstrap class path not set in conjunction with -source 7
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  4 warnings
  ~/gnu/emacs-android2/java$ 

The simplest way to fix it is probably to break out Holder<T> into
Holder.java, as that won't require manually bookkeeping the
dependencies.  I attached a patch, which builds on x86_64-pc-linux-gnu.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: [PATCH] java: Resolve possible parallelism error across Holder class --]
[-- Type: text/x-patch, Size: 1333 bytes --]

From faf8fc54ad1d835d843e33833715eed2af83d517 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= <arsen@aarsen.me>
Date: Sun, 19 Feb 2023 16:21:02 +0100
Subject: [PATCH] java: Resolve possible parallelism error across Holder class

* java/org/gnu/emacs/EmacsService.java (Holder): Move from here
to...
* java/org/gnu/emacs/Holder.java: ... here.  New file.
---
 java/org/gnu/emacs/EmacsService.java | 5 -----
 java/org/gnu/emacs/Holder.java       | 6 ++++++
 2 files changed, 6 insertions(+), 5 deletions(-)
 create mode 100644 java/org/gnu/emacs/Holder.java

diff --git a/java/org/gnu/emacs/EmacsService.java b/java/org/gnu/emacs/EmacsService.java
index ba6ec485d62..18cbb06eaa8 100644
--- a/java/org/gnu/emacs/EmacsService.java
+++ b/java/org/gnu/emacs/EmacsService.java
@@ -62,11 +62,6 @@
 
 import android.hardware.input.InputManager;
 
-class Holder<T>
-{
-  T thing;
-};
-
 /* EmacsService is the service that starts the thread running Emacs
    and handles requests by that Emacs instance.  */
 
diff --git a/java/org/gnu/emacs/Holder.java b/java/org/gnu/emacs/Holder.java
new file mode 100644
index 00000000000..41866084ab9
--- /dev/null
+++ b/java/org/gnu/emacs/Holder.java
@@ -0,0 +1,6 @@
+package org.gnu.emacs;
+
+class Holder<T>
+{
+  T thing;
+};
-- 
2.39.2


[-- Attachment #1.3: Type: text/plain, Size: 149 bytes --]


I also tested the above by making EmacsDialog.class on a clean
configure, triggering the edge case.

Thanks in advance.
-- 
Arsen Arsenović

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

Re: Android port

[Po Lu]

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

> Hi,
>
> I encountered another one:
>
>   javac -classpath "/home/arsen/Android/Sdk/platforms/android-Tiramisu/android.jar:." -target 1.7 -source 1.7 -Xlint:d
>   eprecation org/gnu/emacs/EmacsContextMenu.java
>   warning: [options] bootstrap class path not set in conjunction with -source 7
>   warning: [options] source value 7 is obsolete and will be removed in a future release
>   warning: [options] target value 7 is obsolete and will be removed in a future release
>   warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
>   org/gnu/emacs/EmacsContextMenu.java:265: error: cannot find symbol
>       final Holder<Boolean> rc;
>             ^
>     symbol:   class Holder
>     location: class EmacsContextMenu
>   org/gnu/emacs/EmacsContextMenu.java:267: error: cannot find symbol
>       rc = new Holder<Boolean> ();
>                ^
>     symbol:   class Holder
>     location: class EmacsContextMenu
>   2 errors
>   4 warnings
>   make[2]: *** [Makefile:261: org/gnu/emacs/EmacsContextMenu.class] Error 1 shuffle=2758590628
>
> I tried replicating with that shuffle= value, but it seems that I did
> not get lucky twice.  However, I believe I have the reason why:
>
>   ~/gnu/emacs-android2 130 $ grep -r --include='*.java' Holder
>   java/org/gnu/emacs/EmacsService.java:class Holder<T>
>   java/org/gnu/emacs/EmacsService.java:    final Holder<EmacsView> view;
>   java/org/gnu/emacs/EmacsService.java:    view = new Holder<EmacsView> ();
>   java/org/gnu/emacs/EmacsService.java:    final Holder<ClipboardManager> manager;
>   java/org/gnu/emacs/EmacsService.java:    manager = new Holder<ClipboardManager> ();
>   java/org/gnu/emacs/EmacsDialog.java:    final Holder<Boolean> rc;
>   java/org/gnu/emacs/EmacsDialog.java:    rc = new Holder<Boolean> ();
>   java/org/gnu/emacs/EmacsContextMenu.java:    final Holder<Boolean> rc;
>   java/org/gnu/emacs/EmacsContextMenu.java:    rc = new Holder<Boolean> ();
>
> There is no dependency between these Holder<T> users and the .java that
> provides it:
>
>   ~/gnu/emacs-android2/java$ rm org/gnu/emacs/EmacsDialog.class
>   ~/gnu/emacs-android2/java$ make org/gnu/emacs/EmacsDialog.class
>     JAVAC    org/gnu/emacs/EmacsDialog.class
>   warning: [options] bootstrap class path not set in conjunction with -source 7
>   warning: [options] source value 7 is obsolete and will be removed in a future release
>   warning: [options] target value 7 is obsolete and will be removed in a future release
>   warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
>   org/gnu/emacs/EmacsDialog.java:302: error: cannot find symbol
>       final Holder<Boolean> rc;
>             ^
>     symbol:   class Holder
>     location: class EmacsDialog
>   org/gnu/emacs/EmacsDialog.java:304: error: cannot find symbol
>       rc = new Holder<Boolean> ();
>                ^
>     symbol:   class Holder
>     location: class EmacsDialog
>   2 errors
>   4 warnings
>   make: *** [Makefile:261: org/gnu/emacs/EmacsDialog.class] Error 1
>   ~/gnu/emacs-android2/java 2 $ rm org/gnu/emacs/EmacsService.class; make org/gnu/emacs/EmacsService.class
>     JAVAC    org/gnu/emacs/EmacsService.class
>   warning: [options] bootstrap class path not set in conjunction with -source 7
>   warning: [options] source value 7 is obsolete and will be removed in a future release
>   warning: [options] target value 7 is obsolete and will be removed in a future release
>   warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
>   4 warnings
>   ~/gnu/emacs-android2/java$ make org/gnu/emacs/EmacsDialog.class
>     JAVAC    org/gnu/emacs/EmacsDialog.class
>   warning: [options] bootstrap class path not set in conjunction with -source 7
>   warning: [options] source value 7 is obsolete and will be removed in a future release
>   warning: [options] target value 7 is obsolete and will be removed in a future release
>   warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
>   4 warnings
>   ~/gnu/emacs-android2/java$ 
>
> The simplest way to fix it is probably to break out Holder<T> into
> Holder.java, as that won't require manually bookkeeping the
> dependencies.  I attached a patch, which builds on x86_64-pc-linux-gnu.
>
> From faf8fc54ad1d835d843e33833715eed2af83d517 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= <arsen@aarsen.me>
> Date: Sun, 19 Feb 2023 16:21:02 +0100
> Subject: [PATCH] java: Resolve possible parallelism error across Holder class
>
> * java/org/gnu/emacs/EmacsService.java (Holder): Move from here
> to...
> * java/org/gnu/emacs/Holder.java: ... here.  New file.
> ---
>  java/org/gnu/emacs/EmacsService.java | 5 -----
>  java/org/gnu/emacs/Holder.java       | 6 ++++++
>  2 files changed, 6 insertions(+), 5 deletions(-)
>  create mode 100644 java/org/gnu/emacs/Holder.java
>
> diff --git a/java/org/gnu/emacs/EmacsService.java b/java/org/gnu/emacs/EmacsService.java
> index ba6ec485d62..18cbb06eaa8 100644
> --- a/java/org/gnu/emacs/EmacsService.java
> +++ b/java/org/gnu/emacs/EmacsService.java
> @@ -62,11 +62,6 @@
>  
>  import android.hardware.input.InputManager;
>  
> -class Holder<T>
> -{
> -  T thing;
> -};
> -
>  /* EmacsService is the service that starts the thread running Emacs
>     and handles requests by that Emacs instance.  */
>  
> diff --git a/java/org/gnu/emacs/Holder.java b/java/org/gnu/emacs/Holder.java
> new file mode 100644
> index 00000000000..41866084ab9
> --- /dev/null
> +++ b/java/org/gnu/emacs/Holder.java
> @@ -0,0 +1,6 @@
> +package org.gnu.emacs;
> +
> +class Holder<T>
> +{
> +  T thing;
> +};
> -- 
> 2.39.2
>
>
> I also tested the above by making EmacsDialog.class on a clean
> configure, triggering the edge case.
>
> Thanks in advance.

Thanks.  The make depends thing is supposed to be done by javac
internally, and it should scan through source files in
org/gnu/emacs to find missing definitions.

I will try to fix the group rule definition.

tree-sitter and Android port

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> I believe the Android port of Emacs is now more or less feature
> complete.

I've added support for tree-sitter to the Android port, and ported that
library to our Android build system as well.

However, there is one problem.  Android does not let Emacs link with any
shared libraries or run any executables installed in non-system
directories, meaning that compiled grammars cannot be installed in a
useful fashion.  This is done for security reasons, as apparently many
Android programs have been tricked into executing malicious downloaded
code in the past.

Would one of you two (Yuan Fu or Theodor) please ask the tree-sitter
developers if there is a way to solve this problem (i.e. by having
tree-sitter provide a way to ``interpret'' uncompiled grammar files.)

Thanks in advance.

Re: Android port

[Arsen Arsenović]

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

Hi Po,

Po Lu <luangruo@yahoo.com> writes:

> Thanks.  The make depends thing is supposed to be done by javac
> internally, and it should scan through source files in
> org/gnu/emacs to find missing definitions.

I believe it only scans through source files listed on the command line
and through the classpath.

> I will try to fix the group rule definition.

Yes, I believe this is the proper fix.  I was getting a bunch of other
errors in similar vein after fixing the one above, except even stranger,
so I suspect javac is quite bad at parallelizing.  The group build you
pushed earlier should alleviate that at a slight hit to compile speed
(which I doubt it's major enough to warrant build-time instability).

Thanks.
-- 
Arsen Arsenović

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

Re: tree-sitter and Android port

[Arsen Arsenović]

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

Hi,

Po Lu <luangruo@yahoo.com> writes:

> I've added support for tree-sitter to the Android port, and ported that
> library to our Android build system as well.

Thanks, that should greatly improve the efficiency of fontification in
due time.

> However, there is one problem.  Android does not let Emacs link with any
> shared libraries or run any executables installed in non-system
> directories, meaning that compiled grammars cannot be installed in a
> useful fashion.  This is done for security reasons, as apparently many
> Android programs have been tricked into executing malicious downloaded
> code in the past.

Based on my prior experience with Termux, I suspect that the Emacs home
directory should work.  Termux is able to both build and launch programs
in that directory, and I suspect also dlopen () libraries, though I have
not tried that.

> Would one of you two (Yuan Fu or Theodor) please ask the tree-sitter
> developers if there is a way to solve this problem (i.e. by having
> tree-sitter provide a way to ``interpret'' uncompiled grammar files.)
>
> Thanks in advance.

P.S: I noticed that the Termux wiki lists some file managers that
integrate with SAF, and hence, should be able to access the home
directory on devices with poor built-in file managers:
https://wiki.termux.com/wiki/Internal_and_external_storage

While the manual should probably skirt from naming specific file
managers, it could be good to name what a file manager needs to be able
to access the Emacs home directory (namely, SAF support).

Thanks in advance.
-- 
Arsen Arsenović

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

Re: Android port

[Po Lu]

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

> Hi Po,
>
> Po Lu <luangruo@yahoo.com> writes:
>
>> Thanks.  The make depends thing is supposed to be done by javac
>> internally, and it should scan through source files in
>> org/gnu/emacs to find missing definitions.
>
> I believe it only scans through source files listed on the command line
> and through the classpath.

org/gnu/emacs is in the classpath.

> Yes, I believe this is the proper fix.  I was getting a bunch of other
> errors in similar vein after fixing the one above, except even stranger,
> so I suspect javac is quite bad at parallelizing.  The group build you
> pushed earlier should alleviate that at a slight hit to compile speed
> (which I doubt it's major enough to warrant build-time instability).

Thanks for finding this bug in javac.

Re: Android port

[Arsen Arsenović]

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


Po Lu <luangruo@yahoo.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> Hi Po,
>>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> Thanks.  The make depends thing is supposed to be done by javac
>>> internally, and it should scan through source files in
>>> org/gnu/emacs to find missing definitions.
>>
>> I believe it only scans through source files listed on the command line
>> and through the classpath.
>
> org/gnu/emacs is in the classpath.

Yes, and the sourcepath too, but I don't think the sources in those
paths are re-parsed to grab class definitions on each build, which is
where the problem stems for, but are instead parsed on an as needed
basis, with the classes available being presumed to map 1-to-1 to the
list of .java files in the sourcepath.

>> Yes, I believe this is the proper fix.  I was getting a bunch of other
>> errors in similar vein after fixing the one above, except even stranger,
>> so I suspect javac is quite bad at parallelizing.  The group build you
>> pushed earlier should alleviate that at a slight hit to compile speed
>> (which I doubt it's major enough to warrant build-time instability).
>
> Thanks for finding this bug in javac.

Sure, if you end up reporting it, please keep me posted.  I'm curious
about what the intended behavior here is.

Thanks.
-- 
Arsen Arsenović

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

Re: tree-sitter and Android port

[Po Lu]

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

> Hi,
>
> Po Lu <luangruo@yahoo.com> writes:
>
>> I've added support for tree-sitter to the Android port, and ported that
>> library to our Android build system as well.
>
> Thanks, that should greatly improve the efficiency of fontification in
> due time.
>
>> However, there is one problem.  Android does not let Emacs link with any
>> shared libraries or run any executables installed in non-system
>> directories, meaning that compiled grammars cannot be installed in a
>> useful fashion.  This is done for security reasons, as apparently many
>> Android programs have been tricked into executing malicious downloaded
>> code in the past.
>
> Based on my prior experience with Termux, I suspect that the Emacs home
> directory should work.  Termux is able to both build and launch programs
> in that directory, and I suspect also dlopen () libraries, though I have
> not tried that.

Termux has taken the approach of targeting an older version of Android
without these restrictions, meaning that it will no longer install on
some soon-to-be future version of Android; Android 14 will no longer
allow installing applications targeting Android 5.1 or later, and they
plan to ``progressively ramp up'' the target version requirement.

> P.S: I noticed that the Termux wiki lists some file managers that
> integrate with SAF, and hence, should be able to access the home
> directory on devices with poor built-in file managers:
> https://wiki.termux.com/wiki/Internal_and_external_storage
>
> While the manual should probably skirt from naming specific file
> managers, it could be good to name what a file manager needs to be able
> to access the Emacs home directory (namely, SAF support).

If they are free software, I don't see a problem with listing them in
the manual.

Re: tree-sitter and Android port

[Yuan Fu]

> On Feb 20, 2023, at 6:23 AM, Po Lu <luangruo@yahoo.com> wrote:
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
>> I believe the Android port of Emacs is now more or less feature
>> complete.
> 
> I've added support for tree-sitter to the Android port, and ported that
> library to our Android build system as well.
> 
> However, there is one problem.  Android does not let Emacs link with any
> shared libraries or run any executables installed in non-system
> directories, meaning that compiled grammars cannot be installed in a
> useful fashion.  This is done for security reasons, as apparently many
> Android programs have been tricked into executing malicious downloaded
> code in the past.
> 
> Would one of you two (Yuan Fu or Theodor) please ask the tree-sitter
> developers if there is a way to solve this problem (i.e. by having
> tree-sitter provide a way to ``interpret'' uncompiled grammar files.)
> 
> Thanks in advance.

I’ve looked at this before. The “uncompiled grammar file”, grammar.c, not only contains static data, but also functions. Some language also requires a scanner.cc <http://scanner.cc/> file which contains nontrivial functions. So to “interpret” the grammar file you essentially need a C (and sometimes even C++) compiler.

Yuan

Re: tree-sitter and Android port

[Po Lu]

Yuan Fu <casouri@gmail.com> writes:

> I’ve looked at this before. The “uncompiled grammar file”, grammar.c,
> not only contains static data, but also functions. Some language also
> requires a scanner.cc <http://scanner.cc/> file which contains
> nontrivial functions. So to “interpret” the grammar file you
> essentially need a C (and sometimes even C++) compiler.

Is there any chance of this situation changing?

In the future, we will see more and more systems where these kinds of
restrictions are common, so it would be a good idea for a solution to be
found.  Thanks.

Re: Android port

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> I believe the Android port of Emacs is now more or less feature
> complete.
>
> It can be found on the feature/android branch of the Emacs repository,
> and should support all (mipsel, arm, armv7l, mips64, aarch64 and x86)
> Android devices capable of running Android 2.2 or later.  You can obtain
> a check out of that code like so:
>
>   $ git clone git://git.sv.gnu.org/emacs.git -b feature/android
>
> Please give it as much testing as you can on real hardware from many
> different Android vendors.  Follow the instructions in INSTALL.android
> to build and install Emacs for your specific device.  In addition,
> please submit patches and report editing modes that do not work well
> with the input methods of various on screen keyboards, along with other
> bugs, using ``M-x report-emacs-bug RET.''
>
> The answers to various common questions (such as ``how to access
> external storage'', or ``where does Emacs put its init.el'') are in the
> Android appendix of the Emacs manual in the branch.
>
> Prebuilt binaries will be made available shortly, but please do not
> expect them to contain all dependencies with which Emacs can be built.
> At present, I don't recommend using binaries from f-droid.org, since
> they are out of date, but I will ask the f-droid packagers to rectify
> that problem.
>
> I will post this news to comp.emacs; please post this to other forums
> frequented by Emacs users as well.

A prebuilt binary for 64-bit ARM devices running Android 5.1 or later
can be found at:

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

Note that because F-Droid chose to sign their release with their own
signing key, you will have to uninstall the F-Droid version before
installing this one.

Re: Android port

[Etienne Prud'homme]

Sorry for the late reply.

Does this port allow Emacs to access files outside app-specific
storage?  When trying the Sourceforge build, I was unable to access
files outside `/data/data/org.gnu.emacs`.  It looks to me the
application doesn't ask for any storage permissions.

Trying to use it with no a touch keyboard is not really efficient for
me (yet), but I didn't see any functions that would ask Android to
allow file system access.

I was surprised to see so many things working.  Thanks for your work.

Etienne Prud'homme

Re: Android port

[Po Lu]

"Etienne Prud'homme" <e.e.f.prudhomme@gmail.com> writes:

> Sorry for the late reply.
>
> Does this port allow Emacs to access files outside app-specific
> storage?  When trying the Sourceforge build, I was unable to access
> files outside `/data/data/org.gnu.emacs`.  It looks to me the
> application doesn't ask for any storage permissions.
>
> I was surprised to see so many things working.  Thanks for your work.
>
> Etienne Prud'homme

Emacs does not ask for any permissions by default.  You must enable
access to storage on Android 10 and earlier, and access to ``All files
and media'' on Android 11 and later.  This is described in the Android
appendix of the Emacs manual, which I suggest you read.

> Trying to use it with no a touch keyboard is not really efficient for
> me (yet), but I didn't see any functions that would ask Android to
> allow file system access.

Why is that?
The on-screen keyboard should be displayed whenever necessary.

Thanks.