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

[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

[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

[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

[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: 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

[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

[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: contributing to Emacs

[Konstantin Kharlamov]

On Sat, 2023-06-17 at 12:47 -0400, Alfred M. Szmidt wrote:
>    > > 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...

I see you have 4 patches to Emacs. If you do not mind, can I ask you: what other projects did you contribute to, to be able to compare the experience?

(I changed the email title as I feel this is kind of offtopic regarding Android)

Re: contributing to Emacs

[Alfred M. Szmidt]

   (I changed the email title as I feel this is kind of offtopic regarding Android)

My "qualifications" are also off-topic for emacs-devel, it is you who
needs to answer what "notoriously hard" means.  Clearly, people do not
find it as hard as you claim to.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sat, 2023-06-17 at 14:36 -0400, Alfred M. Szmidt wrote:
>    (I changed the email title as I feel this is kind of offtopic regarding
> Android)
>
> My "qualifications" are also off-topic for emacs-devel, it is you who
> needs to answer what "notoriously hard" means.  Clearly, people do not
> find it as hard as you claim to.

Okay, well. You see, in 90% of open source projects contributions work like this: you
create a branch, you add commits, you `git push` — and then if your changes weren't
registered yet for review, you'll get a link in your terminal to immediately
send them for review. Otherwise you don't do anything at all, it is already in
review, and simple push makes it available to maintainers to see.

A few projects have special requirements, like "have a Signed-off-by" line. In such
case in a few minutes you'll get an email saying your commits didn't pass CI, so you
look at it, you fix it.

Such simplicity makes contribution a complete no-brainer. I can't count how many
times I was stumbling upon something easily fixable in a project I don't even use,
(in such cases it's mostly docs improvements) and in five minutes I had changes
applied and sent for review.

This "90%" you can count as the chance that if a new developer comes, they would
expect it to be that simple. Which isn't the case for Emacs. If contributing to most
open sources projects only requires finding out their upstream URL, in Emacs case you
also need to go read HUGE "Sending patches" section. And then if that's not enough,
from what I've seen maintainers also expect you to have read CONTRIBUTE section,
which is absolutely large, much bigger than "Sending patches". (to be fair, if you
are a new contributor, you won't know it exists because "Sending patches" has no
mention of it).

This alone may eliminate a number of contributors who has no experience with
contributing via mailing lists (I think a lot of devs has no such experience, because
offhand the only widely popular projects that still use MLs are the kernel, glibc,
gcc and Emacs), and who wouldn't like to have to spend too much time figuring it out.

But some devs know how contributing via ML works. They will probably send their
patchset to bug-gnu-emacs, and… they will find out that debbugs for some reason
created a dozen bugreports for each individual patch 😄 Amazing.

But let's set aside the "newness" problem, let's imagine a developer who already has
experience, know all these problems and obstacles. Like me. Even in this case
contributing is inconvenient, because you can't "just push new revision" and be done,
you need to also send it to some URL. And then some maintainers have differing
requirements: typically in ML-managed project you just do `git send-email`, but I've
also been asked once by someone to attach patches instead, which makes situation even
more complicated. You see: these are complete no-brainer in 90% of projects. But
every time I contribute here I have to think about such stuff which is completely
irrelevant to the changes being sent.

And how do you even get a link where to send new patch revision? I have two dozens
email notifications coming to my email everyday. So I will have to search through all
that stuff.

And then, debbugs has no syntax highlight whatsoever and does not show the latest
patch revision. So studying the patch quickly in the interface is inconvenient at
best, you'd rather open it locally in Emacs (if you have the patch locally).

How do maintainers review code being sent I don't even know. I am a co-maintainer of
`color-identifiers-mode`, and we have set up CI and tests, so I immediately know a
contribution at least passes tests. But in absence of CI I guess you have to manually
check that the patch someone sent at least compiles…?

So, yes, contributing to Emacs is hard.

Re: contributing to Emacs

[Alfred M. Szmidt]

   So, yes, contributing to Emacs is hard.

You might not _prefer_ the way it is done, but it is not hard as you
purport it to be.  The chapter "Sending patches" is eight relativley
simple bullets, the CONTRIBUTING is also not a very hard document to
follow.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sat, 2023-06-17 at 17:00 -0400, Alfred M. Szmidt wrote:
>    So, yes, contributing to Emacs is hard.
> 
> You might not _prefer_ the way it is done, but it is not hard as you
> purport it to be.  The chapter "Sending patches" is eight relativley
> simple bullets, the CONTRIBUTING is also not a very hard document to
> follow.

Well. You clearly don't want to get into discussion, because ignored most of my
points, and then you saying it's "8 relatively simple bullets" is misleading at
best. There's a lot of text, especially to someone new, especially when in other
projects you usually don't need to read anything at all. There's always CI if
something goes wrong with your contribution.

That's fine, let's not discuss it then.

Re: contributing to Emacs

[Alfred M. Szmidt]

   That's fine, let's not discuss it then.

You've not explained what is hard, you raised multiple preferences,
but not _why_.  Sending an email to emacs-devel@ with a patch, even
without following those eight bullets is not hard -- people seem to be
doing it all the time.

Your responsibility as a contributor ends as soon as you fixed
whatever issues are raised by the maintainters, and they commit the
patch.  There is no need to look at some CI machinery to know if you
screwed up -- it sorta isn't your problem.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sat, 2023-06-17 at 17:19 -0400, Alfred M. Szmidt wrote:
>    That's fine, let's not discuss it then.
> 
> You've not explained what is hard, you raised multiple preferences,
> but not _why_.  Sending an email to emacs-devel@ with a patch, even
> without following those eight bullets is not hard -- people seem to be
> doing it all the time.

Well, I don't know how, but you managed to completely miss my point. First of
all, this isn't a "preference", I enlisted actions that you *don't* do with
other projects, actions that create mental load. And then I also mentioned that
basically 90% of devs would expect such things to just work.

The reason I asked you if you ever contributed to other projects is because the
only reason you'd ask me what's the problem with development workflow here is if
you just have no other experience.

> Your responsibility as a contributor ends as soon as you fixed
> whatever issues are raised by the maintainters, and they commit the
> patch.  There is no need to look at some CI machinery to know if you
> screwed up -- it sorta isn't your problem.

Well… You are right. But then how do you expect a contributor to become a
maintainer when they see problems? 🤷‍♂️

Re: contributing to Emacs

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

   >    That's fine, let's not discuss it then.
   > 
   > You've not explained what is hard, you raised multiple preferences,
   > but not _why_.  Sending an email to emacs-devel@ with a patch, even
   > without following those eight bullets is not hard -- people seem to be
   > doing it all the time.

   Well, I don't know how, but you managed to completely miss my
   point. First of all, this isn't a "preference", I enlisted actions
   that you *don't* do with other projects, actions that create mental
   load. And then I also mentioned that basically 90% of devs would
   expect such things to just work.

Because you are over exaggerating the hurdle to contribute to Emacs.
You claimed that you "_need_ to go read HUGE 'Sending patches
section".  It is literally: send feature suggestions (patch or not!)
to emacs-devel@, and bugs to bug-gnu-emacs@ -- that is it.

If you plan on contributing a lot, it is quite courteous to read a few
documents like the Contributing section (or how about, Emacs Lisp
Coding Conventions?) which is not "absolutely large", it is respectful
to all to know what is expceted.  

Your message was quite far larger than both documents together
... consider that for a second.  

   The reason I asked you if you ever contributed to other projects is
   because the only reason you'd ask me what's the problem with
   development workflow here is if you just have no other experience.

Yes, plenty projects over the course of 30 years.  And the process you
outlined ("PR's") is probobly the worst -- in my experience -- you
might prefer it though.  Often leading to quite bad quality since it
is so easy to just accept anything that goes through "the test"
without any regard for what it does and how it does it.

But I wouldn't call the "PR process" hard, but it does cause a barrier
(IMHO...) for people, since they need to go through many more steps
(creating a login, an issue, branch, pr, ...) instead of just editing
a file, running C-x v = and sending the result to a list.

   > Your responsibility as a contributor ends as soon as you fixed
   > whatever issues are raised by the maintainters, and they commit
   > the patch.  There is no need to look at some CI machinery to know
   > if you screwed up -- it sorta isn't your problem.

   Well… You are right. But then how do you expect a contributor to
   become a maintainer when they see problems? 🤷‍♂️

It is unrealistic to _expect_ contributors to become maintainers.
Becoming a maintainer, specially for something complicated and large
like GNU Emacs should be hard, because it is a hard and complicated
job.

Emacs has a high bar when it comes to _standards_, and _quality_ --
but contributing is trivial.  And all the praise to the Emacs
maintainers for keeping things to high standards.

Re: contributing to Emacs

[Konstantin Kharlamov]

Okay, as mentioned elsewhere in thread, I think the problem is known and further
discussion here ain't productive. So I'm going to stop here. But to answer
something quickly verifiable:

On Sat, 2023-06-17 at 18:25 -0400, Alfred M. Szmidt wrote:
> Your message was quite far larger than both documents together
> ... consider that for a second.  

No. I measured specifically for you: "Sending Patches" alone is 5884 characters
not counting bullets, and my email was 3491 characters.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 01:39:17 +0300
> 
> No. I measured specifically for you: "Sending Patches" alone is 5884 characters
> not counting bullets, and my email was 3491 characters.

When someone posts a patch, he or she is not requested to read that
section, let alone pass some kind of exam on being familiar with it.
I'm quite sure 99% of contributors don't even know that section exists
in the manual, and have never read it.  So the size of that node is
utterly irrelevant to how hard it is to contribute to Emacs.

If you are keen on studying how this is done and whether and how it
can be improved (as opposed to reiterating that "Cartage shall be
destroyed"), I invite you to read the typical discussions of such
submissions on our issue tracker.  There, you will see what we
_really_ require from the contributors and how the process goes.
Here's one recent example:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64126

Here's another:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64045

And one more:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63913

Yes, many other projects do it differently.  By and large, they are
toy projects whose median life time is about 1/10th that of Emacs, and
the size is accordingly small.  These quantitative differences call
for qualitatively different procedures.  Look at other large projects,
like GCC and GDB, and you will see very similar procedures.  As a
matter of fact, GDB even tried several times to move to PR-like
patch-review workflow based on several available frameworks, and each
time went back, concluding that those frameworks are lacking some
important features.  So the issue is not as clear-cut and simple as
you seem to present it, and the Emacs maintainers perhaps know what
they are doing when they stick to what we have, and not just out of
obstinance.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 01:39:17 +0300
> > 
> > No. I measured specifically for you: "Sending Patches" alone is 5884
> > characters
> > not counting bullets, and my email was 3491 characters.
> 
> When someone posts a patch, he or she is not requested to read that
> section, let alone pass some kind of exam on being familiar with it.
> I'm quite sure 99% of contributors don't even know that section exists
> in the manual, and have never read it.  So the size of that node is
> utterly irrelevant to how hard it is to contribute to Emacs.

You can't send a patch if you don't know how and where to send it 😊 So you
can't avoid reading that section.

> If you are keen on studying how this is done and whether and how it
> can be improved (as opposed to reiterating that "Cartage shall be
> destroyed"), I invite you to read the typical discussions of such
> submissions on our issue tracker.  There, you will see what we
> _really_ require from the contributors and how the process goes.
> Here's one recent example:
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64126
> 
> Here's another:
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64045
> 
> And one more:
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63913

I looked through these links but I'm not sure what they supposed to show me.
I've been contributing patches from time to time and back when I had my first
ones I've been multiple times pointed to CONTRIBUTE file due to getting either
formatting or something else wrong. Which is why I'm saying there's an
expectation to read that file as well.

> Yes, many other projects do it differently.  By and large, they are
> toy projects whose median life time is about 1/10th that of Emacs, and
> the size is accordingly small.  

Mesa isn't small. Neither is systemd, docker, podman. These are very active
projects and they are in very active use today. If you go up the stack: Gnome,
KDE, they also are big active projects in use, and they use workflow similar to
Mesa and systemd. There's also WINE as another example.

> These quantitative differences call
> for qualitatively different procedures.  Look at other large projects,
> like GCC and GDB, and you will see very similar procedures.  As a
> matter of fact, GDB even tried several times to move to PR-like
> patch-review workflow based on several available frameworks, and each
> time went back, concluding that those frameworks are lacking some
> important features. 

I didn't know. Do you have a link at hand? I'd be curious to read what was the
problem. Apparently there wasn't an article on Phoronix about it, kind of sad.

>  So the issue is not as clear-cut and simple as
> you seem to present it, and the Emacs maintainers perhaps know what
> they are doing when they stick to what we have, and not just out of
> obstinance.

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> You can't send a patch if you don't know how and where to send it 😊
> So you can't avoid reading that section.

I cannot help but wonder how a person who is unable to read several
short paragraphs of text would have learned the programming languages in
which Emacs is written.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 17:01 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > You can't send a patch if you don't know how and where to send it 😊
> > So you can't avoid reading that section.
> 
> I cannot help but wonder how a person who is unable to read several
> short paragraphs of text would have learned the programming languages in
> which Emacs is written.

The point is not (in)ability to read. The point is the additional mental load
from the many additional actions that are needed to contribute.

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> The point is not (in)ability to read. The point is the additional
> mental load from the many additional actions that are needed to
> contribute.

That effort is minimal, compared to the effort it takes to write the
code.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 17:25 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > The point is not (in)ability to read. The point is the additional
> > mental load from the many additional actions that are needed to
> > contribute.
> 
> That effort is minimal, compared to the effort it takes to write the
> code.

These two are uncomparable. The "effort to write the code" is something people
often feel joy in doing. Whereas effort related to pushing your changes upstream
is just something necessary. You need to go through it, but it's usually not
something people enjoy doing.

And to make sure we're on the same page: note that I do not say "sending
patches" section alone is problematic (also below there's a discussion on
possible improvement to it), my point is there lots of such "unnecessary stuff",
which accumulates.

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> And to make sure we're on the same page: note that I do not say
> "sending patches" section alone is problematic (also below there's a
> discussion on possible improvement to it), my point is there lots of
> such "unnecessary stuff", which accumulates.

And that includes?

I'm sorry, but I haven't had the time to read through this discussion,
which also happens to be a tangent wrt the original topic of the thread.
Please forgive me if you have to repeat yourself.

Thanks.

Re: contributing to Emacs

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

   > > You can't send a patch if you don't know how and where to send it 😊
   > > So you can't avoid reading that section.
   > 
   > I cannot help but wonder how a person who is unable to read several
   > short paragraphs of text would have learned the programming languages in
   > which Emacs is written.

   The point is not (in)ability to read. The point is the additional mental load
   from the many additional actions that are needed to contribute.

What about the mental load of the maintainers?  Those chapers exist
for a reason, to make life easier for both contributors and
maintainers so that there is a well documented, agreed upon, standard
to follow.

And you're not even required to read them, the only action you have is
to send a patch -- if even that, since there are plenty of times when
someone sends a suggestion and the maintainers or someone else
implement the feature!  There are literally no additional actions.

Emacs is a luxurious project in that regard, and the little nod once
in a while to read one or two chapters is the least we can do to thank
those that do the daily work.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: ams@gnu.org, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 11:53:09 +0300
> 
> On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
> > 
> > When someone posts a patch, he or she is not requested to read that
> > section, let alone pass some kind of exam on being familiar with it.
> > I'm quite sure 99% of contributors don't even know that section exists
> > in the manual, and have never read it.  So the size of that node is
> > utterly irrelevant to how hard it is to contribute to Emacs.
> 
> You can't send a patch if you don't know how and where to send it 😊 So you
> can't avoid reading that section.

False.  People know how to reach us even without reading.  The few
Emacs mailing lists are common knowledge, and are just an Internet
search away if someone needs that.

> > If you are keen on studying how this is done and whether and how it
> > can be improved (as opposed to reiterating that "Cartage shall be
> > destroyed"), I invite you to read the typical discussions of such
> > submissions on our issue tracker.  There, you will see what we
> > _really_ require from the contributors and how the process goes.
> > Here's one recent example:
> > 
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64126
> > 
> > Here's another:
> > 
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64045
> > 
> > And one more:
> > 
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63913
> 
> I looked through these links but I'm not sure what they supposed to show me.

How patch submitting process works in reality.

> I've been contributing patches from time to time and back when I had my first
> ones I've been multiple times pointed to CONTRIBUTE file due to getting either
> formatting or something else wrong. Which is why I'm saying there's an
> expectation to read that file as well.

There's no such expectation.  We live in the real world, not in some
fantasy.  When the patch doesn't follow our conventions, we either
correct that by hand when installing it or (if the deviations are too
significant) ask the contributor to make those changes and resubmit.

> > Yes, many other projects do it differently.  By and large, they are
> > toy projects whose median life time is about 1/10th that of Emacs, and
> > the size is accordingly small.  
> 
> Mesa isn't small. Neither is systemd, docker, podman.

I said "by and large".

> > These quantitative differences call
> > for qualitatively different procedures.  Look at other large projects,
> > like GCC and GDB, and you will see very similar procedures.  As a
> > matter of fact, GDB even tried several times to move to PR-like
> > patch-review workflow based on several available frameworks, and each
> > time went back, concluding that those frameworks are lacking some
> > important features. 
> 
> I didn't know. Do you have a link at hand? I'd be curious to read what was the
> problem. Apparently there wasn't an article on Phoronix about it, kind of sad.

I don't have a link, you will have to search the archives of the GDB
list.

Re: contributing to Emacs

[Eli Zaretskii]

> Date: Sun, 18 Jun 2023 12:01:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ams@gnu.org, emacs-devel@gnu.org
> 
> > You can't send a patch if you don't know how and where to send it 😊 So you
> > can't avoid reading that section.
> 
> False.  People know how to reach us even without reading.  The few
> Emacs mailing lists are common knowledge, and are just an Internet
> search away if someone needs that.

To say nothing of the fact that "Send Bug Report" is right there on
the Help menu.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 12:06 +0300, Eli Zaretskii wrote:
> > Date: Sun, 18 Jun 2023 12:01:41 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: ams@gnu.org, emacs-devel@gnu.org
> > 
> > > You can't send a patch if you don't know how and where to send it 😊 So
> > > you
> > > can't avoid reading that section.
> > 
> > False.  People know how to reach us even without reading.  The few
> > Emacs mailing lists are common knowledge, and are just an Internet
> > search away if someone needs that.
> 
> To say nothing of the fact that "Send Bug Report" is right there on
> the Help menu.

It's not really relevant. Emacs is the unique project that tracks patches in the
bugtracker, so if you don't know yet that bugtracker is used to send a patch,
the only reason you'd use it if you didn't manage to find "sending patches"
section and decided to report a bug about the lack of docs (which would be of
course invalid, but that's not the point).

Re: contributing to Emacs

[Michael Albinus]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

Hi Konstantin,

>> To say nothing of the fact that "Send Bug Report" is right there on
>> the Help menu.
>
> It's not really relevant. Emacs is the unique project that tracks patches in the
> bugtracker,

No. At least Guix does it also, FTR.

Best regards, Michael.

RE: [External] : Re: contributing to Emacs

[Drew Adams]

> Emacs is the unique project that tracks patches
> in the bugtracker, so if you don't know yet that
> bugtracker is used to send a patch,...

(I don't have anything to say about the main point
being discussed in this thread.)

Wrt `M-x report-emacs-bug': We've discussed in the
past the fact that this is also the way to send an
enhancement request, and that that might not be
obvious from the menu item and command name, or even
from the doc string.

I don't think we ever came up with a "solution" that
might make clear that this command is a general way
to provide feedback to help improve Emacs.

I don't have a great suggestion for that, but I do
think it would be good if we came up with something.

"Send Feedback (suggestion, bug, patch...)"?

Someone seeing the menu item won't necessarily check
the doc string.  But still, the doc string could
maybe point out that you can use the command to send
other feedback, and not just report something that
you're convinced is a bug.

Re: [External] : Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 13:29 +0000, Drew Adams wrote:
> > Emacs is the unique project that tracks patches
> > in the bugtracker, so if you don't know yet that
> > bugtracker is used to send a patch,...
> 
> (I don't have anything to say about the main point
> being discussed in this thread.)
> 
> Wrt `M-x report-emacs-bug': We've discussed in the
> past the fact that this is also the way to send an
> enhancement request, and that that might not be
> obvious from the menu item and command name, or even
> from the doc string.
> 
> I don't think we ever came up with a "solution" that
> might make clear that this command is a general way
> to provide feedback to help improve Emacs.
> 
> I don't have a great suggestion for that, but I do
> think it would be good if we came up with something.
> 
> "Send Feedback (suggestion, bug, patch...)"?
> 
> Someone seeing the menu item won't necessarily check
> the doc string.  But still, the doc string could
> maybe point out that you can use the command to send
> other feedback, and not just report something that
> you're convinced is a bug.

Sorry, just notice your email.

I think it's better to add a separate function, sort of `M-x send-patch-to-emacs`. Because `report-emacs-bug` has a lot of information unrelated to sending a patch; and then I think I may be useful to add some other information that is specific to sending a patch but useless to sending a bug report.

Re: [External] : Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: "ams@gnu.org" <ams@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 19 Jun 2023 01:46:53 +0300
> 
> I think it's better to add a separate function, sort of `M-x
> send-patch-to-emacs`.

It already exists: submit-emacs-patch.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 12:01 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: ams@gnu.org, emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 11:53:09 +0300
> > 
> > On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
> > > 
> > > When someone posts a patch, he or she is not requested to read that
> > > section, let alone pass some kind of exam on being familiar with it.
> > > I'm quite sure 99% of contributors don't even know that section exists
> > > in the manual, and have never read it.  So the size of that node is
> > > utterly irrelevant to how hard it is to contribute to Emacs.
> > 
> > You can't send a patch if you don't know how and where to send it 😊 So you
> > can't avoid reading that section.
> 
> False.  People know how to reach us even without reading.  The few
> Emacs mailing lists are common knowledge, and are just an Internet
> search away if someone needs that.

Okay, let's conduct an experiment. Suppose I am a new contributor who never
contributed via MLs. So first I search for "Emacs contribute". I get this URL
https://www.gnu.org/software/emacs/manual/html_node/emacs/Contributing.html
There I see a suggestion to implement a new feature and submit a patch. So then
I use page search for word "patch" to see where are details on how to do that. I
find a link "Sending Patches". There I find a suggestion to send it to
bugtracker, and then various points about MIME types, what needs to be done,
etc.

In what case do you imagine such new developer would not need to read that
section and still will successfully send a patch? 🤷‍♂️

> > > If you are keen on studying how this is done and whether and how it
> > > can be improved (as opposed to reiterating that "Cartage shall be
> > > destroyed"), I invite you to read the typical discussions of such
> > > submissions on our issue tracker.  There, you will see what we
> > > _really_ require from the contributors and how the process goes.
> > > Here's one recent example:
> > > 
> > >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64126
> > > 
> > > Here's another:
> > > 
> > >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64045
> > > 
> > > And one more:
> > > 
> > >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63913
> > 
> > I looked through these links but I'm not sure what they supposed to show me.
> 
> How patch submitting process works in reality.

I know how it works, I've been contributing to Emacs. Which is why I'm not sure
what was I supposed to see there. I looked at the links and it seems to be
pretty usual.

> > I've been contributing patches from time to time and back when I had my
> > first
> > ones I've been multiple times pointed to CONTRIBUTE file due to getting
> > either
> > formatting or something else wrong. Which is why I'm saying there's an
> > expectation to read that file as well.
> 
> There's no such expectation.  We live in the real world, not in some
> fantasy.  When the patch doesn't follow our conventions, we either
> correct that by hand when installing it or (if the deviations are too
> significant) ask the contributor to make those changes and resubmit.

Okay, maybe something changed. I am saying from my experience of contributing
patches.

> > > Yes, many other projects do it differently.  By and large, they are
> > > toy projects whose median life time is about 1/10th that of Emacs, and
> > > the size is accordingly small.  
> > 
> > Mesa isn't small. Neither is systemd, docker, podman.
> 
> I said "by and large".

Well, in this case I might be missing what you meant to say. You pointed out
there are small projects with different workflow, I pointed out there are large
ones. So I guess that cancels out. If that was meant to present some point to
me, I'm not seeing it.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: ams@gnu.org, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 12:18:09 +0300
> 
> > > You can't send a patch if you don't know how and where to send it 😊 So you
> > > can't avoid reading that section.
> > 
> > False.  People know how to reach us even without reading.  The few
> > Emacs mailing lists are common knowledge, and are just an Internet
> > search away if someone needs that.
> 
> Okay, let's conduct an experiment. Suppose I am a new contributor who never
> contributed via MLs. So first I search for "Emacs contribute". I get this URL
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Contributing.html
> There I see a suggestion to implement a new feature and submit a patch. So then
> I use page search for word "patch" to see where are details on how to do that. I
> find a link "Sending Patches". There I find a suggestion to send it to
> bugtracker, and then various points about MIME types, what needs to be done,
> etc.
> 
> In what case do you imagine such new developer would not need to read that
> section and still will successfully send a patch? 🤷‍♂️

All of them.  I never had anyone asking where to send a patch.  People
sometimes say they are not sure whether they send them to a correct
forum, but they do send them to the right place nonetheless.

> > > I've been contributing patches from time to time and back when I had my
> > > first
> > > ones I've been multiple times pointed to CONTRIBUTE file due to getting
> > > either
> > > formatting or something else wrong. Which is why I'm saying there's an
> > > expectation to read that file as well.
> > 
> > There's no such expectation.  We live in the real world, not in some
> > fantasy.  When the patch doesn't follow our conventions, we either
> > correct that by hand when installing it or (if the deviations are too
> > significant) ask the contributor to make those changes and resubmit.
> 
> Okay, maybe something changed. I am saying from my experience of contributing
> patches.

AFAIR, you insisted to know, for each comment during the patch review,
where is that requirement documented.  So you were pointed to those
places.  You could have simply done what you were asked, in which case
you wouldn't need to read on that.

> > > > Yes, many other projects do it differently.  By and large, they are
> > > > toy projects whose median life time is about 1/10th that of Emacs, and
> > > > the size is accordingly small.  
> > > 
> > > Mesa isn't small. Neither is systemd, docker, podman.
> > 
> > I said "by and large".
> 
> Well, in this case I might be missing what you meant to say. You pointed out
> there are small projects with different workflow, I pointed out there are large
> ones.

Your large ones are still smaller than Emacs by a factor of 3.  You
also forgot the point about the age of each project.

> So I guess that cancels out.

It doesn't.  Your argument was about 90% of projects, and my response
about most of them being small was about that majority.  Showing a few
examples that are in the same order of magnitude as Emacs doesn't
substantiate your claim, which basically is: it's easy and obvious
that Emacs should switch, but a few old-timers block that for
laughable reasons.

Re: contributing to Emacs

[Dmitry Gutov]

On 18/06/2023 12:35, Eli Zaretskii wrote:
>> From: Konstantin Kharlamov<hi-angel@yandex.ru>
>> Cc:ams@gnu.org,emacs-devel@gnu.org
>> Date: Sun, 18 Jun 2023 12:18:09 +0300
>>
>>>> You can't send a patch if you don't know how and where to send it 😊 So you
>>>> can't avoid reading that section.
>>> False.  People know how to reach us even without reading.  The few
>>> Emacs mailing lists are common knowledge, and are just an Internet
>>> search away if someone needs that.
>> Okay, let's conduct an experiment. Suppose I am a new contributor who never
>> contributed via MLs. So first I search for "Emacs contribute". I get this URL
>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Contributing.html
>> There I see a suggestion to implement a new feature and submit a patch. So then
>> I use page search for word "patch" to see where are details on how to do that. I
>> find a link "Sending Patches". There I find a suggestion to send it to
>> bugtracker, and then various points about MIME types, what needs to be done,
>> etc.
>>
>> In what case do you imagine such new developer would not need to read that
>> section and still will successfully send a patch? 🤷‍♂️
> All of them.  I never had anyone asking where to send a patch.  People
> sometimes say they are not sure whether they send them to a correct
> forum, but they do send them to the right place nonetheless.

You don't see people asking where to send the patch because they simply 
stop at that point. Or they spend some time searching the web and trying.

Most people who know where to send the question, will probably have 
found the bug tracker as well by that point.

https://en.wikipedia.org/wiki/Survivorship_bias#/media/File:Survivorship-bias.svg

Re: contributing to Emacs

[Philip Kaludercic]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
>> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> > Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com, emacs-devel@gnu.org
>> > Date: Sun, 18 Jun 2023 01:39:17 +0300
>> > 
>> > No. I measured specifically for you: "Sending Patches" alone is 5884
>> > characters
>> > not counting bullets, and my email was 3491 characters.
>> 
>> When someone posts a patch, he or she is not requested to read that
>> section, let alone pass some kind of exam on being familiar with it.
>> I'm quite sure 99% of contributors don't even know that section exists
>> in the manual, and have never read it.  So the size of that node is
>> utterly irrelevant to how hard it is to contribute to Emacs.
>
> You can't send a patch if you don't know how and where to send it 😊 So you
> can't avoid reading that section.

I think `submit-emacs-patch' is supposed to help here.  But I don't get
how this is a Emacs/ML specific issue?

-- 
Philip Kaludercic

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 10:00 +0000, Philip Kaludercic wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
> > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > > Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com,
> > > > emacs-devel@gnu.org
> > > > Date: Sun, 18 Jun 2023 01:39:17 +0300
> > > > 
> > > > No. I measured specifically for you: "Sending Patches" alone is 5884
> > > > characters
> > > > not counting bullets, and my email was 3491 characters.
> > > 
> > > When someone posts a patch, he or she is not requested to read that
> > > section, let alone pass some kind of exam on being familiar with it.
> > > I'm quite sure 99% of contributors don't even know that section exists
> > > in the manual, and have never read it.  So the size of that node is
> > > utterly irrelevant to how hard it is to contribute to Emacs.
> > 
> > You can't send a patch if you don't know how and where to send it 😊 So you
> > can't avoid reading that section.
> 
> I think `submit-emacs-patch' is supposed to help here. 

You would need to know it exists.

>  But I don't get how this is a Emacs/ML specific issue?

We are discussing possible improvement to Emacs-specific contributing workflow.

Re: contributing to Emacs

[Philip Kaludercic]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Sun, 2023-06-18 at 10:00 +0000, Philip Kaludercic wrote:
>> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>> 
>> > On Sun, 2023-06-18 at 08:20 +0300, Eli Zaretskii wrote:
>> > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> > > > Cc: eliz@gnu.org, arne_bab@web.de, luangruo@yahoo.com,
>> > > > emacs-devel@gnu.org
>> > > > Date: Sun, 18 Jun 2023 01:39:17 +0300
>> > > > 
>> > > > No. I measured specifically for you: "Sending Patches" alone is 5884
>> > > > characters
>> > > > not counting bullets, and my email was 3491 characters.
>> > > 
>> > > When someone posts a patch, he or she is not requested to read that
>> > > section, let alone pass some kind of exam on being familiar with it.
>> > > I'm quite sure 99% of contributors don't even know that section exists
>> > > in the manual, and have never read it.  So the size of that node is
>> > > utterly irrelevant to how hard it is to contribute to Emacs.
>> > 
>> > You can't send a patch if you don't know how and where to send it 😊 So you
>> > can't avoid reading that section.
>> 
>> I think `submit-emacs-patch' is supposed to help here. 
>
> You would need to know it exists.

True, but that can be fixed.

>>  But I don't get how this is a Emacs/ML specific issue?
>
> We are discussing possible improvement to Emacs-specific contributing workflow.

My point is that this is an issue that all projects have in some sense
or another.  You always have to find out how they work, and what you
need to do to submit a patch.

One idea (but I don't know if this is practicable), is to use the
configure script to set up Git's `sendemail.to' option or to add
`vc-default-patch-addressee' to .dir-locals.el.

-- 
Philip Kaludercic

Re: contributing to Emacs

[Sean Whitton]

Hello,

On Sun 18 Jun 2023 at 10:22AM GMT, Philip Kaludercic wrote:

> One idea (but I don't know if this is practicable), is to use the
> configure script to set up Git's `sendemail.to' option or to add
> `vc-default-patch-addressee' to .dir-locals.el.

I thought we were going to do that anyway, just as soon as enough time
had passed that people are not going to get unsafe local variable
popups?

-- 
Sean Whitton

Re: contributing to Emacs

[Philip Kaludercic]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Sun 18 Jun 2023 at 10:22AM GMT, Philip Kaludercic wrote:
>
>> One idea (but I don't know if this is practicable), is to use the
>> configure script to set up Git's `sendemail.to' option or to add
>> `vc-default-patch-addressee' to .dir-locals.el.
>
> I thought we were going to do that anyway, just as soon as enough time
> had passed that people are not going to get unsafe local variable
> popups?

That was (is?) the plan, but I guess it was just delayed because people
on older versions got irritated by the unsafe variable warnings, and
then everyone forgot.

-- 
Philip Kaludercic

Re: contributing to Emacs

[Sean Whitton]

Hello,

On Sat 24 Jun 2023 at 03:37PM GMT, Philip Kaludercic wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Hello,
>>
>> On Sun 18 Jun 2023 at 10:22AM GMT, Philip Kaludercic wrote:
>>
>>> One idea (but I don't know if this is practicable), is to use the
>>> configure script to set up Git's `sendemail.to' option or to add
>>> `vc-default-patch-addressee' to .dir-locals.el.
>>
>> I thought we were going to do that anyway, just as soon as enough time
>> had passed that people are not going to get unsafe local variable
>> popups?
>
> That was (is?) the plan, but I guess it was just delayed because people
> on older versions got irritated by the unsafe variable warnings, and
> then everyone forgot.

Let's go ahead now?

-- 
Sean Whitton

Setting 'vc-default-patch-addressee' in .dir-locals.el

[Philip Kaludercic]

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

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Sat 24 Jun 2023 at 03:37PM GMT, Philip Kaludercic wrote:
>
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>>
>>> Hello,
>>>
>>> On Sun 18 Jun 2023 at 10:22AM GMT, Philip Kaludercic wrote:
>>>
>>>> One idea (but I don't know if this is practicable), is to use the
>>>> configure script to set up Git's `sendemail.to' option or to add
>>>> `vc-default-patch-addressee' to .dir-locals.el.
>>>
>>> I thought we were going to do that anyway, just as soon as enough time
>>> had passed that people are not going to get unsafe local variable
>>> popups?
>>
>> That was (is?) the plan, but I guess it was just delayed because people
>> on older versions got irritated by the unsafe variable warnings, and
>> then everyone forgot.
>
> Let's go ahead now?

Does anyone have any objections against applying


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Set-vc-default-patch-addressee-in-.dir-locals.el.patch --]
[-- Type: text/x-diff, Size: 1040 bytes --]

From 08832036be2ed3df0cc4640a74dc11a646d77e7a Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 25 Jun 2023 13:31:28 +0200
Subject: [PATCH] Set vc-default-patch-addressee in .dir-locals.el

* .dir-locals.el: Set it to "bug-gnu-emacs@gnu.org".
---
 .dir-locals.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.dir-locals.el b/.dir-locals.el
index 0bcded4b5d1..7e0fc02dd16 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -8,7 +8,8 @@
          (vc-git-annotate-switches . "-w")
          (bug-reference-url-format . "https://debbugs.gnu.org/%s")
 	 (diff-add-log-use-relative-names . t)
-         (vc-prepare-patches-separately . nil)))
+         (vc-prepare-patches-separately . nil)
+         (vc-default-patch-addressee . "bug-gnu-emacs@gnu.org")))
  (c-mode . ((c-file-style . "GNU")
             (c-noise-macro-names . ("INLINE" "NO_INLINE" "ATTRIBUTE_NO_SANITIZE_UNDEFINED"
                                     "UNINIT" "CALLBACK" "ALIGN_STACK" "ATTRIBUTE_MALLOC"
-- 
2.39.2


[-- Attachment #3: Type: text/plain, Size: 37 bytes --]


on Emacs 29?

-- 
Philip Kaludercic

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> We are discussing possible improvement to Emacs-specific contributing
> workflow.

It's hard to not be drawn into the bikeshedding, and I've failed, but
perhaps if everyone realizes what this discussion is, it will stop.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 20:13 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > We are discussing possible improvement to Emacs-specific contributing
> > workflow.
> 
> It's hard to not be drawn into the bikeshedding, and I've failed, but
> perhaps if everyone realizes what this discussion is, it will stop.

Why? There's possibility that "sending patches" will be improved as result of the discussion, isn't that good? Perhaps something else will come out of this as well, I can hope at least.

Re: contributing to Emacs

[Alfred M. Szmidt]

   > > We are discussing possible improvement to Emacs-specific contributing
   > > workflow.
   > 
   > It's hard to not be drawn into the bikeshedding, and I've failed, but
   > perhaps if everyone realizes what this discussion is, it will stop.

   Why? There's possibility that "sending patches" will be improved as
   result of the discussion, isn't that good? Perhaps something else
   will come out of this as well, I can hope at least.

The improvments suggested so far have been very superficial, and do
not change the way how one contributes to Emacs -- which was what was
the supposed hard part at the start of the discussion.

So yeah, this is mostly bikeshedding at this point ...

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


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

>    > > We are discussing possible improvement to Emacs-specific contributing
>    > > workflow.
>    > 
>    > It's hard to not be drawn into the bikeshedding, and I've failed, but
>    > perhaps if everyone realizes what this discussion is, it will stop.
>
>    Why? There's possibility that "sending patches" will be improved as
>    result of the discussion, isn't that good? Perhaps something else
>    will come out of this as well, I can hope at least.
>
> The improvments suggested so far have been very superficial, and do
> not change the way how one contributes to Emacs -- which was what was
> the supposed hard part at the start of the discussion.

In the discussion it became clear (at least to me) that the way to
contribute is not the main complication, but the discoverability of that
way and that the way seems hard when you see more than a sheet of paper
in print as instructions.

As a contributor I find "just send your patch by email" to be much
easier than any other workflow. Though that may be due to using Emacs to
send emails (via mu4e).

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: contributing to Emacs

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Konstantin Kharlamov <hi-angel@yandex.ru>, luangruo@yahoo.com,
>  philipk@posteo.net, eliz@gnu.org, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 16:57:56 +0200
> 
> In the discussion it became clear (at least to me) that the way to
> contribute is not the main complication, but the discoverability of that
> way and that the way seems hard when you see more than a sheet of paper
> in print as instructions.

You are inventing a problem where there is none.

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> Cc: Konstantin Kharlamov <hi-angel@yandex.ru>, luangruo@yahoo.com,
>>  philipk@posteo.net, eliz@gnu.org, emacs-devel@gnu.org
>> Date: Sun, 18 Jun 2023 16:57:56 +0200
>> 
>> In the discussion it became clear (at least to me) that the way to
>> contribute is not the main complication, but the discoverability of that
>> way and that the way seems hard when you see more than a sheet of paper
>> in print as instructions.
>
> You are inventing a problem where there is none.

You said that the w32 port didn’t get many additional devs. I’m trying
to find reasons — and on the website I see obvious reasons that keep
people from contributing. And the more I look into it, the more I see
how broken the new-dev-wants-to-contribute usecase of the website is.

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: contributing to Emacs

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

   >> In the discussion it became clear (at least to me) that the way to
   >> contribute is not the main complication, but the discoverability of that
   >> way and that the way seems hard when you see more than a sheet of paper
   >> in print as instructions.
   >
   > You are inventing a problem where there is none.

   You said that the w32 port didn’t get many additional devs. I’m trying
   to find reasons — and on the website I see obvious reasons that keep
   people from contributing. And the more I look into it, the more I see
   how broken the new-dev-wants-to-contribute usecase of the website is.

Someone contributing a complicated feature like w32 most surley would
have read the Emacs manual once or twice.  Or at least looked over the
source code -- maybe starting with README file.

What keeps people from contributing complicated thing is that they are
complicated.  Lets stop making a mountain of a molehill.

Re: contributing to Emacs

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: ams@gnu.org, hi-angel@yandex.ru, luangruo@yahoo.com, philipk@posteo.net,
>  emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 20:52:43 +0200
> 
> >> In the discussion it became clear (at least to me) that the way to
> >> contribute is not the main complication, but the discoverability of that
> >> way and that the way seems hard when you see more than a sheet of paper
> >> in print as instructions.
> >
> > You are inventing a problem where there is none.
> 
> You said that the w32 port didn’t get many additional devs. I’m trying
> to find reasons — and on the website I see obvious reasons that keep
> people from contributing. And the more I look into it, the more I see
> how broken the new-dev-wants-to-contribute usecase of the website is.

I understand and appreciate what you are trying to do, but those
aren't the reasons for lack of active contributors to Emacs.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 22:11 +0300, Eli Zaretskii wrote:
> > From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> > Cc: ams@gnu.org, hi-angel@yandex.ru, luangruo@yahoo.com, philipk@posteo.net,
> >  emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 20:52:43 +0200
> > 
> > > > In the discussion it became clear (at least to me) that the way to
> > > > contribute is not the main complication, but the discoverability of that
> > > > way and that the way seems hard when you see more than a sheet of paper
> > > > in print as instructions.
> > > 
> > > You are inventing a problem where there is none.
> > 
> > You said that the w32 port didn’t get many additional devs. I’m trying
> > to find reasons — and on the website I see obvious reasons that keep
> > people from contributing. And the more I look into it, the more I see
> > how broken the new-dev-wants-to-contribute usecase of the website is.
> 
> I understand and appreciate what you are trying to do, but those
> aren't the reasons for lack of active contributors to Emacs.

I think it cumulative of many factors, and fixing every small factor that comes
into play increases probability of getting a new contributor.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: ams@gnu.org, luangruo@yahoo.com, philipk@posteo.net, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 23:10:57 +0300
> 
> On Sun, 2023-06-18 at 22:11 +0300, Eli Zaretskii wrote:
> > > From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> > > Cc: ams@gnu.org, hi-angel@yandex.ru, luangruo@yahoo.com, philipk@posteo.net,
> > >  emacs-devel@gnu.org
> > > Date: Sun, 18 Jun 2023 20:52:43 +0200
> > > 
> > > > > In the discussion it became clear (at least to me) that the way to
> > > > > contribute is not the main complication, but the discoverability of that
> > > > > way and that the way seems hard when you see more than a sheet of paper
> > > > > in print as instructions.
> > > > 
> > > > You are inventing a problem where there is none.
> > > 
> > > You said that the w32 port didn’t get many additional devs. I’m trying
> > > to find reasons — and on the website I see obvious reasons that keep
> > > people from contributing. And the more I look into it, the more I see
> > > how broken the new-dev-wants-to-contribute usecase of the website is.
> > 
> > I understand and appreciate what you are trying to do, but those
> > aren't the reasons for lack of active contributors to Emacs.
> 
> I think it cumulative of many factors, and fixing every small factor that comes
> into play increases probability of getting a new contributor.

The suggested measures will not fix any such factors.

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> > > You said that the w32 port didn’t get many additional devs. I’m trying
>> > > to find reasons — and on the website I see obvious reasons that keep
>> > > people from contributing. And the more I look into it, the more I see
>> > > how broken the new-dev-wants-to-contribute usecase of the website is.
>> > 
>> > I understand and appreciate what you are trying to do, but those
>> > aren't the reasons for lack of active contributors to Emacs.
>> 
>> I think it cumulative of many factors, and fixing every small factor that comes
>> into play increases probability of getting a new contributor.
>
> The suggested measures will not fix any such factors.

I obviously disagree strongly but will not pursue this further.

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: contributing to Emacs

[David Masterson]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> 
>> On Sun, 2023-06-18 at 22:11 +0300, Eli Zaretskii wrote:
>> > > From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> > > 
>> > > > > In the discussion it became clear (at least to me) that the way to
>> > > > > contribute is not the main complication, but the discoverability of that
>> > > > > way and that the way seems hard when you see more than a sheet of paper
>> > > > > in print as instructions.
>> > > > 
>> > > > You are inventing a problem where there is none.
>> > > 
>> > > You said that the w32 port didn’t get many additional devs. I’m trying
>> > > to find reasons — and on the website I see obvious reasons that keep
>> > > people from contributing. And the more I look into it, the more I see
>> > > how broken the new-dev-wants-to-contribute usecase of the website is.
>> > 
>> > I understand and appreciate what you are trying to do, but those
>> > aren't the reasons for lack of active contributors to Emacs.
>> 
>> I think it cumulative of many factors, and fixing every small factor that comes
>> into play increases probability of getting a new contributor.
>
> The suggested measures will not fix any such factors.

Would you say that Emacs still has development practices from the
80s/90s that, given the chance and newer toolsets, you could see being
done differently and better?

It's okay to say that what Emacs has now is working well for the current
developers, but is difficult for on-boarding new developers that want to
start out simple before graduating into Emacs internals.

-- 
David Masterson

Re: contributing to Emacs

[Eli Zaretskii]

> From: David Masterson <dsmasterson@gmail.com>
> Cc: Konstantin Kharlamov <hi-angel@yandex.ru>,  arne_bab@web.de,
>   ams@gnu.org,  luangruo@yahoo.com,  philipk@posteo.net,
>   emacs-devel@gnu.org
> Date: Mon, 19 Jun 2023 11:07:07 -0700
> 
> Would you say that Emacs still has development practices from the
> 80s/90s that, given the chance and newer toolsets, you could see being
> done differently and better?

What are "development practices from the 80s/90s"?

> It's okay to say that what Emacs has now is working well for the current
> developers, but is difficult for on-boarding new developers that want to
> start out simple before graduating into Emacs internals.

Practical suggestions for changes that would make it easier are
welcome, but they must not make the lives of the current developers
significantly harder.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Mon, 2023-06-19 at 21:50 +0300, Eli Zaretskii wrote:
> > From: David Masterson <dsmasterson@gmail.com>
> > Cc: Konstantin Kharlamov <hi-angel@yandex.ru>,  arne_bab@web.de,
> >   ams@gnu.org,  luangruo@yahoo.com,  philipk@posteo.net,
> >   emacs-devel@gnu.org
> > Date: Mon, 19 Jun 2023 11:07:07 -0700
> > 
> > Would you say that Emacs still has development practices from the
> > 80s/90s that, given the chance and newer toolsets, you could see being
> > done differently and better?
> 
> What are "development practices from the 80s/90s"?

I would abstain from answering this question, because this will turn into a
completely useless flamewar.

> > It's okay to say that what Emacs has now is working well for the current
> > developers, but is difficult for on-boarding new developers that want to
> > start out simple before graduating into Emacs internals.
> 
> Practical suggestions for changes that would make it easier are
> welcome, but they must not make the lives of the current developers
> significantly harder.

For starters I would be happy if at least the section about submitting patches
was reformatted into two sections. My last email explaining that no information
will be lost in such reformat¹ was unanswered, so I don't know what is the
current state of this discussion.

1: https://lists.gnu.org/archive/html/emacs-devel/2023-06/msg00506.html

Re: contributing to Emacs

[David Masterson]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Mon, 2023-06-19 at 21:50 +0300, Eli Zaretskii wrote:
>> > From: David Masterson <dsmasterson@gmail.com>
>> > 
>> > Would you say that Emacs still has development practices from the
>> > 80s/90s that, given the chance and newer toolsets, you could see being
>> > done differently and better?
>> 
>> What are "development practices from the 80s/90s"?
>
> I would abstain from answering this question, because this will turn into a
> completely useless flamewar.

I think I understand his question and I'm not going to answer it like I
know better -- he's been much more embedded in Emacs development than me.

-- 
David Masterson

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, philipk@posteo.net, 
> 	emacs-devel@gnu.org
> Date: Tue, 20 Jun 2023 00:29:10 +0300
> 
> > Practical suggestions for changes that would make it easier are
> > welcome, but they must not make the lives of the current developers
> > significantly harder.
> 
> For starters I would be happy if at least the section about submitting patches
> was reformatted into two sections. My last email explaining that no information
> will be lost in such reformat¹ was unanswered, so I don't know what is the
> current state of this discussion.
> 
> 1: https://lists.gnu.org/archive/html/emacs-devel/2023-06/msg00506.html

I already said I didn't think this was a good idea, and explained why
I thought so.

In any case, that section hardly has any bearing on the main issue at
hand: how to make it easier for people to contribute.  I explained
that as well.

I'd appreciate if this seasonal "what's wrong with Emacs
contributions" discussion would either switch to discussing some
innovative and useful ideas for how to make it easier for
contributors, or just died if there are no such ideas yet.
Reiterating the same claims and the same arguments doesn't sound like
a good use of our time and bandwidth.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Tue, 2023-06-20 at 14:14 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, philipk@posteo.net, 
> >         emacs-devel@gnu.org
> > Date: Tue, 20 Jun 2023 00:29:10 +0300
> > 
> > > Practical suggestions for changes that would make it easier are
> > > welcome, but they must not make the lives of the current developers
> > > significantly harder.
> > 
> > For starters I would be happy if at least the section about submitting
> > patches
> > was reformatted into two sections. My last email explaining that no
> > information
> > will be lost in such reformat¹ was unanswered, so I don't know what is the
> > current state of this discussion.
> > 
> > 1: https://lists.gnu.org/archive/html/emacs-devel/2023-06/msg00506.html
> 
> I already said I didn't think this was a good idea, and explained why
> I thought so.

You said you afraid some information will be lost. I explained that it won't.
You didn't provide any counter-arguments, so I kind of hoped it is clear at this
point that it will only bring benefit. If you are referring to something I
didn't answer, please point that out, because to my knowledge I replied to
everything.

> In any case, that section hardly has any bearing on the main issue at
> hand: how to make it easier for people to contribute.  I explained
> that as well.

That is because the large issue consists of many small ones! The only single
"big move" that is theoretically possible is just move Emacs to a Gitlab
instance, which will remove necessity to care of any docs because finding a
developer who doesn't know how git-forges work is unlikely. But I *do not*
suggest doing that because I know many long-timers would not want that. So
instead I am trying to bite at different pieces that could be improved without
affecting existing workflow. This docs discussion is just one small piece.

> I'd appreciate if this seasonal "what's wrong with Emacs
> contributions" discussion would either switch to discussing some
> innovative and useful ideas for how to make it easier for
> contributors, or just died if there are no such ideas yet.
> Reiterating the same claims and the same arguments doesn't sound like
> a good use of our time and bandwidth.

To my knowledge, I didn't "reiterate same claims", but was answering your
reasoning about not wanting to change the docs, and your reasoning didn't seem
to have been recursive so far. And it is pointless to suggest new ideas if we
didn't even finish discussing old ones.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: dsmasterson@gmail.com, arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com,
>   philipk@posteo.net, emacs-devel@gnu.org
> Date: Tue, 20 Jun 2023 18:45:03 +0300
> 
> > I already said I didn't think this was a good idea, and explained why
> > I thought so.
> 
> You said you afraid some information will be lost. I explained that it won't.
> You didn't provide any counter-arguments, so I kind of hoped it is clear at this
> point that it will only bring benefit. If you are referring to something I
> didn't answer, please point that out, because to my knowledge I replied to
> everything.

If you carefully re-read what I wrote about those suggestions, you
will see that the issue is exhausted from my POV.

> > In any case, that section hardly has any bearing on the main issue at
> > hand: how to make it easier for people to contribute.  I explained
> > that as well.
> 
> That is because the large issue consists of many small ones!

You cannot solve a complex problem by explaining it.  So adding more
and more explanations will not get us closer to the goal.  Especially
since almost no one reads that, especially not the new contributors.
They instead learn it on the job, one bit at a time.  And there's
nothing wrong with that, from where I stand.

> The only single
> "big move" that is theoretically possible is just move Emacs to a Gitlab
> instance, which will remove necessity to care of any docs because finding a
> developer who doesn't know how git-forges work is unlikely. But I *do not*
> suggest doing that because I know many long-timers would not want that. So
> instead I am trying to bite at different pieces that could be improved without
> affecting existing workflow. This docs discussion is just one small piece.

We considered Gitlab, and also a couple of other alternatives.  They
all had problems that needed to be solved first, and no one stepped
forward or succeeded to do that.  You can find all this in the
archives, including our minimum requirements to any such
workflow/framework.

Re: contributing to Emacs

[Lynn Winebarger]

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

On Tue, Jun 20, 2023, 12:15 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > The only single
> > "big move" that is theoretically possible is just move Emacs to a Gitlab
> > instance, which will remove necessity to care of any docs because
> finding a
> > developer who doesn't know how git-forges work is unlikely. But I *do
> not*
> > suggest doing that because I know many long-timers would not want that.
> So
> > instead I am trying to bite at different pieces that could be improved
> without
> > affecting existing workflow. This docs discussion is just one small
> piece.
>
> We considered Gitlab, and also a couple of other alternatives.  They
> all had problems that needed to be solved first, and no one stepped
> forward or succeeded to do that.  You can find all this in the
> archives, including our minimum requirements to any such
> workflow/framework
>

Have the problems with the search interface for the mailing list archive
been fixed?  Unless you meant some other archives, that seems problematic.

Lynn

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

Re: contributing to Emacs

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Tue, 20 Jun 2023 12:32:25 -0400
> Cc: Konstantin Kharlamov <hi-angel@yandex.ru>, dsmasterson@gmail.com, arne_bab@web.de, ams@gnu.org, 
> 	Po Lu <luangruo@yahoo.com>, Philip Kaludercic <philipk@posteo.net>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Have the problems with the search interface for the mailing list archive been fixed?  Unless you meant
> some other archives, that seems problematic.

How many different and almost unrelated problems do we want to discuss
in a single thread??

No, search problems have not been solved, AFAIK, and I have no idea
what else can be done to solve them.  If you ask me, I suggest that
interested people download the archives (each month can be downloaded
as a single mbox file) and archive them locally, using some search
software, like mairix or another.

But please! don't add more topics to this discussion, which already
wasted enough time and bandwidth without any positive results.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Tue, 2023-06-20 at 19:14 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: dsmasterson@gmail.com, arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com,
> >   philipk@posteo.net, emacs-devel@gnu.org
> > Date: Tue, 20 Jun 2023 18:45:03 +0300
> > 
> > > I already said I didn't think this was a good idea, and explained why
> > > I thought so.
> > 
> > You said you afraid some information will be lost. I explained that it
> > won't.
> > You didn't provide any counter-arguments, so I kind of hoped it is clear at
> > this
> > point that it will only bring benefit. If you are referring to something I
> > didn't answer, please point that out, because to my knowledge I replied to
> > everything.
> 
> If you carefully re-read what I wrote about those suggestions, you
> will see that the issue is exhausted from my POV.

Sorry, I am not the best person to read for cues between the lines, if that's
what you meant. You explained my suggestion has a problem, I disproved that. As
far as I understand you just do not want to discuss this issue (not because it's
wrong or something, but because you just don't have the motivation). It's okay.
I think at this point I should ask if there any other person who can apply the
change to the docs who I can discuss it with, although to be honest I'm kind of
exhausted too.

Re: contributing to Emacs

[Björn Bidar]

Eli Zaretskii <eliz@gnu.org> writes:

>> The only single
>> "big move" that is theoretically possible is just move Emacs to a Gitlab
>> instance, which will remove necessity to care of any docs because finding a
>> developer who doesn't know how git-forges work is unlikely. But I *do not*
>> suggest doing that because I know many long-timers would not want that. So
>> instead I am trying to bite at different pieces that could be improved without
>> affecting existing workflow. This docs discussion is just one small piece.
>
> We considered Gitlab, and also a couple of other alternatives.  They
> all had problems that needed to be solved first, and no one stepped
> forward or succeeded to do that.  You can find all this in the
> archives, including our minimum requirements to any such
> workflow/framework.

Have you considered updating mailman to mailman3 plus hyperkitty? The
new hyperkitty interface is easier to use and works better different
screen layouts such as mobile or high dpi.

Also considering that Mailman2 uses Python 2 which is EOL.

Re: contributing to Emacs

[Po Lu]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Have you considered updating mailman to mailman3 plus hyperkitty? The
> new hyperkitty interface is easier to use and works better different
> screen layouts such as mobile or high dpi.

Please, no.  Hyperkitty is much more difficult to use, one reason being
that it seems to assume _everyone_ is using one of those new screen
layouts, and increases the size of the padding around hyperlinks
accordingly.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Björn Bidar <bjorn.bidar@thaodan.de>
> Cc: Konstantin Kharlamov <hi-angel@yandex.ru>,  dsmasterson@gmail.com,
>   arne_bab@web.de,  ams@gnu.org,  luangruo@yahoo.com,  philipk@posteo.net,
>   emacs-devel@gnu.org
> Date: Sat, 24 Jun 2023 04:44:19 +0300
> 
> Have you considered updating mailman to mailman3 plus hyperkitty? The
> new hyperkitty interface is easier to use and works better different
> screen layouts such as mobile or high dpi.
> 
> Also considering that Mailman2 uses Python 2 which is EOL.

Mailman is not maintained by us, it's infrastructure used by the
entire GNU Project.  If you want to suggest changes in that, please
post to mailman@gnu.org and savannah-hackers-public@gnu.org.

The Emacs project just uses the infrastructure provided by GNU.

Also, the bug tracker is not built on mailman, it just sends messages
to a mailing list, but that's all.

Re: contributing to Emacs

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

>> Have you considered updating mailman to mailman3 plus hyperkitty? The
>> new hyperkitty interface is easier to use and works better different
>> screen layouts such as mobile or high dpi.
>>
>> Also considering that Mailman2 uses Python 2 which is EOL.
>
> Mailman is not maintained by us, it's infrastructure used by the
> entire GNU Project.  If you want to suggest changes in that, please
> post to mailman@gnu.org and savannah-hackers-public@gnu.org.
>
> The Emacs project just uses the infrastructure provided by GNU.
>
> Also, the bug tracker is not built on mailman, it just sends messages
> to a mailing list, but that's all.

I don't know what you mean with not "built on mailman", but the bug
tracker on debbugs.gnu.org uses mailman for moderation. However, it is
not the mailman instance of the GNU project, but an own one.

JFTR, although this might be tangent information to this thread.

Best regards, Michael.

Re: contributing to 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 Emacs developers are not in charge of how the FSF handles mailing
lists.  It handles all its mailing lists with the same software.

This is not a useful place to have a discussion about that,
but I don't know what list might be a good place for it.  Sorry.
-- 
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: contributing to Emacs

[Corwin Brust]

On Sat, Jun 24, 2023 at 9:25 PM Richard Stallman <rms@gnu.org> wrote:
>
> This is not a useful place to have a discussion about that,
> but I don't know what list might be a good place for it.  Sorry.

Speaking from a savannah standpoint, there is no (public) mailing list
for FSF/GNU infrastructure discussion, at the moment.

Please write to mailman@gnu.org as the official place to contact
mailman admins.  This will also reach the GNU vols and FSF sys admins
who need to be kept in the loop as changes are made.

Re: contributing to Emacs

[Björn Bidar]

Corwin Brust <corwin@bru.st> writes:

R> On Sat, Jun 24, 2023 at 9:25 PM Richard Stallman <rms@gnu.org> wrote:
>>
>> This is not a useful place to have a discussion about that,
>> but I don't know what list might be a good place for it.  Sorry.
>
> Speaking from a savannah standpoint, there is no (public) mailing list
> for FSF/GNU infrastructure discussion, at the moment.
>
> Please write to mailman@gnu.org as the official place to contact
> mailman admins.  This will also reach the GNU vols and FSF sys admins
> who need to be kept in the loop as changes are made.

Ok I will summarize my point to them and cc the list.

In this thread we got sidetracked and talked about improving the
accessibility of contributing to Emacs (and thous all Gnu projects in
this case).

Gnu still uses Mailman2 which uses Python2 which is EOL.

Is there a plan to upgrade to Mailman3? Doing so and also enabling
Hyperkitty could help the accessibility because of a more modern ui that
helps people on different screen resolutions and less familiarity of
using email.


Br,

Björn Bidar

Re: contributing to Emacs

[Ian Kelling]

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Corwin Brust <corwin@bru.st> writes:
>
> R> On Sat, Jun 24, 2023 at 9:25 PM Richard Stallman <rms@gnu.org> wrote:
>>>
>>> This is not a useful place to have a discussion about that,
>>> but I don't know what list might be a good place for it.  Sorry.
>>
>> Speaking from a savannah standpoint, there is no (public) mailing list
>> for FSF/GNU infrastructure discussion, at the moment.
>>
>> Please write to mailman@gnu.org as the official place to contact
>> mailman admins.  This will also reach the GNU vols and FSF sys admins
>> who need to be kept in the loop as changes are made.
>
> Ok I will summarize my point to them and cc the list.
>
> In this thread we got sidetracked and talked about improving the
> accessibility of contributing to Emacs (and thous all Gnu projects in
> this case).
>
> Gnu still uses Mailman2 which uses Python2 which is EOL.
>
> Is there a plan to upgrade to Mailman3? Doing so and also enabling
> Hyperkitty could help the accessibility because of a more modern ui that
> helps people on different screen resolutions and less familiarity of
> using email.

Yes, we, the FSF tech team, plan to upgrade to Mialman 3 this year. And
also deploy https://public-inbox.org/README.html. We are open to
volunteer help.  https://www.fsf.org/volunteer links to
https://libreplanet.org/wiki/Group:FSF:Tech_Team_Volunteers

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

Re: contributing to Emacs

[Yuchen Pei]

On Mon 2023-06-26 02:31:12 +0300, Björn Bidar wrote:

> Is there a plan to upgrade to Mailman3? Doing so and also enabling
> Hyperkitty could help the accessibility because of a more modern ui that
> helps people on different screen resolutions and less familiarity of
> using email.

Can you elaborate on the accessibility issue, especially how is the
mailman 2 archive web interface not as accessible?

One problem with Hyperkitty is that it requires javascript to display
any message, which is makes it kind of useless in non-js browsers like
eww and lynx.

Best,
Yuchen

-- 
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
          <https://ypei.org/assets/ypei-pubkey.txt>

Re: contributing to Emacs

[Corwin Brust]

On Tue, Jun 27, 2023 at 6:08 AM Yuchen Pei <id@ypei.org> wrote:
>
> One problem with Hyperkitty is that it requires javascript to display

Hi Everyone,

As Richard has said, there's little or no value in discussion of
general infrastructure (or even mail infra specifically) on this list.
FTR, concerns like "some of us use text browsers and/or don't want to
run any javascript at all" is something that the sysadmin teams all
understand very well about our community.

If you have thoughts or suggestions I'd encourage you to write Ian and
the other FSF and GNU vols who help with mail infra directly at
mailman@gnu.org

Thanks & regards,
Corwin

Re: contributing to Emacs

[Björn Bidar]

Just answering once here as other already mentioned this is wrong place
although it's related.

Yuchen Pei <id@ypei.org> writes:

> On Mon 2023-06-26 02:31:12 +0300, Björn Bidar wrote:
>
>> Is there a plan to upgrade to Mailman3? Doing so and also enabling
>> Hyperkitty could help the accessibility because of a more modern ui that
>> helps people on different screen resolutions and less familiarity of
>> using email.
>
> Can you elaborate on the accessibility issue, especially how is the
> mailman 2 archive web interface not as accessible?

Scaling doesn't work for high dpi displays, smaller displays or those
that use touch input such as phones.

Subjectively it is also an issue that so few content is on a page
requiring to click to the next page for each message.

> One problem with Hyperkitty is that it requires javascript to display
> any message, which is makes it kind of useless in non-js browsers like
> eww and lynx.

If I understand correctly there was some improvements on that recently:
https://gitlab.com/mailman/hyperkitty/-/merge_requests/418

Re: contributing to 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. ]]]

  > One problem with Hyperkitty is that it requires javascript to display
  > any message, which is makes it kind of useless in non-js browsers like
  > eww and lynx.

Features that require Javascript are totallky unacceptable if the JS
code is nonfree (see https://gnu.org/philosophy/javascript-trap.html)
and problematical even if the JS code is free
(see https://gnu.org/philosophy/wwworst-app-store.html).

We should avoid web features that send JS code, whenever possible.
Sending code to run immediately in the user's computer, in a way that
gives the user community no feasible opportunity to study the code and
release modified versions that people have a real option to use,
undermines the freedom of free software.


-- 
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: contributing to Emacs

[Björn Bidar]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > One problem with Hyperkitty is that it requires javascript to display
>   > any message, which is makes it kind of useless in non-js browsers like
>   > eww and lynx.
>
> Features that require Javascript are totallky unacceptable if the JS
> code is nonfree (see https://gnu.org/philosophy/javascript-trap.html)
> and problematical even if the JS code is free
> (see https://gnu.org/philosophy/wwworst-app-store.html).


Why do you assume JavaScript = nonfree? Mailman3-Hyperkitty is free
software.

> We should avoid web features that send JS code, whenever possible.
> Sending code to run immediately in the user's computer, in a way that

Besides avoiding JavaScript in modern web is impossible in 99% of the
cases besides for websites that load all of their content synchronously
on the initial load of the page.

> gives the user community no feasible opportunity to study the code and
> release modified versions that people have a real option to use,
> undermines the freedom of free software.

You can't modify code of content that is loaded of from other computers,
the entity that hosts a web application such as Hyperkitty is in control
which JavaScript is shipped.

In such a case GPL isn't enuogh as you don't have to release modified
versions of the app, AGPL is required. 

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Björn Bidar <bjorn.bidar@thaodan.de> writes:

> Richard Stallman <rms@gnu.org> writes:

>>   > One problem with Hyperkitty is that it requires javascript to display
>>   > any message, which is makes it kind of useless in non-js browsers like
>>   > eww and lynx.
>>
>> Features that require Javascript are totallky unacceptable if the JS
>> code is nonfree (see https://gnu.org/philosophy/javascript-trap.html)
>> and problematical even if the JS code is free
>> (see https://gnu.org/philosophy/wwworst-app-store.html).
>
> Why do you assume JavaScript = nonfree? Mailman3-Hyperkitty is free software.

If he had assumed that, the second part of the sentence (problematic
even if free) would not make sense.

⇒ just quoting policy, not implying something about hyperkitty.

>> We should avoid web features that send JS code, whenever possible.
>> Sending code to run immediately in the user's computer, in a way that
>
> Besides avoiding JavaScript in modern web is impossible in 99% of the
> cases besides for websites that load all of their content synchronously
> on the initial load of the page.

While this is true in this very precise wording, the large majority of
websites that use Javascript can be implemented such that all of their
content is loaded on initial page load — including interactivity that
can be provided via CSS and standard form-validation.

The advantage of using that approach is that it usually degrades more
gracefully when using simpler frontends like lynx or ewww — I’ve been
limited to a text terminal quite a few times already while trying to
find answers to a problem and being able to read bug reports from a
browser that does not support JS is very useful for that.

(that said: if JS is used for progressive enhancement and the site is
 usable without JS, this just uses more of the capabilities of powerful
 clients without locking out those in simpler browsers
 https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement )

>> gives the user community no feasible opportunity to study the code and
>> release modified versions that people have a real option to use,
>> undermines the freedom of free software.
>
> You can't modify code of content that is loaded of from other computers,
> the entity that hosts a web application such as Hyperkitty is in control
> which JavaScript is shipped.
>
> In such a case GPL isn't enuogh as you don't have to release modified
> versions of the app, AGPL is required. 

This has also been discussed a lot already and is addressed in a third
article:
https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.html

«In this case, we call it Service as a Software Substitute, or SaaSS (we
coined that to be less vague and general than “Software as a Service”),
and such a service is always a bad thing. … However, most services'
principal functions are communicating or publishing information; they
are nothing like running any program yourself, so they are not SaaSS.
They could not be replaced by your copy of a program, either; a program
running in your own computers, used solely by you and isolated from
others, is not communicating with anyone else.»

@RMS: this article is not linked in
      https://www.gnu.org/philosophy/javascript-trap.html
      but it appears that it would be useful to link it there, maybe
      in the sentence “We are addressing the server issue separately.”

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: contributing to 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. ]]]

  > @RMS: this article is not linked in
  >       https://www.gnu.org/philosophy/javascript-trap.html
  >       but it appears that it would be useful to link it there, maybe
  >       in the sentence “We are addressing the server issue separately.”

Interesting idea.

I was skeptical about it, because SaaSS has nothing particularly to do with
use of JS.  That computing in the web site could be done with any sort
of computing method.

But it could be useful to mention at the start of the page that there
two kinds of problems a web page can have.

Thanks.
-- 
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: contributing to 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. ]]]

  > > Features that require Javascript are totallky unacceptable if the JS
  > > code is nonfree (see https://gnu.org/philosophy/javascript-trap.html)
  > > and problematical even if the JS code is free
  > > (see https://gnu.org/philosophy/wwworst-app-store.html).


  > Why do you assume JavaScript = nonfree? Mailman3-Hyperkitty is free
  > software.

I don't assume that.  In fact, I said explicitly that I don't.  I said,

> Features that require Javascript are totallky unacceptable if the JS
> code is nonfree (see https://gnu.org/philosophy/javascript-trap.html)
> and problematical even if the JS code is free
> (see https://gnu.org/philosophy/wwworst-app-store.html).

You're arguing against a moral issue based on practical convenience.
For the free software movement, moral issues are the most important.

  > Besides avoiding JavaScript in modern web is impossible in 99% of the
  > cases besides for websites that load all of [what they display] synchronously
  > on the initial load of the page.

Web sites hand a method for handling that in 2000: divide the material
into pages in a sensible way, and show each page completely when the user
goes there.

  > You can't modify code... that is loaded of from other computers,

That ie exactly the problem I mentioned.  This is why it is bad
for web sites to send code to execute in the user's browser.

  > the entity that hosts a web application such as Hyperkitty is in control
  > which JavaScript is shipped.

Yes, exactly.  That why Hyperkitty is fundamentally morally flawed.




-- 
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: contributing to Emacs

[Yuchen Pei]

On Wed 2023-06-28 23:03:34 -0400, Richard Stallman wrote:

> [[[ 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. ]]]
>
>   > One problem with Hyperkitty is that it requires javascript to display
>   > any message, which is makes it kind of useless in non-js browsers like
>   > eww and lynx.
>
> Features that require Javascript are totallky unacceptable if the JS
> code is nonfree (see https://gnu.org/philosophy/javascript-trap.html)
> and problematical even if the JS code is free
> (see https://gnu.org/philosophy/wwworst-app-store.html).
>
> We should avoid web features that send JS code, whenever possible.
> Sending code to run immediately in the user's computer, in a way that
> gives the user community no feasible opportunity to study the code and
> release modified versions that people have a real option to use,
> undermines the freedom of free software.

This is why I think it would be a good idea to write emacs/elisp client
packages to replace web/javascript clients. The former is much more free
than javascript you can't change. Examples of such packages include
osm.el[1] for openstreetmap, sx.el[2] for stackexchange, org-jira[3] for
JIRA , as well as the buildbot package I'm submitting to ELPA[4]. It
does not solve the server side issue (SaaSS), but it does offer complete
freedom on the client side.

[1] https://github.com/minad/osm
[2] https://github.com/vermiculus/sx.el
[3] https://github.com/ahungry/org-jira
[4] https://g.ypei.me/buildbot.el.git/about/

Best,
Yuchen

-- 
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
          <https://ypei.org/assets/ypei-pubkey.txt>

Re: contributing to 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 is why I think it would be a good idea to write emacs/elisp client
  > packages to replace web/javascript clients. The former is much more free
  > than javascript you can't change.

I agree.

  >  It
  > does not solve the server side issue (SaaSS), but it does offer complete
  > freedom on the client side.

If a service does SaaSS, that problem is inherent in the server's
essence.  Nothing we might do on the client side will alter it.
I just don't use those servers.

-- 
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: contributing to 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 write to mailman@gnu.org as the official place to contact
  > mailman admins.  This will also reach the GNU vols and FSF sys admins
  > who need to be kept in the loop as changes are made.

We are always looking for skilled GNU/Linux sysadmins to volunteer to
help in this work.  Would you be willing to join in part time?  Please
write to sysadmin@gnu.org.

-- 
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: contributing to 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 write to mailman@gnu.org as the official place to contact
  > mailman admins.  This will also reach the GNU vols and FSF sys admins
  > who need to be kept in the loop as changes are made.

I wrote this:

    We are always looking for skilled GNU/Linux sysadmins to volunteer to
    help in this work.  Would you be willing to join in part time?  Please
    write to sysadmin@gnu.org.

But what I really want to say is this:

We are always looking for skilled GNU/Linux sysadmins to volunteer
to help in this work.  Would any of you be willing to join in part
time?  Please write to sysadmin@gnu.org.


-- 
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: contributing to Emacs

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

   > In any case, that section hardly has any bearing on the main issue at
   > hand: how to make it easier for people to contribute.  I explained
   > that as well.

   That is because the large issue consists of many small ones! The only single
   "big move" that is theoretically possible is just move Emacs to a Gitlab
   instance, which will remove necessity to care of any docs because finding a
   developer who doesn't know how git-forges work is unlikely. But I *do not*
   suggest doing that because I know many long-timers would not want that. So
   instead I am trying to bite at different pieces that could be improved without
   affecting existing workflow. This docs discussion is just one small piece.

I'm sorry, but this cannot be taken seriously.  "remove necessity to
care of any docs"?  This is now how good software development works,
and such naive attiude for silver bullets is not only counter productive.

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> On Tue, 2023-06-20 at 14:14 +0300, Eli Zaretskii wrote:
>> I'd appreciate if this seasonal "what's wrong with Emacs
>> contributions" discussion would either switch to discussing some
>> innovative and useful ideas for how to make it easier for
>> contributors, or just died if there are no such ideas yet.
>> Reiterating the same claims and the same arguments doesn't sound like
>> a good use of our time and bandwidth.
>
> To my knowledge, I didn't "reiterate same claims", but was answering your
> reasoning about not wanting to change the docs, and your reasoning didn't seem
> to have been recursive so far. And it is pointless to suggest new ideas if we
> didn't even finish discussing old ones.

Maybe this was to both your arguments and my arguments which are
similar, though our proposed solutions differ.

I decided to stop pushing that point, because I realized that while I
know that part of my experience is fixing broken information flows (so I
actually think that I am right in this), it will not be a good use of my
or Eli's time if I keep pushing there but it gets rejected in the end
anyway.

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: contributing to Emacs

[David Masterson]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Masterson <dsmasterson@gmail.com>
>> 
>> Would you say that Emacs still has development practices from the
>> 80s/90s that, given the chance and newer toolsets, you could see being
>> done differently and better?
>
> What are "development practices from the 80s/90s"?

I'm not a developer of Emacs -- I've kibitzed around in it off and on
for 40+ years.  In the 80s, there was reliance on email/news for comms
(there wasn't much else available).  It worked good, but things got
misplaced once in awhile because of the disconnect between email & news.
I'm sure things have improved with newer tools (like Git allowing direct
checkout/checkin of code with proper controls rather than emailed patch
files), but I asked if you could see things being better.

>> It's okay to say that what Emacs has now is working well for the current
>> developers, but is difficult for on-boarding new developers that want to
>> start out simple before graduating into Emacs internals.
>
> Practical suggestions for changes that would make it easier are
> welcome, but they must not make the lives of the current developers
> significantly harder.

This is what I thought.  You, as a current developer, should be
commenting on suggestions from the standpoint of "will it make my life
harder?" (with a grain of flexibility).

I hope others understand that point.

-- 
David Masterson

Re: contributing to Emacs

[Po Lu]

David Masterson <dsmasterson@gmail.com> writes:

> I'm not a developer of Emacs -- I've kibitzed around in it off and on
> for 40+ years.  In the 80s, there was reliance on email/news for comms
> (there wasn't much else available).  It worked good, but things got
> misplaced once in awhile because of the disconnect between email & news.

I'm sure the proper fix is for the FSF to fix the news to mail gateways
between the various lists and GNUsenet.

Re: contributing to Emacs

[David Masterson]

Po Lu <luangruo@yahoo.com> writes:

> David Masterson <dsmasterson@gmail.com> writes:
>
>> I'm not a developer of Emacs -- I've kibitzed around in it off and on
>> for 40+ years.  In the 80s, there was reliance on email/news for comms
>> (there wasn't much else available).  It worked good, but things got
>> misplaced once in awhile because of the disconnect between email & news.
>
> I'm sure the proper fix is for the FSF to fix the news to mail gateways
> between the various lists and GNUsenet.

Mostly yes.  Back in the early days (~1987), that happened now and then.

But more that the "flow" of email is a bit different than news and new
people (as I was then) can miss something in email (because they weren't
on all the MLs) or news (because threads split and rejoined and you
missed something).  Also, working with patches via email/news was
sometimes problematic.

Things have gotten better over time.

-- 
David Masterson

Re: contributing to Emacs

[Alfred M. Szmidt]

   David Masterson <dsmasterson@gmail.com> writes:

   > I'm not a developer of Emacs -- I've kibitzed around in it off and on
   > for 40+ years.  In the 80s, there was reliance on email/news for comms
   > (there wasn't much else available).  It worked good, but things got
   > misplaced once in awhile because of the disconnect between email & news.

   I'm sure the proper fix is for the FSF to fix the news to mail gateways
   between the various lists and GNUsenet.

If it is something we, the GNU project wants, it is _us_ who should
make it happen.  Not the FSF.  So as usual, someone has to volunteer
to do that work.

Re: contributing to 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. ]]]

  > I'm sure the proper fix is for the FSF to fix the news to mail gateways
  > between the various lists and GNUsenet.

Can someone please report this in a concrete way?  I can forward
it to the sysadmins.

-- 
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: contributing to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > I'm sure the proper fix is for the FSF to fix the news to mail gateways
>   > between the various lists and GNUsenet.
>
> Can someone please report this in a concrete way?  I can forward
> it to the sysadmins.

Sure: articles posted to gnu.emacs.help don't end up on help-gnu-emacs,
and vice versa.

Re: contributing to Emacs

[David Masterson]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > I'm sure the proper fix is for the FSF to fix the news to mail gateways
>   > between the various lists and GNUsenet.
>
> Can someone please report this in a concrete way?  I can forward
> it to the sysadmins.

This particular discussion was in regards to the way things were a long
time ago in a place far, far away.  Things have improved since then.

-- 
David Masterson

Re: contributing to 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 particular discussion was in regards to the way things were a long
  > time ago in a place far, far away.  Things have improved since then.

I'm glad things have improved.  I have not heard anything concrete
about netnews since many years ago, except perhaps Google has taken
over netnews.

-- 
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: contributing to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> perhaps Google has taken over netnews.

This is not true!

Google operates a large news server that can only be used through their
web page.  But there are many other sites in existence, as always.

Re: contributing to 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. ]]]

  > Google operates a large news server that can only be used through their
  > web page.  But there are many other sites in existence, as always.

That is good news.  I had heard otherwise.

-- 
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: contributing to Emacs

[Eli Zaretskii]

> From: David Masterson <dsmasterson@gmail.com>
> Cc: hi-angel@yandex.ru,  arne_bab@web.de,  ams@gnu.org,  luangruo@yahoo.com,
>   philipk@posteo.net,  emacs-devel@gnu.org
> Date: Mon, 19 Jun 2023 15:47:05 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: David Masterson <dsmasterson@gmail.com>
> >> 
> >> Would you say that Emacs still has development practices from the
> >> 80s/90s that, given the chance and newer toolsets, you could see being
> >> done differently and better?
> >
> > What are "development practices from the 80s/90s"?
> 
> I'm not a developer of Emacs -- I've kibitzed around in it off and on
> for 40+ years.  In the 80s, there was reliance on email/news for comms
> (there wasn't much else available).  It worked good, but things got
> misplaced once in awhile because of the disconnect between email & news.

If this is about problems between email and news, then I don't think
it's relevant anymore, since hardly anyone here uses news anymore for
submitting changes and discussing them.

If I misunderstood, and "development practices from the 80s/90s"
something else, please elaborate.

> > Practical suggestions for changes that would make it easier are
> > welcome, but they must not make the lives of the current developers
> > significantly harder.
> 
> This is what I thought.  You, as a current developer, should be
> commenting on suggestions from the standpoint of "will it make my life
> harder?" (with a grain of flexibility).

That's one consideration, yes.  The other is what are the advantages
of the suggested changes.  Their balance is what drives the final
decisions.

Re: contributing to Emacs

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

   Okay, as mentioned elsewhere in thread, I think the problem is
   known and further discussion here ain't productive. So I'm going to
   stop here. But to answer something quickly verifiable:

Several people agree that contributing to Emacs is trivial, to the
point that you do not need to read _anything_ to make a contriubution,
even a significant one.  So what problem exactly is known?

   > Your message was quite far larger than both documents together
   > ... consider that for a second.  

   No. I measured specifically for you: "Sending Patches" alone is 5884 characters
   not counting bullets, and my email was 3491 characters.

Exaggerated claims, get overblown responses.  *shurg*

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 04:34 -0400, Alfred M. Szmidt wrote:
>    Okay, as mentioned elsewhere in thread, I think the problem is
>    known and further discussion here ain't productive. So I'm going to
>    stop here. But to answer something quickly verifiable:
> 
> Several people agree that contributing to Emacs is trivial, to the
> point that you do not need to read _anything_ to make a contriubution,
> even a significant one.  So what problem exactly is known?
> 
>    > Your message was quite far larger than both documents together
>    > ... consider that for a second.  
> 
>    No. I measured specifically for you: "Sending Patches" alone is 5884
> characters
>    not counting bullets, and my email was 3491 characters.
> 
> Exaggerated claims, get overblown responses.  *shurg*

My claims are easily verifiable and correct. Your claim wasn't correct.

But I don't know what you're getting at here, because even if my claims were
exaggerated, replying them with a lie (because as I understand your last
sentence it wasn't a mistake, you actually okay with it being wrong just because
you think my claims are exaggerated) is non-technical at best. I don't see much
point in further discussion with you, thanks.

Re: contributing to Emacs

[Po Lu]

Contributing to Emacs is easy from a technical perspective.

What will make it hard, is rejecting complex new features on the basis
that they are written by only one person.  Which is a position
inconsistent with all other recent development activity anyway: Bidi
reordering and native compilation are two major features that have been
written by one person alone, and for whom we have only one expert on
board, while at least one other person in this thread has Android
development experience.

Richard, would you please look at the thread starting at
<83v8fnslfz.fsf@gnu.org>, and make a final decision?  I'm afraid that if
the Android port isn't eventually installed, there will be a fork, and I
don't have the energy to work on both the fork and Emacs at the same
time.  So it would be nice to know what to expect now.

Re: contributing to 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. ]]]

  > Richard, would you please look at the thread starting at
  > <83v8fnslfz.fsf@gnu.org>, and make a final decision?

That was a big discussion and I've been very backlogged.  It seems to
be around 150 messages, according to grep.  I can't read that many!
It would take me hours.

It seems to be a matter of ease of maintenance, not directly a specific
technical point, and not an ethical issue.  I think the active maintainers
are the best people to decide this.

  >   I'm afraid that if
  > the Android port isn't eventually installed, there will be a fork,

1. Why would it be a fork, rather than updating a set of changes as has
happened with Emacs for MacOS?

2. Why would a fork be a very bad thing?

  >  and I
  > don't have the energy to work on both the fork and Emacs at the same
  > time.

3. Could you please tell me in 20 lines what the crucial issue is?
Has someone proposed a policy that we don't install a big change
if only one person can understand it?

4. Could we recruit Android wizards to help work on it?

-- 
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: contributing to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> That was a big discussion and I've been very backlogged.  It seems to
> be around 150 messages, according to grep.  I can't read that many!
> It would take me hours.
>
> It seems to be a matter of ease of maintenance, not directly a specific
> technical point, and not an ethical issue.  I think the active maintainers
> are the best people to decide this.

No active Emacs developers, aside from Eli and me, have commented on the
technical aspects of the issue.

> 1. Why would it be a fork, rather than updating a set of changes as has
> happened with Emacs for MacOS?

That hasn't happened with Emacs for Mac OS.  The NS port is part of the
GNU Emacs distribution.

> 2. Why would a fork be a very bad thing?

Because we will soon have a proliferation of subtly incompatible
varities of Emacs.

> 3. Could you please tell me in 20 lines what the crucial issue is?
> Has someone proposed a policy that we don't install a big change
> if only one person can understand it?

Not ``if only one person can understand it'', but rather ``if there is
_currently_ only one person who understands it.''

> 4. Could we recruit Android wizards to help work on it?

Probably, if the necessity arrives.  However, the work is finished.
All that remains is to install the changes.

Thanks.

Re: contributing to Emacs

[Gregory Heytings]

>
> No active Emacs developers, aside from Eli and me, have commented on the 
> technical aspects of the issue.
>

That remark is inelegant at best.

Re: contributing to 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. ]]]

  > > 2. Why would a fork be a very bad thing?

  > Because we will soon have a proliferation of subtly incompatible
  > varities of Emacs.

I dom't think that is necessarily so bad.

  > > Has someone proposed a policy that we don't install a big change
  > > if only one person can understand it?

  > Not ``if only one person can understand it'', but rather ``if there is
  > _currently_ only one person who understands it.''

Could you show me the actual proposal that was made?

  > > 4. Could we recruit Android wizards to help work on it?

  > Probably, if the necessity arrives.  However, the work is finished.
  > All that remains is to install the changes.

What work does "the work" refer to?  Various messages seem to say
that the code that has been written is only partial support for Emacs on Android -- that some important features are not yet implemented.


-- 
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: contributing to Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> I dom't think that is necessarily so bad.

It is: look at XEmacs, and the waste it led to.

> Could you show me the actual proposal that was made?

I suggest reading the first article in this thread.  Namely, this:

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

> Various messages seem to say that the code that has been written is
> only partial support for Emacs on Android -- that some important
> features are not yet implemented.

Would you please show me any of those messages?  I've been unequivocally
clear on this point: the port has already been completed (and was as far
back as April.)

Re: contributing to Emacs

[Philip Kaludercic]

Po Lu <luangruo@yahoo.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> I dom't think that is necessarily so bad.
>
> It is: look at XEmacs, and the waste it led to.

I think we have to distinguish between a diverging fork like XEmacs and
a "parallel" fork, that aims to preserve mutual compatibility.  In the
former case, the two projects will find it more and more difficult over
time to share code, while in the latter is just a question of
organisation and administration, that doesn't matter that much to the
user.

>> Could you show me the actual proposal that was made?
>
> I suggest reading the first article in this thread.  Namely, this:
>
>>  . 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
>
>> Various messages seem to say that the code that has been written is
>> only partial support for Emacs on Android -- that some important
>> features are not yet implemented.
>
> Would you please show me any of those messages?  I've been unequivocally
> clear on this point: the port has already been completed (and was as far
> back as April.)

I recall reading that GNUTLS was not supported on Android, making it
difficult to fetch packages from ELPA.  Has this been addressed?  I
would have looked it up myself, but I don't know where to begin.

Re: contributing to Emacs

[Po Lu]

Philip Kaludercic <philipk@posteo.net> writes:

> I recall reading that GNUTLS was not supported on Android, making it
> difficult to fetch packages from ELPA.  Has this been addressed?  I
> would have looked it up myself, but I don't know where to begin.

GnuTLS is supported, and my own builds are built with it enabled.  This
misconception results from F-Droid packaging Emacs without GnuTLS.

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Philip Kaludercic <philipk@posteo.net> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> I dom't think that is necessarily so bad.
>>
>> It is: look at XEmacs, and the waste it led to.
>
> I think we have to distinguish between a diverging fork like XEmacs and
> a "parallel" fork, that aims to preserve mutual compatibility.  In the
> former case, the two projects will find it more and more difficult over
> time to share code, while in the latter is just a question of
> organisation and administration, that doesn't matter that much to the
> user.

It means that the parallel fork has to be rebased everytime a change is
made and that people working on the original codebase do not see whether
their change breaks the parallel fork.

That creates additional work that does not exist at all if the codebases
are merged.

Just think of it like a long-running pull-request. In my experience
these always bitrot.

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: contributing to Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ams@gnu.org, hi-angel@yandex.ru, eliz@gnu.org, arne_bab@web.de,
> 	emacs-devel@gnu.org
> Date: Mon, 19 Jun 2023 22:55:27 -0400
> 
> Has someone proposed a policy that we don't install a big change
> if only one person can understand it?

I don't think it's useful to bring up such general questions here.

What I did ask was whether in this particular case we'd want to
install the Android changes, and describe some of the downsides I saw
to doing that.  Having just one individual who fully understands the
platform and the code was one of the downsides, but not the only one.

Re: contributing to Emacs

[chad]

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

HAving arguments on behalf of other people is an unfortunately common
conversational trap, especially in asynchronous mediums like mailing lists
and forums.

As someone who has been following emacs development and recruiting people
to help with it for multiple decades, let me say this: there is a common
(notorious) belief that contributing is difficult/complex/requiring of
confounding steps. The reality has improved a great deal over the pat ~5-6
years (due to heroic efforts of people like Eli, Lars, Stephan, Philip,
John, Chong, Stefan -- among others). At the same time, the baseline effort
required to participate in "open" development (whatever the term) has
dropped considerably, trending strongly towards the sort of "drive by
contrib" possibility that is common in many projects.

The end result is, I would have to agree, that it is still, at least
somewhat "notoriously hard to contribute to emacs". It's moving in a good
direction, but the effort surely has headroom left to fill.

There are frequent discussions on emacs-devel about new ways to address
this issue. I would caution people in this threat against getting caught in
yet another such thread, as they tend to consume a lot of oxygen, but
that's obviously up to each individual.

I hope that helps,
~Chad




On Sat, Jun 17, 2023 at 5:19 PM Alfred M. Szmidt <ams@gnu.org> wrote:

>    That's fine, let's not discuss it then.
>
> You've not explained what is hard, you raised multiple preferences,
> but not _why_.  Sending an email to emacs-devel@ with a patch, even
> without following those eight bullets is not hard -- people seem to be
> doing it all the time.
>
> Your responsibility as a contributor ends as soon as you fixed
> whatever issues are raised by the maintainters, and they commit the
> patch.  There is no need to look at some CI machinery to know if you
> screwed up -- it sorta isn't your problem.
>
>

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

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


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

>    So, yes, contributing to Emacs is hard.
>
> You might not _prefer_ the way it is done, but it is not hard as you
> purport it to be.  The chapter "Sending patches" is eight relativley
> simple bullets, the CONTRIBUTING is also not a very hard document to
> follow.

I think here’s a misconception about writing: 8 bullet points is not
simple. 4 bullet points are simple and can be grasped by humans
directly. Anything more becomes complex.



But let’s not discuss without the context at hand:

- Sending Patches: https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html
- CONTRIBUTE: https://www.gnu.org/software/emacs/CONTRIBUTE

The starting point to contribute is usually the website: 

    https://www.gnu.org/software/emacs

You can find Sending Patches if you click on Documentation & Support,
then go into the manual and search for sending patches — or check in the
reporting bugs section. That’s at least 3 clicks if you know what you’re
doing. If you don’t — good luck finding it.

The Reporting bugs section in Documentation & Support only links the
CONTRIBUTE file as plain text, even though it’s org-mode, so it could be
linked as html (easier to read in the browser). That’s only two links to
click — again: if you know what you’re doing.

As an aside: IRC is linked in "further information", not in
"documentation and support" — I’m not sure why that page exists, because
all the content seems to belong to Documentation & support. Maybe that
could be replaced by a dedicated "Contributing" page with a shorter
version of sending patches.


To make this constructive: If this is intended to be easy, I’d have
imagined something like this (using Sending Patches as base).

------ ------ ------ ------ ------ ------ 

To contribute patches please make them easy to use for maintainers:

- patch format: Send patches with explanation in a single email as MIME
  attachment or inline. Create your patches with diff -u (with the old
  version as first version) or with ~git format-patch master~ (for
  commited changes) or ~git diff~ (for uncommited changes).

- commit log: Include a commit log entry in the correct style. They are
  described in
  https://www.gnu.org/software/emacs/manual/html_node/emacs/Format-of-ChangeLog.html
  Look at earlier commits for examples.

- target address: Send unfinished patches for discussion to
  emacs-devel@gnu.org. Send fixes for an existing bug to the
  <number>@debbugs.gnu.org address of the bug. Send new bug-reports with
  fix to bug-gnu-emacs@gnu.org.

- patch content: Please send atomic changes: we’d rather get two emails
  than one that mixes concerns. For new bugs, use ~M-x report-emacs-bug~
  to include the information needed for bug-reports.

For more details, please read at
https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html

------ ------ ------ ------ ------ ------ 

I believe that this includes the essential information from
https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html
so someone following these 4 bullet points will already send patches in
the required format. This should be much easier to parse for
contributors.

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: contributing to Emacs

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Konstantin Kharlamov <hi-angel@yandex.ru>, eliz@gnu.org,
>  luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 11:26:37 +0200
> 
> To make this constructive: If this is intended to be easy, I’d have
> imagined something like this (using Sending Patches as base).
> 
> ------ ------ ------ ------ ------ ------ 
> 
> To contribute patches please make them easy to use for maintainers:
> 
> - patch format: Send patches with explanation in a single email as MIME
>   attachment or inline. Create your patches with diff -u (with the old
>   version as first version) or with ~git format-patch master~ (for
>   commited changes) or ~git diff~ (for uncommited changes).
> 
> - commit log: Include a commit log entry in the correct style. They are
>   described in
>   https://www.gnu.org/software/emacs/manual/html_node/emacs/Format-of-ChangeLog.html
>   Look at earlier commits for examples.
> 
> - target address: Send unfinished patches for discussion to
>   emacs-devel@gnu.org. Send fixes for an existing bug to the
>   <number>@debbugs.gnu.org address of the bug. Send new bug-reports with
>   fix to bug-gnu-emacs@gnu.org.
> 
> - patch content: Please send atomic changes: we’d rather get two emails
>   than one that mixes concerns. For new bugs, use ~M-x report-emacs-bug~
>   to include the information needed for bug-reports.
> 
> For more details, please read at
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html

This refers to other places, so if the reader needs to read them, the
gain is largely an illusory one: you must read those referenced places
as well.

Summary is only useful in cases like this if the details are
non-essential.  If they _are_ essential, a summary with references
doesn't make the reading simpler or shorter.

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> For more details, please read at
>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html
>
> This refers to other places, so if the reader needs to read them, the
> gain is largely an illusory one: you must read those referenced places
> as well.

You don’t have to read those places. I took care to ensure that all the
essential parts for contributing a patch are in my shorter version.

The reference to other places is there for people who think they have
special requirements or want to understand *why* the rules are as they
are.

Maybe the text should make that clear, so this should not be "for more
details", but "for explanations of these rules, please read
https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html"

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: contributing to Emacs

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: ams@gnu.org, hi-angel@yandex.ru, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 12:30:04 +0200
> 
> > This refers to other places, so if the reader needs to read them, the
> > gain is largely an illusory one: you must read those referenced places
> > as well.
> 
> You don’t have to read those places. I took care to ensure that all the
> essential parts for contributing a patch are in my shorter version.
> 
> The reference to other places is there for people who think they have
> special requirements or want to understand *why* the rules are as they
> are.

AFAICT, without reading all those places the instructions are
incomplete.  We might as well just said: send the patches to us, and
omit all the rest.

> Maybe the text should make that clear, so this should not be "for more
> details", but "for explanations of these rules, please read
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html"

Those are neither "more details" nor "explanations", they are what we
expect from a perfect patch submit.  I don't see how we can omit them,
if we want to describe our conventions in full.  Without such a full
description, that whole section is unnecessary.

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> Maybe the text should make that clear, so this should not be "for more
>> details", but "for explanations of these rules, please read
>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html"
>
> Those are neither "more details" nor "explanations", they are what we
> expect from a perfect patch submit.  I don't see how we can omit them,
> if we want to describe our conventions in full.  Without such a full
> description, that whole section is unnecessary.

That sounds like improving the average patch submitted would be useless
if the instructions are not perfect for every case.

But that risks losing contributors because they give up when reading the
instructions.

The goal is easier onboarding. Any hurdle in the way of sending a good
patch¹ causes fewer good patches to be sent — and more bad patches,
because people then don’t read the section at all (or don’t even find
it, because on the website only CONTRIBUTING is linked with a description
that indicates that says that this is about contributing).

¹: good need not be perfect, but good enough to make maintenance easy.

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: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 11:26 +0200, Dr. Arne Babenhauserheide wrote:
> ------ ------ ------ ------ ------ ------
>
> To contribute patches please make them easy to use for maintainers:
>
> - patch format: Send patches with explanation in a single email as MIME
>   attachment or inline. Create your patches with diff -u (with the old
>   version as first version) or with ~git format-patch master~ (for
>   commited changes) or ~git diff~ (for uncommited changes).

While at it, I think it may be worth to improve this a bit as well. I presume
the "old version as first version" refers to Emacs before it started using git?
I think there's no point to mention it because if you contribute to a project,
you always need the very latest code, in which case there's git support. So I
think `diff -u` mention may be removed. Perhaps:

    - patch format: Send patches with explanation in a single email as MIME attachment or
      inline. Create your patches with with ~git format-patch master~ (for commited
      changes) or ~git diff~ (for uncommited changes).

And I'm also wondering if there's any point mentioning `git diff` as well. I think
it's reasonable to expect most people know how to use git and they probably have made
commits, so the `git format-patch` is the way to go.

But even is a person is complete newbie, having to `git-diff` and then to write
commit message manually is uncomfortable, because you have to write the message anew
every time you address a review. It may be better to just suggest to do `git
format-patch` instead.

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Sat, 2023-06-17 at 14:36 -0400, Alfred M. Szmidt wrote:
> open sources projects only requires finding out their upstream URL,

And usually creating an account, putting SSH keys into it, and so forth …

> in Emacs case you
> also need to go read HUGE "Sending patches" section.

This sounds like a writing problem: such a section should be quick to
read. Do you have concrete ideas how to slim this down?

Maybe with some simple examples how to send the patches.

> And then if that's not enough, from what I've seen maintainers also
> expect you to have read CONTRIBUTE section, which is absolutely large,
> much bigger than "Sending patches". (to be fair, if you are a new
> contributor, you won't know it exists because "Sending patches" has no
> mention of it).

Same here. I see quite a bit of explanation in the CONTRIBUTE file that
makes that longer than the information a contributor really has to know.

> more complicated. You see: these are complete no-brainer in 90% of projects. But
> every time I contribute here I have to think about such stuff which is completely
> irrelevant to the changes being sent.
> And how do you even get a link where to send new patch revision? I have two dozens
> email notifications coming to my email everyday. So I will have to search through all
> that stuff.

Can this be improved with changes to debbug emails sent? Or to the
debbug web interface?

For a github project (to name the elefant in the room) you also have to
know the URL, but there it feels easier. Can we make that easier in the
existing infrastructure?

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: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 10:59 +0200, Dr. Arne Babenhauserheide wrote:
> 
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > On Sat, 2023-06-17 at 14:36 -0400, Alfred M. Szmidt wrote:
> > open sources projects only requires finding out their upstream URL,
> 
> And usually creating an account, putting SSH keys into it, and so forth …
> 
> > in Emacs case you
> > also need to go read HUGE "Sending patches" section.
> 
> This sounds like a writing problem: such a section should be quick to
> read. Do you have concrete ideas how to slim this down?
> 
> Maybe with some simple examples how to send the patches.

Well… Yes. I see that the section "Sending Patches" is actually mixed up also
with the information about what changes should be contained in it. It is a
useful information, but I think it could be great if that was *on the same page*
but *in a separate paragraph*. This would allow a person to immediately know
which part is related to just "how to send a patch" and which is about the
commit message and stuff like that.

I can send the changes if there's any interest.

> > And then if that's not enough, from what I've seen maintainers also
> > expect you to have read CONTRIBUTE section, which is absolutely large,
> > much bigger than "Sending patches". (to be fair, if you are a new
> > contributor, you won't know it exists because "Sending patches" has no
> > mention of it).
> 
> Same here. I see quite a bit of explanation in the CONTRIBUTE file that
> makes that longer than the information a contributor really has to know.

Eli said elsewhere that reading this file isn't required, so whatever. The
"Sending Patches" section does not refer to it anyway.

> > more complicated. You see: these are complete no-brainer in 90% of projects.
> > But
> > every time I contribute here I have to think about such stuff which is
> > completely
> > irrelevant to the changes being sent.
> > And how do you even get a link where to send new patch revision? I have two
> > dozens
> > email notifications coming to my email everyday. So I will have to search
> > through all
> > that stuff.
> 
> Can this be improved with changes to debbug emails sent? Or to the
> debbug web interface?
> 
> For a github project (to name the elefant in the room) you also have to
> know the URL, but there it feels easier. Can we make that easier in the
> existing infrastructure?

I will need to think about that, but I would guess there should be ways.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 12:30 +0300, Konstantin Kharlamov wrote:
> Well… Yes. I see that the section "Sending Patches" is actually mixed up also
> with the information about what changes should be contained in it. It is a
> useful information, but I think it could be great if that was *on the same
> page* but *in a separate paragraph*. 

Sorry, I mean to say "with a separate heading". In my language "paragraph" has a
bit different meaning, I meant as in, having a separate title on the same page.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 12:30 +0300, Konstantin Kharlamov wrote:
> On Sun, 2023-06-18 at 10:59 +0200, Dr. Arne Babenhauserheide wrote:
> > 
> > Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> > > more complicated. You see: these are complete no-brainer in 90% of
> > > projects.
> > > But
> > > every time I contribute here I have to think about such stuff which is
> > > completely
> > > irrelevant to the changes being sent.
> > > And how do you even get a link where to send new patch revision? I have
> > > two
> > > dozens
> > > email notifications coming to my email everyday. So I will have to search
> > > through all
> > > that stuff.
> > 
> > Can this be improved with changes to debbug emails sent? Or to the
> > debbug web interface?
> > 
> > For a github project (to name the elefant in the room) you also have to
> > know the URL, but there it feels easier. Can we make that easier in the
> > existing infrastructure?
> 
> I will need to think about that, but I would guess there should be ways.

Okay, so, here's an obvious one: a patch series sent to bug-gnu-emacs@gnu.org
should not create separate bugreports for every patch.

In ML-managed projects it is typical to send patches as a series, and when you
doing that results in such surprising behaviour, it creates an additional
emotional and mental load both for you and for maintainers who would need to do
something with these separate reports.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org, luangruo@yahoo.com, 
> 	emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 12:56:33 +0300
> 
> Okay, so, here's an obvious one: a patch series sent to bug-gnu-emacs@gnu.org
> should not create separate bugreports for every patch.
> 
> In ML-managed projects it is typical to send patches as a series, and when you
> doing that results in such surprising behaviour, it creates an additional
> emotional and mental load both for you and for maintainers who would need to do
> something with these separate reports.

Our preference is to send patches as a single patch, not as patch
series.

That said, people are sometimes sending series, and we don't ask them
to resend, we process those series anyway.

As for separate bug reports, this is easily fixed by merging them.

So I see no problem here.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 13:02 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org, luangruo@yahoo.com, 
> >         emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 12:56:33 +0300
> > 
> > Okay, so, here's an obvious one: a patch series sent to
> > bug-gnu-emacs@gnu.org
> > should not create separate bugreports for every patch.
> > 
> > In ML-managed projects it is typical to send patches as a series, and when
> > you
> > doing that results in such surprising behaviour, it creates an additional
> > emotional and mental load both for you and for maintainers who would need to
> > do
> > something with these separate reports.
> 
> Our preference is to send patches as a single patch, not as patch
> series.
> 
> That said, people are sometimes sending series, and we don't ask them
> to resend, we process those series anyway.
> 
> As for separate bug reports, this is easily fixed by merging them.

Unfortunately merging bugreports does not fix that. The last patch I had to
Emacs was sent with a cover letter and resulted in two reports: one for the
cover letter and another for the patch itself. You may remember that it resulted
in a confusion, because α) discussions happened on both threads, but then a new
patch version was only sent to one of them, so there other thread wasn't
notified that comments were addressed, and β) you may remember 3 months after
the patch got accepted someone was asking the status. Which is because one of
the threads was closed saying that the patch is applied, but then the other
thread into which a person was looking has no such comment.

> So I see no problem here.

This is psychology. Having a report per patch may not be a problem for you, but
when a contributor sends patches and gets into such situation, they do not know
it is okay. They will be frightened and frustrated, because it looks like
something just went wrong. Such situation being okay needs at least be mentioned
in "sending patches" section, and at best it should just work.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 13:13:23 +0300
> 
> On Sun, 2023-06-18 at 13:02 +0300, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org, luangruo@yahoo.com, 
> > >         emacs-devel@gnu.org
> > > Date: Sun, 18 Jun 2023 12:56:33 +0300
> > > 
> > > Okay, so, here's an obvious one: a patch series sent to
> > > bug-gnu-emacs@gnu.org
> > > should not create separate bugreports for every patch.
> > > 
> > > In ML-managed projects it is typical to send patches as a series, and when
> > > you
> > > doing that results in such surprising behaviour, it creates an additional
> > > emotional and mental load both for you and for maintainers who would need to
> > > do
> > > something with these separate reports.
> > 
> > Our preference is to send patches as a single patch, not as patch
> > series.
> > 
> > That said, people are sometimes sending series, and we don't ask them
> > to resend, we process those series anyway.
> > 
> > As for separate bug reports, this is easily fixed by merging them.
> 
> Unfortunately merging bugreports does not fix that. The last patch I had to
> Emacs was sent with a cover letter and resulted in two reports: one for the
> cover letter and another for the patch itself. You may remember that it resulted
> in a confusion, because α) discussions happened on both threads, but then a new
> patch version was only sent to one of them, so there other thread wasn't
> notified that comments were addressed, and β) you may remember 3 months after
> the patch got accepted someone was asking the status. Which is because one of
> the threads was closed saying that the patch is applied, but then the other
> thread into which a person was looking has no such comment.
> 
> > So I see no problem here.
> 
> This is psychology. Having a report per patch may not be a problem for you, but
> when a contributor sends patches and gets into such situation, they do not know
> it is okay. They will be frightened and frustrated, because it looks like
> something just went wrong. Such situation being okay needs at least be mentioned
> in "sending patches" section, and at best it should just work.

Like I said: we prefer a single patch for each changeset.  The
problems presented by patch series are one reason.  And yet, we will
never reject a patch series, even though it makes the process
inconvenient and confusing.

I don't see what else do we need to argued about here.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 13:22 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 13:13:23 +0300
> > 
> > On Sun, 2023-06-18 at 13:02 +0300, Eli Zaretskii wrote:
> > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > > Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org, luangruo@yahoo.com, 
> > > >         emacs-devel@gnu.org
> > > > Date: Sun, 18 Jun 2023 12:56:33 +0300
> > > > 
> > > > Okay, so, here's an obvious one: a patch series sent to
> > > > bug-gnu-emacs@gnu.org
> > > > should not create separate bugreports for every patch.
> > > > 
> > > > In ML-managed projects it is typical to send patches as a series, and
> > > > when
> > > > you
> > > > doing that results in such surprising behaviour, it creates an
> > > > additional
> > > > emotional and mental load both for you and for maintainers who would
> > > > need to
> > > > do
> > > > something with these separate reports.
> > > 
> > > Our preference is to send patches as a single patch, not as patch
> > > series.
> > > 
> > > That said, people are sometimes sending series, and we don't ask them
> > > to resend, we process those series anyway.
> > > 
> > > As for separate bug reports, this is easily fixed by merging them.
> > 
> > Unfortunately merging bugreports does not fix that. The last patch I had to
> > Emacs was sent with a cover letter and resulted in two reports: one for the
> > cover letter and another for the patch itself. You may remember that it
> > resulted
> > in a confusion, because α) discussions happened on both threads, but then a
> > new
> > patch version was only sent to one of them, so there other thread wasn't
> > notified that comments were addressed, and β) you may remember 3 months
> > after
> > the patch got accepted someone was asking the status. Which is because one
> > of
> > the threads was closed saying that the patch is applied, but then the other
> > thread into which a person was looking has no such comment.
> > 
> > > So I see no problem here.
> > 
> > This is psychology. Having a report per patch may not be a problem for you,
> > but
> > when a contributor sends patches and gets into such situation, they do not
> > know
> > it is okay. They will be frightened and frustrated, because it looks like
> > something just went wrong. Such situation being okay needs at least be
> > mentioned
> > in "sending patches" section, and at best it should just work.
> 
> Like I said: we prefer a single patch for each changeset.  The
> problems presented by patch series are one reason.  And yet, we will
> never reject a patch series, even though it makes the process
> inconvenient and confusing.
> 
> I don't see what else do we need to argued about here.

Well, you see, the "sending patches" section has no mention that a series is
unwelcome. And Emacs is the unique project where a squashed patch with many
commits is preferred over a series.

If series is indeed unwelcome, it would be better to reflect in "sending
patches" section and provide copy-paste instructions for the people to quickly
squash their commits before sending to ML (and I think something needs to be
figured out about commit messages too in this case). Because when you are
developing, it is easier to separate changes to distinct commits to make sure
that if something break you know what exactly change was the reason to it. Even
if these commits will have to be squashed later.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 13:27:47 +0300
> 
> > Like I said: we prefer a single patch for each changeset.  The
> > problems presented by patch series are one reason.  And yet, we will
> > never reject a patch series, even though it makes the process
> > inconvenient and confusing.
> > 
> > I don't see what else do we need to argued about here.
> 
> Well, you see, the "sending patches" section has no mention that a series is
> unwelcome.

They aren't "unwelcome", please don't misquote what I write.

> If series is indeed unwelcome, it would be better to reflect in "sending
> patches" section and provide copy-paste instructions for the people to quickly
> squash their commits before sending to ML (and I think something needs to be
> figured out about commit messages too in this case). Because when you are
> developing, it is easier to separate changes to distinct commits to make sure
> that if something break you know what exactly change was the reason to it. Even
> if these commits will have to be squashed later.

It sounds like you have just asked us to make that section larger, is
that right?

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 13:36 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 13:27:47 +0300
> > 
> > > Like I said: we prefer a single patch for each changeset.  The
> > > problems presented by patch series are one reason.  And yet, we will
> > > never reject a patch series, even though it makes the process
> > > inconvenient and confusing.
> > > 
> > > I don't see what else do we need to argued about here.
> > 
> > Well, you see, the "sending patches" section has no mention that a series is
> > unwelcome.
> 
> They aren't "unwelcome", please don't misquote what I write.

Hmm, I feel like there's some confusion. You said that a single patch is
preferred over a series, right? And then you said it is the reason we don't need
to do anything about the problem with sending a series to bug-gnu-emacs@gnu.org

But the problem exists, so I'm suggesting that if you don't want it to be fixed,
perhaps we should put some docs about that.

If you say a series is not "unwelcome", then this documentation should simply
mention the problem.

> > If series is indeed unwelcome, it would be better to reflect in "sending
> > patches" section and provide copy-paste instructions for the people to
> > quickly
> > squash their commits before sending to ML (and I think something needs to be
> > figured out about commit messages too in this case). Because when you are
> > developing, it is easier to separate changes to distinct commits to make
> > sure
> > that if something break you know what exactly change was the reason to it.
> > Even
> > if these commits will have to be squashed later.
> 
> It sounds like you have just asked us to make that section larger, is
> that right?

Yes, but it can still be easier to read than it is now. A few mails above I put
a suggestion to separate "how to send a patch" and "what changes should it
contain" to different chapters (ideally contained on a single page though). I
can rewrite the section and send it here if there's any interest. I didn't get
any reply if such change is welcome or not, but I imagine it would simplify the
page a lot.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 13:44:59 +0300
> 
> > > Well, you see, the "sending patches" section has no mention that a series is
> > > unwelcome.
> > 
> > They aren't "unwelcome", please don't misquote what I write.
> 
> Hmm, I feel like there's some confusion. You said that a single patch is
> preferred over a series, right?

"Preferred", yes.  That's a far cry from "unwelcoming" patch series.

> And then you said it is the reason we don't need
> to do anything about the problem with sending a series to bug-gnu-emacs@gnu.org
> 
> But the problem exists, so I'm suggesting that if you don't want it to be fixed,
> perhaps we should put some docs about that.

The problem, such as it exists, is mine and of other people who review
patches.  It isn't the problem of those who _submit_ patches.
Therefore, there is no need to make the instructions longer on behalf
of what isn't the contributor's problem.  In the rare case that a
first-time contributor submits a whole series of patches, he or she
will be told that we prefer a single patch.  That's all, end of story.
Most contributors will never even bump into this, because it is rare
for a casual contributor to submit such complex patches.

> > It sounds like you have just asked us to make that section larger, is
> > that right?
> 
> Yes, but it can still be easier to read than it is now. A few mails above I put
> a suggestion to separate "how to send a patch" and "what changes should it
> contain" to different chapters (ideally contained on a single page though). I
> can rewrite the section and send it here if there's any interest. I didn't get
> any reply if such change is welcome or not, but I imagine it would simplify the
> page a lot.

So when we write text that explains our conventions, it's "too long",
but when you suggest to add more stuff, that makes it "easier to
read"?  Doesn't sound consistent to me.

We only describe in the instructions stuff that is important enough,
and try to keep the details to the absolute minimum that is necessary.
You may think that other aspects are more important, but, with all due
respect, it isn't your call.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 13:59 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 13:44:59 +0300
> > 
> > > > Well, you see, the "sending patches" section has no mention that a
> > > > series is
> > > > unwelcome.
> > > 
> > > They aren't "unwelcome", please don't misquote what I write.
> > 
> > Hmm, I feel like there's some confusion. You said that a single patch is
> > preferred over a series, right?
> 
> "Preferred", yes.  That's a far cry from "unwelcoming" patch series.
> 
> > And then you said it is the reason we don't need
> > to do anything about the problem with sending a series to
> > bug-gnu-emacs@gnu.org
> > 
> > But the problem exists, so I'm suggesting that if you don't want it to be
> > fixed,
> > perhaps we should put some docs about that.
> 
> The problem, such as it exists, is mine and of other people who review
> patches.  It isn't the problem of those who _submit_ patches.
> Therefore, there is no need to make the instructions longer on behalf
> of what isn't the contributor's problem.  In the rare case that a
> first-time contributor submits a whole series of patches, he or she
> will be told that we prefer a single patch.  That's all, end of story.
> Most contributors will never even bump into this, because it is rare
> for a casual contributor to submit such complex patches.

Well… Okay.

> > > It sounds like you have just asked us to make that section larger, is
> > > that right?
> > 
> > Yes, but it can still be easier to read than it is now. A few mails above I
> > put
> > a suggestion to separate "how to send a patch" and "what changes should it
> > contain" to different chapters (ideally contained on a single page though).
> > I
> > can rewrite the section and send it here if there's any interest. I didn't
> > get
> > any reply if such change is welcome or not, but I imagine it would simplify
> > the
> > page a lot.
> 
> So when we write text that explains our conventions, it's "too long",
> but when you suggest to add more stuff, that makes it "easier to
> read"?  Doesn't sound consistent to me.

You missed my point. The section "how to submit patches" will become
significantly shorter. Because it will be separated from all the other points
about what a patch should contain.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 14:14:55 +0300
> 
> You missed my point. The section "how to submit patches" will become
> significantly shorter. Because it will be separated from all the other points
> about what a patch should contain.

Separating them will be even more confusing: people will read one, but
not the other, and tell us they didn't find something.

Would you please trust me that I care about those instructions very
much and take every opportunity to make them better, in every aspect?

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 14:32 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 14:14:55 +0300
> > 
> > You missed my point. The section "how to submit patches" will become
> > significantly shorter. Because it will be separated from all the other
> > points
> > about what a patch should contain.
> 
> Separating them will be even more confusing: people will read one, but
> not the other, and tell us they didn't find something.

Not necessarily. Let me reiterate: the chapter "Sending Patches" has two
different things: "How to send patches" and "What should patch contain". It is
*already* the case, all I am suggesting is simply divide them with a title
(well, maybe a little bit of refactoring may be needed to make sure the two
parts has only relevant texts).

Why would a person complain they didn't find text about patch content in section
"how to send patches" if it belongs to the section right next to it "What should
a patch contain".

If these two sections are on the same page, a person would see them both,
especially so given the "how to send patches" section would be very short.

(we can think of better sections naming, these two titles are just something I
made up offhand)

> Would you please trust me that I care about those instructions very
> much and take every opportunity to make them better, in every aspect?

Of course, this is why we're discussing them 😊

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 14:54:11 +0300
> 
> > Separating them will be even more confusing: people will read one, but
> > not the other, and tell us they didn't find something.
> 
> Not necessarily. Let me reiterate: the chapter "Sending Patches" has two
> different things: "How to send patches" and "What should patch contain". It is
> *already* the case, all I am suggesting is simply divide them with a title
> (well, maybe a little bit of refactoring may be needed to make sure the two
> parts has only relevant texts).

A new contributor needs to know both.

> Why would a person complain they didn't find text about patch content in section
> "how to send patches" if it belongs to the section right next to it "What should
> a patch contain".

Because in an Info reader you don't necessarily see the "section right
next to the current one".

> If these two sections are on the same page, a person would see them both,
> especially so given the "how to send patches" section would be very short.

You assume the contributors read a paper copy or a PDF version of the
manual?

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 15:18 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 14:54:11 +0300
> > 
> > > Separating them will be even more confusing: people will read one, but
> > > not the other, and tell us they didn't find something.
> > 
> > Not necessarily. Let me reiterate: the chapter "Sending Patches" has two
> > different things: "How to send patches" and "What should patch contain". It
> > is
> > *already* the case, all I am suggesting is simply divide them with a title
> > (well, maybe a little bit of refactoring may be needed to make sure the two
> > parts has only relevant texts).
> 
> A new contributor needs to know both.
> 
> > Why would a person complain they didn't find text about patch content in
> > section
> > "how to send patches" if it belongs to the section right next to it "What
> > should
> > a patch contain".
> 
> Because in an Info reader you don't necessarily see the "section right
> next to the current one".

I assume it's a question of markup. I don't know offhand what format is used for
this document, but I can tell that in the worst case a section title may be
created by simply putting a text in bold.

> > If these two sections are on the same page, a person would see them both,
> > especially so given the "how to send patches" section would be very short.
> 
> You assume the contributors read a paper copy or a PDF version of the
> manual?

I am assuming that if a person doesn't know how to contribute to Emacs, they
will query a search engine about that. And search engine would send them to this
page
https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> I am assuming that if a person doesn't know how to contribute to Emacs, they
> will query a search engine about that. And search engine would send them to this
> page
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html

When I looked up instructions (instead of just using M-x report bug (and
completing on report-emacs-bug with amx), I used the tried and true
approach to look for a "contributing" link on the project-website.

It didn’t work.

I think that’s a bug in the website and may be part of the explanation
why additional ports did not bring many additional developers.
(though the Emacs website is already much, much better than it was two
decades ago)

- today: https://web.archive.org/web/20230602202220/http://www.gnu.org/software/emacs/
- one decade ago: https://web.archive.org/web/20130704144538/http://www.gnu.org/software/emacs/
- two decades ago: https://web.archive.org/web/20030205055456/http://www.gnu.org/software/emacs/

Though for contributors, there’s actually one thing that got worse:
searching on the website for "contribut" turned up the CONTRIBUTING file
before the current design and now doesn’t turn up a result.

Two decades ago:

>  To contact the maintainers of Emacs, either to report a bug or to
>  contribute fixes or improvements, send mail to
>  <bug-gnu-emacs@gnu.org>.

One decade ago:

> To report bugs, or to contribute fixes and improvements, use the
> built-in Emacs bug reporter (M-x report-emacs-bug) or send email to
> bug-gnu-emacs@gnu.org. You can browse our bug database at
> debbugs.gnu.org. For more information on contributing, see the
> CONTRIBUTE file (also distributed with Emacs).

Now:

(you have to click on "Documentation & Support" or on "Further
information" to find something about contributing or development).

I think that’s a regression that needs fixing.

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: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Sun, 2023-06-18 at 13:22 +0300, Eli Zaretskii wrote:
>> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
>> > Date: Sun, 18 Jun 2023 13:13:23 +0300
>> > 
>> > On Sun, 2023-06-18 at 13:02 +0300, Eli Zaretskii wrote:
>> > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
>> > > > Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org, luangruo@yahoo.com, 
>> > > >         emacs-devel@gnu.org
>> > > > Date: Sun, 18 Jun 2023 12:56:33 +0300
>> > > > 
>> > > > Okay, so, here's an obvious one: a patch series sent to
>> > > > bug-gnu-emacs@gnu.org
>> > > > should not create separate bugreports for every patch.
>> > > > 
>> > > > In ML-managed projects it is typical to send patches as a series, and
>> > > > when
>> > > > you
>> > > > doing that results in such surprising behaviour, it creates an
>> > > > additional
>> > > > emotional and mental load both for you and for maintainers who would
>> > > > need to
>> > > > do
>> > > > something with these separate reports.
>> > > 
>> > > Our preference is to send patches as a single patch, not as patch
>> > > series.
>> > > 
>> > > That said, people are sometimes sending series, and we don't ask them
>> > > to resend, we process those series anyway.
>> > > 
>> > > As for separate bug reports, this is easily fixed by merging them.
>> > 
>> > Unfortunately merging bugreports does not fix that. The last patch I had to
>> > Emacs was sent with a cover letter and resulted in two reports: one for the
>> > cover letter and another for the patch itself. You may remember that it
>> > resulted
>> > in a confusion, because α) discussions happened on both threads, but then a
>> > new
>> > patch version was only sent to one of them, so there other thread wasn't
>> > notified that comments were addressed, and β) you may remember 3 months
>> > after
>> > the patch got accepted someone was asking the status. Which is because one
>> > of
>> > the threads was closed saying that the patch is applied, but then the other
>> > thread into which a person was looking has no such comment.
>> > 
>> > > So I see no problem here.
>> > 
>> > This is psychology. Having a report per patch may not be a problem for you,
>> > but
>> > when a contributor sends patches and gets into such situation, they do not
>> > know
>> > it is okay. They will be frightened and frustrated, because it looks like
>> > something just went wrong. Such situation being okay needs at least be
>> > mentioned
>> > in "sending patches" section, and at best it should just work.
>> 
>> Like I said: we prefer a single patch for each changeset.  The
>> problems presented by patch series are one reason.  And yet, we will
>> never reject a patch series, even though it makes the process
>> inconvenient and confusing.
>> 
>> I don't see what else do we need to argued about here.
>
> Well, you see, the "sending patches" section has no mention that a series is
> unwelcome. And Emacs is the unique project where a squashed patch with many
> commits is preferred over a series.

There is "When you have all these pieces, bundle them up in a mail
message and send it to the developers."¹ which to me implies to send a
single email.

But it can easily get missed in the long text (datapoint for that: you
missed it), that’s why I think the text shown to new contributors should
get changed.

¹: https://www.gnu.org/software/emacs/manual/html_node/emacs/Sending-Patches.html

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: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 12:54 +0200, Dr. Arne Babenhauserheide wrote:
> 
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > On Sun, 2023-06-18 at 13:22 +0300, Eli Zaretskii wrote:
> > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > > Cc: arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com,
> > > > emacs-devel@gnu.org
> > > > Date: Sun, 18 Jun 2023 13:13:23 +0300
> > > > 
> > > > On Sun, 2023-06-18 at 13:02 +0300, Eli Zaretskii wrote:
> > > > > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > > > > Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org,
> > > > > > luangruo@yahoo.com, 
> > > > > >         emacs-devel@gnu.org
> > > > > > Date: Sun, 18 Jun 2023 12:56:33 +0300
> > > > > > 
> > > > > > Okay, so, here's an obvious one: a patch series sent to
> > > > > > bug-gnu-emacs@gnu.org
> > > > > > should not create separate bugreports for every patch.
> > > > > > 
> > > > > > In ML-managed projects it is typical to send patches as a series,
> > > > > > and
> > > > > > when
> > > > > > you
> > > > > > doing that results in such surprising behaviour, it creates an
> > > > > > additional
> > > > > > emotional and mental load both for you and for maintainers who would
> > > > > > need to
> > > > > > do
> > > > > > something with these separate reports.
> > > > > 
> > > > > Our preference is to send patches as a single patch, not as patch
> > > > > series.
> > > > > 
> > > > > That said, people are sometimes sending series, and we don't ask them
> > > > > to resend, we process those series anyway.
> > > > > 
> > > > > As for separate bug reports, this is easily fixed by merging them.
> > > > 
> > > > Unfortunately merging bugreports does not fix that. The last patch I had
> > > > to
> > > > Emacs was sent with a cover letter and resulted in two reports: one for
> > > > the
> > > > cover letter and another for the patch itself. You may remember that it
> > > > resulted
> > > > in a confusion, because α) discussions happened on both threads, but
> > > > then a
> > > > new
> > > > patch version was only sent to one of them, so there other thread wasn't
> > > > notified that comments were addressed, and β) you may remember 3 months
> > > > after
> > > > the patch got accepted someone was asking the status. Which is because
> > > > one
> > > > of
> > > > the threads was closed saying that the patch is applied, but then the
> > > > other
> > > > thread into which a person was looking has no such comment.
> > > > 
> > > > > So I see no problem here.
> > > > 
> > > > This is psychology. Having a report per patch may not be a problem for
> > > > you,
> > > > but
> > > > when a contributor sends patches and gets into such situation, they do
> > > > not
> > > > know
> > > > it is okay. They will be frightened and frustrated, because it looks
> > > > like
> > > > something just went wrong. Such situation being okay needs at least be
> > > > mentioned
> > > > in "sending patches" section, and at best it should just work.
> > > 
> > > Like I said: we prefer a single patch for each changeset.  The
> > > problems presented by patch series are one reason.  And yet, we will
> > > never reject a patch series, even though it makes the process
> > > inconvenient and confusing.
> > > 
> > > I don't see what else do we need to argued about here.
> > 
> > Well, you see, the "sending patches" section has no mention that a series is
> > unwelcome. And Emacs is the unique project where a squashed patch with many
> > commits is preferred over a series.
> 
> There is "When you have all these pieces, bundle them up in a mail
> message and send it to the developers."¹ which to me implies to send a
> single email.
> 
> But it can easily get missed in the long text (datapoint for that: you
> missed it), that’s why I think the text shown to new contributors should
> get changed.

Well… yes, I did miss it. I see suggestions to have a change per patch (which
implies a series), but this sentence… Even now that I know the meaning, it reads
differently for me due to the context around it. It is not about the amount of
text on the page.

Well. Basically, the problem here is that this sentence just drowns among the
talk about sending "multiple patches" (e.g. 2nd paragraphs starts with "Every
patch…") and me knowing that in ML-managed projects you always send a series.

I also don't think there's a built-in way to send a series as a single message
via `git-send-email`. At least ChatGPT says there isn't, though I didn't exactly
study the man page to see if that's correct. And if a person has experience with
other ML-managed projects, they will likely send patches via `git-send-email`.

I think this phrase needs to be a separate point at the beginning, to emphasise
its significance.

But then, if this is true, this again makes contribution harder for people,
because this is different from every other ML-managed project, and creates
additional work to open your email client, and attach the patches.

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> Well, you see, the "sending patches" section has no mention that a series is
> unwelcome. And Emacs is the unique project where a squashed patch with many
> commits is preferred over a series.
>
> If series is indeed unwelcome, it would be better to reflect in "sending
> patches" section and provide copy-paste instructions for the people to quickly
> squash their commits before sending to ML (and I think something needs to be
> figured out about commit messages too in this case). Because when you are
> developing, it is easier to separate changes to distinct commits to make sure
> that if something break you know what exactly change was the reason to it. Even
> if these commits will have to be squashed later.

What's a ``squashed patch''?

Anyway, patches can only be generated by the VCS if the user has access
to the Emacs version control files, which is hardly given.  So prefering
ordinary diffs leads to more people being able to work on Emacs, not
less.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 20:10 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > Well, you see, the "sending patches" section has no mention that a series is
> > unwelcome. And Emacs is the unique project where a squashed patch with many
> > commits is preferred over a series.
> > 
> > If series is indeed unwelcome, it would be better to reflect in "sending
> > patches" section and provide copy-paste instructions for the people to
> > quickly
> > squash their commits before sending to ML (and I think something needs to be
> > figured out about commit messages too in this case). Because when you are
> > developing, it is easier to separate changes to distinct commits to make
> > sure
> > that if something break you know what exactly change was the reason to it.
> > Even
> > if these commits will have to be squashed later.
> 
> What's a ``squashed patch''?

When you have multiple patches squashed into one.

> Anyway, patches can only be generated by the VCS if the user has access
> to the Emacs version control files, which is hardly given.  So prefering
> ordinary diffs leads to more people being able to work on Emacs, not
> less.

How do you get latest upstream code without access to VCS?

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: Eli Zaretskii <eliz@gnu.org>, arne_bab@web.de, ams@gnu.org, 
> 	emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 15:28:01 +0300
> 
> How do you get latest upstream code without access to VCS?

You can request a snapshot tarball from Savannah.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 15:51 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: Eli Zaretskii <eliz@gnu.org>, arne_bab@web.de, ams@gnu.org, 
> >         emacs-devel@gnu.org
> > Date: Sun, 18 Jun 2023 15:28:01 +0300
> > 
> > How do you get latest upstream code without access to VCS?
> 
> You can request a snapshot tarball from Savannah.

Does it imply sending an email to Savannah admins? Because I'm browsing page
https://git.savannah.gnu.org/cgit/emacs.git/ and I don't see any link to a
tarball.

Either way, is it even a realistic usecase? When you develop you need to make
sure there's no conflicts. So every time you send patches, you rebase your local
version to make sure it's okay. And `rebase` is only possible with a VCS access.
So someone developing purely from a tarball seems to me like a case of a purely
academic interest.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: luangruo@yahoo.com, arne_bab@web.de, ams@gnu.org, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 16:02:10 +0300
> 
> On Sun, 2023-06-18 at 15:51 +0300, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > > Cc: Eli Zaretskii <eliz@gnu.org>, arne_bab@web.de, ams@gnu.org, 
> > >         emacs-devel@gnu.org
> > > Date: Sun, 18 Jun 2023 15:28:01 +0300
> > > 
> > > How do you get latest upstream code without access to VCS?
> > 
> > You can request a snapshot tarball from Savannah.
> 
> Does it imply sending an email to Savannah admins?

No.

> Because I'm browsing page
> https://git.savannah.gnu.org/cgit/emacs.git/ and I don't see any
> link to a tarball.

Do you really need one?

> Either way, is it even a realistic usecase?

No, not really.  Maybe in some emergency.

But one can have a release tarball as the base for preparing a patch,
or a tree moved from another system, or a system that's off-line, etc.
Which is why we also accept diffs, not just "git format-patch".

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> When you have multiple patches squashed into one.

When there are multiple orthogonal changes to Emacs, we prefer one
change be submitted at a time, so I'm not sure what the difference
between that and our preferred practice is.

> How do you get latest upstream code without access to VCS?

Changes to the latest Emacs release will generally apply to the
development source code as well.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 21:32 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > When you have multiple patches squashed into one.
> 
> When there are multiple orthogonal changes to Emacs, we prefer one
> change be submitted at a time, so I'm not sure what the difference
> between that and our preferred practice is.

Yeah, comparing docs and what Eli says, I think Eli didn't mean to say that a
patch series is not preferred in general, but rather that it's not preferred to
send a patch-series as it's usually done in ML-managed projects, i.e. via `git
send-email`. Apparently it is preferred to have the series attached and sent via
an email client.

So I think on that topic there's not much to discuss (besides of course the
according improvements to "Sending Patches" docs, but improvements are discussed
elsewhere in the thread).

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> Okay, so, here's an obvious one: a patch series sent to bug-gnu-emacs@gnu.org
> should not create separate bugreports for every patch.
>
> In ML-managed projects it is typical to send patches as a series, and when you
> doing that results in such surprising behaviour, it creates an additional
> emotional and mental load both for you and for maintainers who would need to do
> something with these separate reports.

What's a ``patch series''?

Typically, free software maintainers expect patches to be a single
context format diff, containing either edits to the appropriate
ChangeLog file(s), or with ChangeLog entries prepended.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 18:12 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > Okay, so, here's an obvious one: a patch series sent to
> > bug-gnu-emacs@gnu.org
> > should not create separate bugreports for every patch.
> > 
> > In ML-managed projects it is typical to send patches as a series, and when
> > you
> > doing that results in such surprising behaviour, it creates an additional
> > emotional and mental load both for you and for maintainers who would need to
> > do
> > something with these separate reports.
> 
> What's a ``patch series''?
> 
> Typically, free software maintainers expect patches to be a single
> context format diff, containing either edits to the appropriate
> ChangeLog file(s), or with ChangeLog entries prepended.

Ideally, each commit in the repository should contain minimal functional
changes. It allows for easier code review at the moment and for better figuring
out why some change was done later in the life of the project. Usually at this
point I refer people to this old article from kernel HID subsystem maintainer
and libinput creator http://who-t.blogspot.com/2009/12/on-commit-messages.html
Old — but gold! 😄

When project contributions are done via mailing list (such as kernel, gdb, gcc,
and in the past were also Xorg and Mesa), you usually turn a number of commits
to separate patches and send them. E.g. here's one example:
https://lore.kernel.org/dri-devel/20230612104658.1386996-1-tvrtko.ursulin@linux.intel.com/
it starts with a "zero patch" that is the title of the series, and then
individual patches follow.

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> Ideally, each commit in the repository should contain minimal functional
> changes. It allows for easier code review at the moment and for better figuring
> out why some change was done later in the life of the project. Usually at this
> point I refer people to this old article from kernel HID subsystem maintainer
> and libinput creator http://who-t.blogspot.com/2009/12/on-commit-messages.html
> Old — but gold! 😄

That's the purpose of ChangeLog, not the VCS.

> When project contributions are done via mailing list (such as kernel, gdb, gcc,
> and in the past were also Xorg and Mesa), you usually turn a number of commits
> to separate patches and send them. E.g. here's one example:
> https://lore.kernel.org/dri-devel/20230612104658.1386996-1-tvrtko.ursulin@linux.intel.com/
> it starts with a "zero patch" that is the title of the series, and then
> individual patches follow.

Mesa and Linux are hardly all the world, and that wasn't my experience
with GDB or GCC development.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 20:09 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > Ideally, each commit in the repository should contain minimal functional
> > changes. It allows for easier code review at the moment and for better
> > figuring
> > out why some change was done later in the life of the project. Usually at
> > this
> > point I refer people to this old article from kernel HID subsystem
> > maintainer
> > and libinput creator
> > http://who-t.blogspot.com/2009/12/on-commit-messages.html
> > Old — but gold! 😄
> 
> That's the purpose of ChangeLog, not the VCS.
> 
> > When project contributions are done via mailing list (such as kernel, gdb,
> > gcc,
> > and in the past were also Xorg and Mesa), you usually turn a number of
> > commits
> > to separate patches and send them. E.g. here's one example:
> > https://lore.kernel.org/dri-devel/20230612104658.1386996-1-tvrtko.ursulin@linux.intel.com/
> > it starts with a "zero patch" that is the title of the series, and then
> > individual patches follow.
> 
> Mesa and Linux are hardly all the world, and that wasn't my experience
> with GDB or GCC development.

I am not sure what you mean. Here's GCC ML with patches for the last month
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/thread.html You can see they
send series as well. Here's an arbitrary cover letter "zero patch" for a series
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618426.html

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Sun, 2023-06-18 at 20:09 +0800, Po Lu wrote:
>> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
>> 
>> > Ideally, each commit in the repository should contain minimal functional
>> > changes. It allows for easier code review at the moment and for better
>> > figuring
>> > out why some change was done later in the life of the project. Usually at
>> > this
>> > point I refer people to this old article from kernel HID subsystem
>> > maintainer
>> > and libinput creator
>> > http://who-t.blogspot.com/2009/12/on-commit-messages.html
>> > Old — but gold! 😄
>> 
>> That's the purpose of ChangeLog, not the VCS.
>> 
>> > When project contributions are done via mailing list (such as kernel, gdb,
>> > gcc,
>> > and in the past were also Xorg and Mesa), you usually turn a number of
>> > commits
>> > to separate patches and send them. E.g. here's one example:
>> > https://lore.kernel.org/dri-devel/20230612104658.1386996-1-tvrtko.ursulin@linux.intel.com/
>> > it starts with a "zero patch" that is the title of the series, and then
>> > individual patches follow.
>> 
>> Mesa and Linux are hardly all the world, and that wasn't my experience
>> with GDB or GCC development.
>
> I am not sure what you mean. Here's GCC ML with patches for the last month
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/thread.html You can see they
> send series as well. Here's an arbitrary cover letter "zero patch" for a series
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618426.html

Where is it said that GCC development prefers changes to be submitted in
this format?

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 21:29 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > On Sun, 2023-06-18 at 20:09 +0800, Po Lu wrote:
> > > Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> > > 
> > > > Ideally, each commit in the repository should contain minimal functional
> > > > changes. It allows for easier code review at the moment and for better
> > > > figuring
> > > > out why some change was done later in the life of the project. Usually
> > > > at
> > > > this
> > > > point I refer people to this old article from kernel HID subsystem
> > > > maintainer
> > > > and libinput creator
> > > > http://who-t.blogspot.com/2009/12/on-commit-messages.html
> > > > Old — but gold! 😄
> > > 
> > > That's the purpose of ChangeLog, not the VCS.
> > > 
> > > > When project contributions are done via mailing list (such as kernel,
> > > > gdb,
> > > > gcc,
> > > > and in the past were also Xorg and Mesa), you usually turn a number of
> > > > commits
> > > > to separate patches and send them. E.g. here's one example:
> > > > https://lore.kernel.org/dri-devel/20230612104658.1386996-1-tvrtko.ursulin@linux.intel.com/
> > > > it starts with a "zero patch" that is the title of the series, and then
> > > > individual patches follow.
> > > 
> > > Mesa and Linux are hardly all the world, and that wasn't my experience
> > > with GDB or GCC development.
> > 
> > I am not sure what you mean. Here's GCC ML with patches for the last month
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/thread.html You can see
> > they
> > send series as well. Here's an arbitrary cover letter "zero patch" for a
> > series
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618426.html
> 
> Where is it said that GCC development prefers changes to be submitted in
> this format?

Well, if you want to see the docs, then you can go here
https://gcc.gnu.org/contribute.html#patches and you'll see that it starts with
words "Every patch", which implies that you send multiple patches rather than
just one. "Multiple patches" is a series.

Then if you look a bit further, you'll see this paragraph:

> Series identifier
>
> The series identifier is optional and is only relevant if a number of patches
are needed in order to effect an overall change[…]

So yeah, here's an official text about patch series for GCC, as you wanted.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 20:09 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > Ideally, each commit in the repository should contain minimal functional
> > changes. It allows for easier code review at the moment and for better
> > figuring
> > out why some change was done later in the life of the project. Usually at
> > this
> > point I refer people to this old article from kernel HID subsystem
> > maintainer
> > and libinput creator
> > http://who-t.blogspot.com/2009/12/on-commit-messages.html
> > Old — but gold! 😄
> 
> That's the purpose of ChangeLog, not the VCS.

Sorry, I didn't reply this one.

Well. You can use Changelog instead of VCS. But what's the point of VCS then? 😊
I mean, if you have changes, you have to know what *are* these changes. I can
imagine some weird workflow where each commit adds a line to Changelog and then
commit messages itself will be empty… But such workflow will be awkward to say
the least.

Re: contributing to Emacs

[Po Lu]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> Well. You can use Changelog instead of VCS. But what's the point of
> VCS then?

So that you can easily restore earlier versions of a file, and prevent
files from being modified by two people at the same time through
locking?

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sun, 2023-06-18 at 21:30 +0800, Po Lu wrote:
> Konstantin Kharlamov <hi-angel@yandex.ru> writes:
> 
> > Well. You can use Changelog instead of VCS. But what's the point of
> > VCS then?
> 
> So that you can easily restore earlier versions of a file,

Alright, and then, how do you know which version to restore if you don't have
commit descriptions? 😊

Re: contributing to Emacs

[Sean Whitton]

Hello,

On Sun 18 Jun 2023 at 06:12PM +08, Po Lu wrote:

> Typically, free software maintainers expect patches to be a single
> context format diff, containing either edits to the appropriate
> ChangeLog file(s), or with ChangeLog entries prepended.

This is not the typical case anymore.  If a project is in git or
similar, then the expectation is that you send a patches series for all
but trivial changes.

-- 
Sean Whitton

Re: contributing to Emacs

[Po Lu]

Sean Whitton <spwhitton@spwhitton.name> writes:

> This is not the typical case anymore.  If a project is in git or
> similar, then the expectation is that you send a patches series for all
> but trivial changes.

Such expectations are based on the assumption that the user sending the
patch has access to the version control files associated with the
program being used, which is hardly guaranteed to be true.  I've never
seen Git repository files distributed together with a program.

Re: contributing to Emacs

[Sean Whitton]

Hello,

On Fri 23 Jun 2023 at 03:06PM +08, Po Lu wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> This is not the typical case anymore.  If a project is in git or
>> similar, then the expectation is that you send a patches series for all
>> but trivial changes.
>
> Such expectations are based on the assumption that the user sending the
> patch has access to the version control files associated with the
> program being used, which is hardly guaranteed to be true.  I've never
> seen Git repository files distributed together with a program.

Not guaranteed, but it's the default.

If a project is in git, and you want to contribute, you 'git clone'.

-- 
Sean Whitton

Re: contributing to Emacs

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Konstantin Kharlamov <hi-angel@yandex.ru>,  "Dr. Arne Babenhauserheide"
>  <arne_bab@web.de>,  "Alfred M. Szmidt" <ams@gnu.org>,  eliz@gnu.org,
>   emacs-devel@gnu.org
> Date: Fri, 23 Jun 2023 07:51:41 +0100
> 
> On Sun 18 Jun 2023 at 06:12PM +08, Po Lu wrote:
> 
> > Typically, free software maintainers expect patches to be a single
> > context format diff, containing either edits to the appropriate
> > ChangeLog file(s), or with ChangeLog entries prepended.
> 
> This is not the typical case anymore.  If a project is in git or
> similar, then the expectation is that you send a patches series for all
> but trivial changes.

Not in this project.  Here, the preference is the opposite one (but we
will gladly accept series as well).

Re: contributing to Emacs

[Sean Whitton]

Hello,

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

> Not in this project.  Here, the preference is the opposite one (but we
> will gladly accept series as well).

I know, I just wanted to update Po's impression of the wider ecosystem.

-- 
Sean Whitton

Re: contributing to Emacs

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: luangruo@yahoo.com,  hi-angel@yandex.ru,  arne_bab@web.de,  ams@gnu.org,
>  emacs-devel@gnu.org
> Date: Sat, 24 Jun 2023 08:21:25 +0100
> 
> On Fri 23 Jun 2023 at 10:17AM +03, Eli Zaretskii wrote:
> 
> > Not in this project.  Here, the preference is the opposite one (but we
> > will gladly accept series as well).
> 
> I know, I just wanted to update Po's impression of the wider ecosystem.
                                                               ^^^^^^^^^
(Expect a comment from RMS for using that word.)

The problem with that preference is that most contributors
misunderstand how to arrange the series correctly, and end up sending
series which require extra work, because the same places were modified
several times.  On top of that, the series doesn't really allow
applying only some of the patches, which is the main raison d'être of
the technique.

To correctly subdivide a large patch into a series, one must identify
changes in the changeset that are (a) independent, i.e., can be
applied without all the rest, and in any order; and (b) changes which
_make_sense_ as separate changes, so the project might consider
applying just them, even though the rest will be rejected.

What most people do instead is they provide a series where each patch
is a step towards the solution.  First, a patch with some refactoring,
then another patch with the first aspect of the solution, another
patch with the second aspect, etc.  Such series make no sense as a
series, because the patches are not really independent; instead, they
are _incremental_.  For example, it usually makes no sense to do the
refactoring if we aren't installing the changes which need it.
Moreover, this technique frequently leads to multiple patches touching
the same places several times, so when you review the first patch, you
are looking at code that will be modified later, and risk providing
comments that are irrelevant, because a later patch in the series
rewrites that code anyway, perhaps exactly in a way that you want to
tell the contributor to use.  Basically, the only sane method of
reviewing such "series" is to apply the entire series, then produce
the unified diffs from all of them, and than review those diffs
instead of the patch series.

Since the correct way of breaking patches into individual ones is hard
to explain, and requires good knowledge of the project's conventions
and practices to determine how to break the large patch, I find it
easier to ask contributors to not bother with series and submit a
single large patch.  IME, it's TRT in the majority of cases anyway,
especially with contributions that provide some minor change or fix,
and it definitely makes patch review much more convenient and easy
than the opposite preference.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sat, 2023-06-24 at 10:43 +0300, Eli Zaretskii wrote:
> 
> What most people do instead is they provide a series where each patch
> is a step towards the solution.  First, a patch with some refactoring,
> then another patch with the first aspect of the solution, another
> patch with the second aspect, etc.  Such series make no sense as a
> series, because the patches are not really independent; instead, they
> are _incremental_.  For example, it usually makes no sense to do the
> refactoring if we aren't installing the changes which need it.

I might be misunderstanding something, but as someone who regularly posts such
"incremental changes" at my work, I tend to disagree that such refactoring will
not be needed if the final change not applied.

The point of such refactoring is improving existing code. Like, separating
larger functions to smaller one, encapsulating logic and reducing variables
scope, constifying stuff… I agree that the driving force for these changes is
making some final change that adds some new feature or something… However, even
if the final feature does not make it through, the changes per se make code
easier to maintain and review. I even had multiple occasions at work where I was
making such incremental changes, but the final point I was doing them for was
never reached for one reason or another. But we still applied the refactoring,
because it's an improvement nonetheless.

> Moreover, this technique frequently leads to multiple patches touching
> the same places several times, so when you review the first patch, you
> are looking at code that will be modified later, and risk providing
> comments that are irrelevant, because a later patch in the series
> rewrites that code anyway, perhaps exactly in a way that you want to
> tell the contributor to use.

Actually, this is exactly how review works. It *does not* matter if later code
rewrote the same place again. If you found a problem in *current* commit/patch,
that means that exactly *this* commit/patch needs to be fixed.

That α) simplifies review, and β) makes sure that if later commit gets reverted
at some point, the code that is left would still be valid.

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: luangruo@yahoo.com, arne_bab@web.de, ams@gnu.org, emacs-devel@gnu.org
> Date: Sat, 24 Jun 2023 15:36:20 +0300
> 
> On Sat, 2023-06-24 at 10:43 +0300, Eli Zaretskii wrote:
> > 
> > What most people do instead is they provide a series where each patch
> > is a step towards the solution.  First, a patch with some refactoring,
> > then another patch with the first aspect of the solution, another
> > patch with the second aspect, etc.  Such series make no sense as a
> > series, because the patches are not really independent; instead, they
> > are _incremental_.  For example, it usually makes no sense to do the
> > refactoring if we aren't installing the changes which need it.
> 
> I might be misunderstanding something, but as someone who regularly posts such
> "incremental changes" at my work, I tend to disagree that such refactoring will
> not be needed if the final change not applied.

You might disagree, but such considerations and decisions are the
prerogative of the project maintainers, not of the contributors.  In
Emacs, we don't like code churn unless it has a purpose, and
refactoring by itself doesn't justify the downsides of making the code
less familiar to those who read and audit it very frequently, and need
to be able to find the relevant parts as fast as possible.  Keep in
mind that this is an old project with code written by excellent
programmers (I exclude myself from that group, obviously), and the
code is generally in very good shape.  Thus, refactoring is not really
an urgent need, like it might be in an average project out there.

Again, you might disagree, but this is not your call.  My point was
precisely that since it is not the call of the contributors, they
cannot be expected to make those decisions on our behalf, and are
therefore better off not dividing the patches into several individual
ones.

> > Moreover, this technique frequently leads to multiple patches touching
> > the same places several times, so when you review the first patch, you
> > are looking at code that will be modified later, and risk providing
> > comments that are irrelevant, because a later patch in the series
> > rewrites that code anyway, perhaps exactly in a way that you want to
> > tell the contributor to use.
> 
> Actually, this is exactly how review works. It *does not* matter if later code
> rewrote the same place again. If you found a problem in *current* commit/patch,
> that means that exactly *this* commit/patch needs to be fixed.

I think you misunderstood what I tried to explain, because you are
actually saying that wasting effort on reviewing of and commenting on
code that will be changed or reverted by a further commit is a Good
Thing.

But even if you did understand my point, are you really going to tell
me how to review patches?  Don't you think it's my decision, and not
yours?  In the project of which you are the maintainer, you can define
the procedures and the preferences as you see fit (and I will follow
if I need to contribute, as I do, for example, with GDB, where they do
want patch series), but you cannot force me use the procedures that
you find convenient and natural in a project where I need to review so
many patches each day.

Bottom line: I explained the rationale so that people could understand
the preferences better, and in particular realize that they aren't
arbitrary.  I hope that better understanding will make it easier to
respect the preferences, even if some don't agree with them.

Re: contributing to Emacs

[Konstantin Kharlamov]

On Sat, 2023-06-24 at 17:44 +0300, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: luangruo@yahoo.com, arne_bab@web.de, ams@gnu.org, emacs-devel@gnu.org
> > Date: Sat, 24 Jun 2023 15:36:20 +0300
> > 
> > On Sat, 2023-06-24 at 10:43 +0300, Eli Zaretskii wrote:
> > > 
> > > What most people do instead is they provide a series where each patch
> > > is a step towards the solution.  First, a patch with some refactoring,
> > > then another patch with the first aspect of the solution, another
> > > patch with the second aspect, etc.  Such series make no sense as a
> > > series, because the patches are not really independent; instead, they
> > > are _incremental_.  For example, it usually makes no sense to do the
> > > refactoring if we aren't installing the changes which need it.
> > 
> > I might be misunderstanding something, but as someone who regularly posts
> > such
> > "incremental changes" at my work, I tend to disagree that such refactoring
> > will
> > not be needed if the final change not applied.
> 
> You might disagree, but such considerations and decisions are the
> prerogative of the project maintainers, not of the contributors.  In
> Emacs, we don't like code churn unless it has a purpose, and
> refactoring by itself doesn't justify the downsides of making the code
> less familiar to those who read and audit it very frequently, and need
> to be able to find the relevant parts as fast as possible.  Keep in
> mind that this is an old project with code written by excellent
> programmers (I exclude myself from that group, obviously), and the
> code is generally in very good shape.  Thus, refactoring is not really
> an urgent need, like it might be in an average project out there.
> 
> Again, you might disagree, but this is not your call.  My point was
> precisely that since it is not the call of the contributors, they
> cannot be expected to make those decisions on our behalf, and are
> therefore better off not dividing the patches into several individual
> ones.
> 
> > > Moreover, this technique frequently leads to multiple patches touching
> > > the same places several times, so when you review the first patch, you
> > > are looking at code that will be modified later, and risk providing
> > > comments that are irrelevant, because a later patch in the series
> > > rewrites that code anyway, perhaps exactly in a way that you want to
> > > tell the contributor to use.
> > 
> > Actually, this is exactly how review works. It *does not* matter if later
> > code
> > rewrote the same place again. If you found a problem in *current*
> > commit/patch,
> > that means that exactly *this* commit/patch needs to be fixed.
> 
> I think you misunderstood what I tried to explain, because you are
> actually saying that wasting effort on reviewing of and commenting on
> code that will be changed or reverted by a further commit is a Good
> Thing.

I did not say that.

> But even if you did understand my point, are you really going to tell
> me how to review patches?  Don't you think it's my decision, and not
> yours?  In the project of which you are the maintainer, you can define
> the procedures and the preferences as you see fit (and I will follow
> if I need to contribute, as I do, for example, with GDB, where they do
> want patch series), but you cannot force me use the procedures that
> you find convenient and natural in a project where I need to review so
> many patches each day.

Neither I said how *you* should review patches. You seem to be out of context:
you previous email was a reply to Sean's one-sentence email that they is talking
about the wider ecosystem. And your next reply was not in Emacs-only context,
but instead you were explaining problems with the wider approach. And so my
explanation about code review practices is also in general.

I did not expect you would start applying the practices used in "the wider
ecosystem", because you clearly seem to be fine with how it works for you. My
reply was just an explanation of why other projects do what they are doing.

(also, due to this misunderstanding I opted not to elaborate further on the
other text above, because you seem to be taking this a bit personally)

Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: spwhitton@spwhitton.name, luangruo@yahoo.com, arne_bab@web.de,
>  ams@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 24 Jun 2023 19:17:34 +0300
> 
> > But even if you did understand my point, are you really going to tell
> > me how to review patches?  Don't you think it's my decision, and not
> > yours?  In the project of which you are the maintainer, you can define
> > the procedures and the preferences as you see fit (and I will follow
> > if I need to contribute, as I do, for example, with GDB, where they do
> > want patch series), but you cannot force me use the procedures that
> > you find convenient and natural in a project where I need to review so
> > many patches each day.
> 
> Neither I said how *you* should review patches. You seem to be out of context:
> you previous email was a reply to Sean's one-sentence email that they is talking
> about the wider ecosystem. And your next reply was not in Emacs-only context,
> but instead you were explaining problems with the wider approach. And so my
> explanation about code review practices is also in general.

Then you did misunderstand, and if my wording somehow caused that, I
apologize.  I described the rationale for the preference of this
project to have contributions submitted as a single patch.

Re: contributing to Emacs

[Sean Whitton]

Hello,

On Sat 24 Jun 2023 at 10:43AM +03, Eli Zaretskii wrote:

> The problem with that preference is that most contributors
> misunderstand how to arrange the series correctly, and end up sending
> series which require extra work, because the same places were modified
> several times.  On top of that, the series doesn't really allow
> applying only some of the patches, which is the main raison d'être of
> the technique.
>
> To correctly subdivide a large patch into a series, one must identify
> changes in the changeset that are (a) independent, i.e., can be
> applied without all the rest, and in any order; and (b) changes which
> _make_sense_ as separate changes, so the project might consider
> applying just them, even though the rest will be rejected.
>
> What most people do instead is they provide a series where each patch
> is a step towards the solution.  First, a patch with some refactoring,
> then another patch with the first aspect of the solution, another
> patch with the second aspect, etc.  Such series make no sense as a
> series, because the patches are not really independent; instead, they
> are _incremental_.  For example, it usually makes no sense to do the
> refactoring if we aren't installing the changes which need it.
> Moreover, this technique frequently leads to multiple patches touching
> the same places several times, so when you review the first patch, you
> are looking at code that will be modified later, and risk providing
> comments that are irrelevant, because a later patch in the series
> rewrites that code anyway, perhaps exactly in a way that you want to
> tell the contributor to use.  Basically, the only sane method of
> reviewing such "series" is to apply the entire series, then produce
> the unified diffs from all of them, and than review those diffs
> instead of the patch series.
>
> Since the correct way of breaking patches into individual ones is hard
> to explain, and requires good knowledge of the project's conventions
> and practices to determine how to break the large patch, I find it
> easier to ask contributors to not bother with series and submit a
> single large patch.  IME, it's TRT in the majority of cases anyway,
> especially with contributions that provide some minor change or fix,
> and it definitely makes patch review much more convenient and easy
> than the opposite preference.

This all makes sense.  Separating changes usefully is a skill that
people have to acquire.  And it's reasonable to conclude from experience
that enough people get it wrong that it is better to ask people not to
do it at all.

I do disagree that the main reason for separating them is to allow
applying only some of them.  I think making review easier, and improving
the level of detail in the VCS history, are more singificant reasons.

-- 
Sean Whitton

Re: contributing to Emacs

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org, luangruo@yahoo.com,
>  emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 10:59:42 +0200
> 
> > And then if that's not enough, from what I've seen maintainers also
> > expect you to have read CONTRIBUTE section, which is absolutely large,
> > much bigger than "Sending patches". (to be fair, if you are a new
> > contributor, you won't know it exists because "Sending patches" has no
> > mention of it).
> 
> Same here. I see quite a bit of explanation in the CONTRIBUTE file that
> makes that longer than the information a contributor really has to know.

People keep asking for more and more details to be described there, so
what you expect doesn't stand the test of time and user expectations.

It is clear that you personally may not need everything there, but
CONTRIBUTE is not for you and me, or others like we.

> For a github project (to name the elefant in the room) you also have to
> know the URL, but there it feels easier. Can we make that easier in the
> existing infrastructure?

Type "gnu emacs" into an Internet search window.  The first result
will likely to be the Emacs site.  Click on "Documentation & Support"
and read there.  How hard is that?

Are we perhaps making a mountain out of a proverbial molehill?

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> Cc: "Alfred M. Szmidt" <ams@gnu.org>, eliz@gnu.org, luangruo@yahoo.com,
>>  emacs-devel@gnu.org
>> Date: Sun, 18 Jun 2023 10:59:42 +0200
>> 
>> > And then if that's not enough, from what I've seen maintainers also
>> > expect you to have read CONTRIBUTE section, which is absolutely large,
>> > much bigger than "Sending patches". (to be fair, if you are a new
>> > contributor, you won't know it exists because "Sending patches" has no
>> > mention of it).
>> 
>> Same here. I see quite a bit of explanation in the CONTRIBUTE file that
>> makes that longer than the information a contributor really has to know.
>
> People keep asking for more and more details to be described there, so
> what you expect doesn't stand the test of time and user expectations.

What would you do if CONTRIBUTING were a user interface? Would you
include every idea someone has?

> It is clear that you personally may not need everything there, but
> CONTRIBUTE is not for you and me, or others like we.

For whom *is* CONTRIBUTE?

>> For a github project (to name the elefant in the room) you also have to
>> know the URL, but there it feels easier. Can we make that easier in the
>> existing infrastructure?
>
> Type "gnu emacs" into an Internet search window.  The first result
> will likely to be the Emacs site.  Click on "Documentation & Support"
> and read there.  How hard is that?
>
> Are we perhaps making a mountain out of a proverbial molehill?

I don’t think so. I consider this a writing problem. But do see my other
email with a concrete description and proposal how to package the
information needed for contributing in a way that makes it much easier
to take in.

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: contributing to Emacs

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: hi-angel@yandex.ru, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 12:19:45 +0200
> 
> > People keep asking for more and more details to be described there, so
> > what you expect doesn't stand the test of time and user expectations.
> 
> What would you do if CONTRIBUTING were a user interface? Would you
> include every idea someone has?

Who said anything about including "every idea"?  We try very hard to
include there only what's really necessary and non-obvious, you can
search the archives for discussions about CONTRIBUTE to see it for
yourself.  But still, the instructions grow over time, because people
ask questions about the details, and enough people here consider some
of those details worthy to be included.

> > It is clear that you personally may not need everything there, but
> > CONTRIBUTE is not for you and me, or others like we.
> 
> For whom *is* CONTRIBUTE?

For people who only start contributing and need to study our
conventions and requirements.  If they bother reading the file, of
course.  (If they don't, we will inform them about the relevant
conventions as part of the patch review process.)

Re: contributing to Emacs

[Dr. Arne Babenhauserheide]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> Cc: hi-angel@yandex.ru, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
>> Date: Sun, 18 Jun 2023 12:19:45 +0200
>> 
>> > People keep asking for more and more details to be described there, so
>> > what you expect doesn't stand the test of time and user expectations.
>> 
>> What would you do if CONTRIBUTING were a user interface? Would you
>> include every idea someone has?
>
> Who said anything about including "every idea"?

Sorry about that, it was too careless wording. I meant that 

> We try very hard to
> include there only what's really necessary and non-obvious, you can
> search the archives for discussions about CONTRIBUTE to see it for
> yourself.  But still, the instructions grow over time, because people
> ask questions about the details, and enough people here consider some
> of those details worthy to be included.

With instructions it’s similar as with code: At some point it’s
necessary to refactor, because incremental changes resulted in something
that’s harder to work with than necessary.

There are explanations *why* something is as it is — both in
CONTRIBUTING and in Sending Patches. These are not necessary for someone
wanting to submit a patch, but they are necessary for someone wanting to
improve the instructions or wondering "why that rule?" — which at least
to me is a common question when I see a list of rules.

⇒ not for first contact, but useful at the second or third patch.

>> > It is clear that you personally may not need everything there, but
>> > CONTRIBUTE is not for you and me, or others like we.
>> 
>> For whom *is* CONTRIBUTE?
>
> For people who only start contributing and need to study our
> conventions and requirements.  If they bother reading the file, of
> course.  (If they don't, we will inform them about the relevant
> conventions as part of the patch review process.)

This informing about convention causes load on the maintainers, so I
think we should increase the number of people who read instructions and
get enough information from them that they need not be informed about
convention ⇒ The shorter version I wrote is intended to reduce that load.

At this point I’d say that this may be better as a bug report for the
website. Where can I send these?

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: contributing to Emacs

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: hi-angel@yandex.ru, ams@gnu.org, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 18 Jun 2023 12:50:28 +0200
> 
> At this point I’d say that this may be better as a bug report for the
> website. Where can I send these?

To the same places where any other bug about Emacs is submitted:
bug-gnu-emacs@gnu.org.

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

[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

[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]

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

[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

[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:

> 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

[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:

> 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

[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: 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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Ó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

[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

[Ó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

[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

[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

[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

[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

[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

[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

[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]

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]

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

[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

[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

[Bryce]

I use Unexpected Keyboard.

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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]

> 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

[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]

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

[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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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]

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

[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: 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

[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

[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

[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

[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

[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

[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

[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]

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

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

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

[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

[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

[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

[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

[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

[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

Contributing to Emacs

[João Paulo Labegalini de Carvalho]

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

Hi,

I started using Emacs about 2 months ago. Now that I am comfortable with
customizing Emacs, getting help, and Elisp, I would like to contribute to
the project.

 I was looking at the file etc/TODO in the repo, and some items there
caught my attention. For example, under 'Important Features'  I found 'Add
an "indirect goto" byte-code'. Is this still a desired feature or is it not
required due to recent efforts towards native compilation? (In the negative
case, please feel free to suggest another item for me to work on)

If it is still desired I would like to work on it and would appreciate
guidance. After taking a look at lisp/emacs-lisp/bytecomp.el,it seems that
forms such as

 (let ((foo (lambda (x) bar)))
     (dosomething
       (funcall foo toto)
       (blabla (funcall foo titi))))

are compiled by calling byte-compile-let. Before generating the binding for
foo, #'(lambda (x) bar) is compiled by calling
byte-compile-push-binding-init, which in turn compiles the lambda to
bytecode and pushes it to the stack.

So to make it more concrete for my sake, I wrote the following form

(let ((foo (lambda (x) (- x 1))))
  (* (funcall foo 2)
     (- (funcall foo 3) 2)))

and with disassemble inspected the generated bytecode by Emacs 28.1

byte code:
  args: nil
0       constant  <compiled-function>
      args: (x)
    0       varref    x
    1       sub1
    2       return

1       dup
2       varbind   foo
3       constant  2
4       call      1
5       varref    foo
6       constant  3
7       call      1
8       constant  2
9       diff
10      mult
11      unbind    1
12      return

As far as I understood,  the idea of the "indirect goto" here is to
eliminate the calls on lines 4 and 7 and replace them with an indirect
goto. And as per the TODO entry, the return in line 2 of the compiled
lambda would also need to be replaced by a jump back.

So here is where I am a bit lost. Currently, the compiled lambda bytecode
lives in the *constant vector* and a reference(?) to it is pushed into
the *evaluation
stack* in line 0 (constant <compiled-function>). Thus, for the indirect
goto idea to work, the bytecode of the lambda would need to be part of the
bytecode of the let's body**. That way, a computed branch can branch into
the lambdas code and it is possible to branch out of it when returning.

Aside from guidance on implementing this, I would appreciate any pointers
on how to adequately test it.

Regards,
-- 
João Paulo L. de Carvalho
Ph.D Computer Science |  IC-UNICAMP | Campinas , SP - Brazil
Postdoctoral Research Fellow | University of Alberta | Edmonton, AB - Canada
joao.carvalho@ic.unicamp.br
joao.carvalho@ualberta.ca

** Forgive me for the lack/miss use of terminology.

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

Re: Contributing to Emacs

[Mattias Engdegård]

7 sep. 2022 kl. 22.01 skrev João Paulo Labegalini de Carvalho <jaopaulolc@gmail.com>:

>  I was looking at the file etc/TODO in the repo, and some items there caught my attention. For example, under 'Important Features'  I found 'Add an "indirect goto" byte-code'. Is this still a desired feature

That file is a bit misleading. Adding a byte-code is easy; modifying the compiler is more work, and so is deciding what byte-codes to add and what they should look like.

I'd even go as far as saying that etc/TODO isn't necessarily a catalog of where new contributors should best direct their efforts.

Why don't you think of something that you personally would like Emacs to do that it currently does not, or doesn't do well enough? Or fix something that annoys you daily in your work? Such issues are never in short supply, and your time addressing them would be well-spent.

Re: Contributing to Emacs

[João Paulo Labegalini de Carvalho]

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

> That file is a bit misleading. Adding a byte-code is easy; modifying the
> compiler is more work, and so is deciding what byte-codes to add and what
> they should look like.
>
> I'd even go as far as saying that etc/TODO isn't necessarily a catalog of
> where new contributors should best direct their efforts.
>

That was what I suspected. I noticed that some items in the etc/TODO file
seem to have already been (partially) resolved (e.g. Convert modes that use
view-mode to be derived from special-mode instead).

I can see that adding a byte-code is the easy part. Modifying the compiler
is definitely a more challenging part, specially to decide when the new
byte-code should be generated.

Why don't you think of something that you personally would like Emacs to do
> that it currently does not, or doesn't do well enough? Or fix something
> that annoys you daily in your work? Such issues are never in short supply,
> and your time addressing them would be well-spent.
>

That is a very good suggestion. Currently I don't have anything that annoys
me,  the annoyances I had so far were easy to fix with existing features
and were due to my lack of Emacs knowledge.

The reason I turned to the new byte-code item was to exploit it as a way to
learn more about the inner workings of Emacs.  I guess that I did already
learn something with my modest investigation.

I will keep your suggestion in mind, and if I ever find something that
could be improved/done differently I will reach back out.

-- 
João Paulo L. de Carvalho
Ph.D Computer Science |  IC-UNICAMP | Campinas , SP - Brazil
Postdoctoral Research Fellow | University of Alberta | Edmonton, AB - Canada
joao.carvalho@ic.unicamp.br
joao.carvalho@ualberta.ca

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

Re: Contributing to Emacs

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Wed, 7 Sep 2022 22:32:40 +0200
> Cc: emacs-devel@gnu.org
> 
> I'd even go as far as saying that etc/TODO isn't necessarily a catalog of where new contributors should best direct their efforts.

It's supposed to be.  If you know of entries that shouldn't be there,
and entries that should but aren't, please tell.  We do want to have
this file as a useful reference of developmental tasks that are of
interest to us.

> Why don't you think of something that you personally would like Emacs to do that it currently does not, or doesn't do well enough? Or fix something that annoys you daily in your work? Such issues are never in short supply, and your time addressing them would be well-spent.

How can new contributors find such issues, when they don't know enough
about Emacs, its deficiencies, its development directions, things that
were tried and failed, etc.?  etc/TODO is supposed to guide them.

Re: Contributing to Emacs

[Christopher Dimech]

[-- Attachment #1: Type: text/html, Size: 6347 bytes --]

Re: Contributing to Emacs

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 7 Sep 2022 23:33:17 +0200
> Sensitivity: Normal
> 
> 1.  Text Scaling
> ****************
>  
> a.  When resizing windows and frames, scale the font size of text accordingly.
> b.  When scaling the font size of text, scale the windows and frames accordingly.
> c.  Scale the font size of text to fit the window or frame size.

These are basically the same feature, and it already exists on the
master branch.

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Thursday, September 08, 2022 at 5:40 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: emacs-devel@gnu.org
> > Date: Wed, 7 Sep 2022 23:33:17 +0200
> > Sensitivity: Normal
> >
> > 1.  Text Scaling
> > ****************
> >
> > a.  When resizing windows and frames, scale the font size of text accordingly.
> > b.  When scaling the font size of text, scale the windows and frames accordingly.
> > c.  Scale the font size of text to fit the window or frame size.
>
> These are basically the same feature, and it already exists on the
> master branch.

Will test it and report back.  I knew there were some attempt.  Although
some of the functionality was there, it did not work well in particular
circumstances.

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Thursday, September 08, 2022 at 5:40 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: emacs-devel@gnu.org
> > Date: Wed, 7 Sep 2022 23:33:17 +0200
> > Sensitivity: Normal
> >
> > 1.  Text Scaling
> > ****************
> >
> > a.  When resizing windows and frames, scale the font size of text accordingly.
> > b.  When scaling the font size of text, scale the windows and frames accordingly.
> > c.  Scale the font size of text to fit the window or frame size.
>
> These are basically the same feature, and it already exists on the
> master branch.

@Eli, Have read INSTALL file and it should include the ./autogen.sh
tool as step "1b".

Re: Contributing to Emacs

[Robert Pluim]

>>>>> On Thu, 8 Sep 2022 13:57:10 +0200, Christopher Dimech <dimech@gmx.com> said:

    >> Sent: Thursday, September 08, 2022 at 5:40 PM
    >> From: "Eli Zaretskii" <eliz@gnu.org>
    >> To: "Christopher Dimech" <dimech@gmx.com>
    >> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
    >> Subject: Re: Contributing to Emacs
    >> 
    >> > From: Christopher Dimech <dimech@gmx.com>
    >> > Cc: emacs-devel@gnu.org
    >> > Date: Wed, 7 Sep 2022 23:33:17 +0200
    >> > Sensitivity: Normal
    >> >
    >> > 1.  Text Scaling
    >> > ****************
    >> >
    >> > a.  When resizing windows and frames, scale the font size of text accordingly.
    >> > b.  When scaling the font size of text, scale the windows and frames accordingly.
    >> > c.  Scale the font size of text to fit the window or frame size.
    >> 
    >> These are basically the same feature, and it already exists on the
    >> master branch.

    Christopher> @Eli, Have read INSTALL file and it should include the ./autogen.sh
    Christopher> tool as step "1b".

Only when youʼre building from a git checkout, in which case you
should read INSTALL.REPO, which has that step.

Robert
-- 

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Friday, September 09, 2022 at 12:27 AM
> From: "Robert Pluim" <rpluim@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> >>>>> On Thu, 8 Sep 2022 13:57:10 +0200, Christopher Dimech <dimech@gmx.com> said:
> 
>     >> Sent: Thursday, September 08, 2022 at 5:40 PM
>     >> From: "Eli Zaretskii" <eliz@gnu.org>
>     >> To: "Christopher Dimech" <dimech@gmx.com>
>     >> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
>     >> Subject: Re: Contributing to Emacs
>     >> 
>     >> > From: Christopher Dimech <dimech@gmx.com>
>     >> > Cc: emacs-devel@gnu.org
>     >> > Date: Wed, 7 Sep 2022 23:33:17 +0200
>     >> > Sensitivity: Normal
>     >> >
>     >> > 1.  Text Scaling
>     >> > ****************
>     >> >
>     >> > a.  When resizing windows and frames, scale the font size of text accordingly.
>     >> > b.  When scaling the font size of text, scale the windows and frames accordingly.
>     >> > c.  Scale the font size of text to fit the window or frame size.
>     >> 
>     >> These are basically the same feature, and it already exists on the
>     >> master branch.
> 
>     Christopher> @Eli, Have read INSTALL file and it should include the ./autogen.sh
>     Christopher> tool as step "1b".
> 
> Only when youʼre building from a git checkout, in which case you
> should read INSTALL.REPO, which has that step.
> 
> Robert
 
@Robert.  I would then suggest to include what INSTALL and INSTALL.REPO
are meant for immediately at the beginning of README.

Re: Contributing to Emacs

[Robert Pluim]

>>>>> On Thu, 8 Sep 2022 15:11:29 +0200, Christopher Dimech <dimech@gmx.com> said:

    >> Only when youʼre building from a git checkout, in which case you
    >> should read INSTALL.REPO, which has that step.
    >> 
    >> Robert
 
    Christopher> @Robert.  I would then suggest to include what INSTALL and INSTALL.REPO
    Christopher> are meant for immediately at the beginning of README.

Line 8 of README:

    The file INSTALL in this directory says how to build and install GNU
    Emacs on various systems, once you have unpacked or checked out the
    entire Emacs file tree.

although perhaps that 'checked out' bit should be removed or refer to
INSTALL.REPO.

Robert
-- 

Re: Contributing to Emacs

[Óscar Fuentes]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 8 Sep 2022 15:11:29 +0200, Christopher Dimech <dimech@gmx.com> said:
>
>     >> Only when youʼre building from a git checkout, in which case you
>     >> should read INSTALL.REPO, which has that step.
>     >> 
>     >> Robert
>  
>     Christopher> @Robert.  I would then suggest to include what INSTALL and INSTALL.REPO
>     Christopher> are meant for immediately at the beginning of README.
>
> Line 8 of README:
>
>     The file INSTALL in this directory says how to build and install GNU
>     Emacs on various systems, once you have unpacked or checked out the
>     entire Emacs file tree.
>
> although perhaps that 'checked out' bit should be removed or refer to
> INSTALL.REPO.

You are supposed to use the instructions on INSTALL for building an
Emacs checkout too. Among those instructions, at the beginning, it is
said that you must start with the steps written in INSTALL.REPO in case
you are building a checkout.

It looks fine to me.

Re: Contributing to Emacs

[Robert Pluim]

>>>>> On Thu, 08 Sep 2022 15:38:40 +0200, Óscar Fuentes <ofv@wanadoo.es> said:

    Óscar> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Thu, 8 Sep 2022 15:11:29 +0200, Christopher Dimech <dimech@gmx.com> said:
    >> 
    >> >> Only when youʼre building from a git checkout, in which case you
    >> >> should read INSTALL.REPO, which has that step.
    >> >> 
    >> >> Robert
    >> 
    Christopher> @Robert.  I would then suggest to include what INSTALL and INSTALL.REPO
    Christopher> are meant for immediately at the beginning of README.
    >> 
    >> Line 8 of README:
    >> 
    >> The file INSTALL in this directory says how to build and install GNU
    >> Emacs on various systems, once you have unpacked or checked out the
    >> entire Emacs file tree.
    >> 
    >> although perhaps that 'checked out' bit should be removed or refer to
    >> INSTALL.REPO.

    Óscar> You are supposed to use the instructions on INSTALL for building an
    Óscar> Emacs checkout too. Among those instructions, at the beginning, it is
    Óscar> said that you must start with the steps written in INSTALL.REPO in case
    Óscar> you are building a checkout.

    Óscar> It looks fine to me.

Itʼs easy to miss the referral to INSTALL.REPO at the start of
INSTALL. Would it do any harm to refer to it from README as well?

Robert
-- 

Re: Contributing to Emacs

[Óscar Fuentes]

Robert Pluim <rpluim@gmail.com> writes:

>     Óscar> You are supposed to use the instructions on INSTALL for building an
>     Óscar> Emacs checkout too. Among those instructions, at the beginning, it is
>     Óscar> said that you must start with the steps written in INSTALL.REPO in case
>     Óscar> you are building a checkout.
>
>     Óscar> It looks fine to me.
>
> Itʼs easy to miss the referral to INSTALL.REPO at the start of
> INSTALL. Would it do any harm to refer to it from README as well?

I don't think that it is easier to miss the INSTALL.REPO mention than
any other part of INSTALL, so mentioning it on README seems like
unnecessarily complicating things, moreover when you are supposed to go
to INSTALL.REPO from INSTALL, not from README.

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Friday, September 09, 2022 at 1:25 AM
> From: "Robert Pluim" <rpluim@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> >>>>> On Thu, 8 Sep 2022 15:11:29 +0200, Christopher Dimech <dimech@gmx.com> said:
> 
>     >> Only when youʼre building from a git checkout, in which case you
>     >> should read INSTALL.REPO, which has that step.
>     >> 
>     >> Robert
>  
>     Christopher> @Robert.  I would then suggest to include what INSTALL and INSTALL.REPO
>     Christopher> are meant for immediately at the beginning of README.
> 
> Line 8 of README:
> 
>     The file INSTALL in this directory says how to build and install GNU
>     Emacs on various systems, once you have unpacked or checked out the
>     entire Emacs file tree.
> 
> although perhaps that 'checked out' bit should be removed or refer to
> INSTALL.REPO.
> 
> Robert

I would remove it as you suggest.

Had thought about having something like this, easy and simple.  

The file INSTALL in this directory says how to build and install GNU
Emacs on various systems, once you have downloaded an Emacs Release
file tree.

The file INSTALL.REPO in this directory says how to build and install GNU
Emacs after downloading the development sources hosted on Savannah.

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Thursday, September 08, 2022 at 5:40 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: emacs-devel@gnu.org
> > Date: Wed, 7 Sep 2022 23:33:17 +0200
> > Sensitivity: Normal
> >
> > 1.  Text Scaling
> > ****************
> >
> > a.  When resizing windows and frames, scale the font size of text accordingly.
> > b.  When scaling the font size of text, scale the windows and frames accordingly.
> > c.  Scale the font size of text to fit the window or frame size.
>
> These are basically the same feature, and it already exists on the
> master branch.

@Eli, a pleasant thing would be to mention the commands for window and frame
related scaling in the documentation of "text-scale-increase" and "text-scale-decrease".

Re: Contributing to Emacs

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> Date: Thu, 8 Sep 2022 14:12:01 +0200
> 
> @Eli, a pleasant thing would be to mention the commands for window and frame
> related scaling in the documentation of "text-scale-increase" and "text-scale-decrease".

They are mentioned in the doc string of text-scale-adjust, which is
the preferred user interface for this.

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Friday, September 09, 2022 at 1:47 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> > Date: Thu, 8 Sep 2022 14:12:01 +0200
> > 
> > @Eli, a pleasant thing would be to mention the commands for window and frame
> > related scaling in the documentation of "text-scale-increase" and "text-scale-decrease".
> 
> They are mentioned in the doc string of text-scale-adjust, which is
> the preferred user interface for this.

What I get is the following.  I do not see any reference for the functionality
that scales text in response to window resizing.

--------

text-scale-adjust is an autoloaded interactive byte-compiled Lisp
function in ‘face-remap.el’.

It is bound to C-x C-0, C-x C-=, C-x C--, C-x C-+.

(text-scale-adjust INC)

Adjust the height of the default face by INC.

INC may be passed as a numeric prefix argument.

The actual adjustment made depends on the final component of the
keybinding used to invoke the command, with all modifiers removed:

   +, =   Increase the height of the default face by one step
   -      Decrease the height of the default face by one step
   0      Reset the height of the default face to the global default

After adjusting, continue to read input events and further adjust
the face height as long as the input event read
(with all modifiers removed) is one of the above characters.

Each step scales the height of the default face by the variable
‘text-scale-mode-step’ (a negative number of steps decreases the
height by the same amount).  As a special case, an argument of 0
will remove any scaling currently active.

This command is a special-purpose wrapper around the
‘text-scale-increase’ command which makes repetition convenient
even when it is bound in a non-top-level keymap.  For binding in
a top-level keymap, ‘text-scale-increase’ or
‘text-scale-decrease’ may be more appropriate.

  Probably introduced at or before Emacs version 28.1.

Re: Contributing to Emacs

[Visuwesh]

[வியாழன் செப்டம்பர் 08, 2022] Christopher Dimech wrote:

>> Sent: Friday, September 09, 2022 at 1:47 AM
>> From: "Eli Zaretskii" <eliz@gnu.org>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
>> Subject: Re: Contributing to Emacs
>>
>> > From: Christopher Dimech <dimech@gmx.com>
>> > Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
>> > Date: Thu, 8 Sep 2022 14:12:01 +0200
>> > 
>> > @Eli, a pleasant thing would be to mention the commands for window and frame
>> > related scaling in the documentation of "text-scale-increase" and "text-scale-decrease".
>> 
>> They are mentioned in the doc string of text-scale-adjust, which is
>> the preferred user interface for this.
>
> What I get is the following.  I do not see any reference for the functionality
> that scales text in response to window resizing.

You have an old checkout?  I'm on a pretty recent HEAD and docstring of
text-scale-adjust links to global-text-scale-adjust.

    This command is a special-purpose wrapper around the
    ‘text-scale-increase’ command which makes repetition convenient
    even when it is bound in a non-top-level keymap.  For binding in
    a top-level keymap, ‘text-scale-increase’ or
    ‘text-scale-decrease’ may be more appropriate.

    Most faces are affected by these font size changes, but not faces
    that have an explicit ‘:height’ setting.  The two exceptions to
    this are the ‘default’ and ‘header-line’ faces: they will both be
    scaled even if they have an explicit ‘:height’ setting.

    See also the related command ‘global-text-scale-adjust’.

      Probably introduced at or before Emacs version 28.1.

    [back]	[forward]

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Friday, September 09, 2022 at 2:55 AM
> From: "Visuwesh" <visuweshm@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> [வியாழன் செப்டம்பர் 08, 2022] Christopher Dimech wrote:
> 
> >> Sent: Friday, September 09, 2022 at 1:47 AM
> >> From: "Eli Zaretskii" <eliz@gnu.org>
> >> To: "Christopher Dimech" <dimech@gmx.com>
> >> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> >> Subject: Re: Contributing to Emacs
> >>
> >> > From: Christopher Dimech <dimech@gmx.com>
> >> > Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> >> > Date: Thu, 8 Sep 2022 14:12:01 +0200
> >> > 
> >> > @Eli, a pleasant thing would be to mention the commands for window and frame
> >> > related scaling in the documentation of "text-scale-increase" and "text-scale-decrease".
> >> 
> >> They are mentioned in the doc string of text-scale-adjust, which is
> >> the preferred user interface for this.
> >
> > What I get is the following.  I do not see any reference for the functionality
> > that scales text in response to window resizing.
> 
> You have an old checkout?  I'm on a pretty recent HEAD and docstring of
> text-scale-adjust links to global-text-scale-adjust.

I get emacs-28.1.91 of 5 weeks ago.
 
>     This command is a special-purpose wrapper around the
>     ‘text-scale-increase’ command which makes repetition convenient
>     even when it is bound in a non-top-level keymap.  For binding in
>     a top-level keymap, ‘text-scale-increase’ or
>     ‘text-scale-decrease’ may be more appropriate.
> 
>     Most faces are affected by these font size changes, but not faces
>     that have an explicit ‘:height’ setting.  The two exceptions to
>     this are the ‘default’ and ‘header-line’ faces: they will both be
>     scaled even if they have an explicit ‘:height’ setting.
> 
>     See also the related command ‘global-text-scale-adjust’.
> 
>       Probably introduced at or before Emacs version 28.1.
> 
>     [back]	[forward]
>

Re: Contributing to Emacs

[Robert Pluim]

>>>>> On Thu, 8 Sep 2022 17:16:42 +0200, Christopher Dimech <dimech@gmx.com> said:

    >> > What I get is the following.  I do not see any reference for the functionality
    >> > that scales text in response to window resizing.
    >> 
    >> You have an old checkout?  I'm on a pretty recent HEAD and docstring of
    >> text-scale-adjust links to global-text-scale-adjust.

    Christopher> I get emacs-28.1.91 of 5 weeks ago.

Thatʼs the emacs-28 branch. The relevant code and doc changes are on
the master branch.

Robert
-- 

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Friday, September 09, 2022 at 3:24 AM
> From: "Robert Pluim" <rpluim@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Visuwesh" <visuweshm@gmail.com>, "Eli Zaretskii" <eliz@gnu.org>, jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> >>>>> On Thu, 8 Sep 2022 17:16:42 +0200, Christopher Dimech <dimech@gmx.com> said:
> 
>     >> > What I get is the following.  I do not see any reference for the functionality
>     >> > that scales text in response to window resizing.
>     >> 
>     >> You have an old checkout?  I'm on a pretty recent HEAD and docstring of
>     >> text-scale-adjust links to global-text-scale-adjust.
> 
>     Christopher> I get emacs-28.1.91 of 5 weeks ago.
> 
> Thatʼs the emacs-28 branch. The relevant code and doc changes are on
> the master branch.

Right.  Have seen that tags for the emacs-28 branch.  I wonder if there could be
a tag system as well when checking out the master branch.  It would be quite helpful
and quick to see what one has, especially when having multiple versions locally.

Re: Contributing to Emacs

[Visuwesh]

[வியாழன் செப்டம்பர் 08, 2022] Christopher Dimech wrote:

>> Sent: Friday, September 09, 2022 at 3:24 AM
>> From: "Robert Pluim" <rpluim@gmail.com>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: "Visuwesh" <visuweshm@gmail.com>, "Eli Zaretskii" <eliz@gnu.org>, jaopaulolc@gmail.com, emacs-devel@gnu.org
>> Subject: Re: Contributing to Emacs
>>
>> >>>>> On Thu, 8 Sep 2022 17:16:42 +0200, Christopher Dimech <dimech@gmx.com> said:
>> 
>>     >> > What I get is the following.  I do not see any reference for the functionality
>>     >> > that scales text in response to window resizing.
>>     >> 
>>     >> You have an old checkout?  I'm on a pretty recent HEAD and docstring of
>>     >> text-scale-adjust links to global-text-scale-adjust.
>> 
>>     Christopher> I get emacs-28.1.91 of 5 weeks ago.
>> 
>> Thatʼs the emacs-28 branch. The relevant code and doc changes are on
>> the master branch.
>
> Right.  Have seen that tags for the emacs-28 branch.  I wonder if there could be
> a tag system as well when checking out the master branch.  It would be quite helpful
> and quick to see what one has, especially when having multiple versions locally.

We already have emacs-repository-version.

Re: Contributing to Emacs

[Robert Pluim]

>>>>> On Thu, 8 Sep 2022 17:34:59 +0200, Christopher Dimech <dimech@gmx.com> said:

    >> Thatʼs the emacs-28 branch. The relevant code and doc changes are on
    >> the master branch.

    Christopher> Right.  Have seen that tags for the emacs-28 branch.  I wonder if there could be
    Christopher> a tag system as well when checking out the master branch.  It would be quite helpful
    Christopher> and quick to see what one has, especially when having multiple versions locally.

What would be the point of tagging master? It never goes through any
kind of formal "it is now stable" process until a release branch is
created. And if you want to see which revision youʼre at, any variant
of

    git log -1

or the builtin `emacs-repository-version' variable will tell you.

Robert
-- 

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Friday, September 09, 2022 at 3:39 AM
> From: "Robert Pluim" <rpluim@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Visuwesh" <visuweshm@gmail.com>, "Eli Zaretskii" <eliz@gnu.org>, jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> >>>>> On Thu, 8 Sep 2022 17:34:59 +0200, Christopher Dimech <dimech@gmx.com> said:
> 
>     >> Thatʼs the emacs-28 branch. The relevant code and doc changes are on
>     >> the master branch.
> 
>     Christopher> Right.  Have seen that tags for the emacs-28 branch.  I wonder if there could be
>     Christopher> a tag system as well when checking out the master branch.  It would be quite helpful
>     Christopher> and quick to see what one has, especially when having multiple versions locally.
> 
> What would be the point of tagging master? It never goes through any
> kind of formal "it is now stable" process until a release branch is
> created. And if you want to see which revision youʼre at, any variant
> of
> 
>     git log -1
> 
> or the builtin `emacs-repository-version' variable will tell you.

It says in the README 

This directory tree holds version 29.0.50 of GNU Emacs,

So everything is fine as it is.

Re: Contributing to Emacs

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, jaopaulolc@gmail.com, emacs-devel@gnu.org
> Date: Thu, 8 Sep 2022 17:16:42 +0200
> 
> > >> > @Eli, a pleasant thing would be to mention the commands for window and frame
> > >> > related scaling in the documentation of "text-scale-increase" and "text-scale-decrease".
> > >> 
> > >> They are mentioned in the doc string of text-scale-adjust, which is
> > >> the preferred user interface for this.
> > >
> > > What I get is the following.  I do not see any reference for the functionality
> > > that scales text in response to window resizing.
> > 
> > You have an old checkout?  I'm on a pretty recent HEAD and docstring of
> > text-scale-adjust links to global-text-scale-adjust.
> 
> I get emacs-28.1.91 of 5 weeks ago.

You've lost context: when this started I said the feature exists on
the master branch, i.e. in Emacs 29.  You are using Emacs 28, which is
delivered from the emacs-28 branch.

Re: Contributing to Emacs

[Christopher Dimech]

> Sent: Friday, September 09, 2022 at 4:11 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: visuweshm@gmail.com, jaopaulolc@gmail.com, emacs-devel@gnu.org
> Subject: Re: Contributing to Emacs
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, jaopaulolc@gmail.com, emacs-devel@gnu.org
> > Date: Thu, 8 Sep 2022 17:16:42 +0200
> >
> > > >> > @Eli, a pleasant thing would be to mention the commands for window and frame
> > > >> > related scaling in the documentation of "text-scale-increase" and "text-scale-decrease".
> > > >>
> > > >> They are mentioned in the doc string of text-scale-adjust, which is
> > > >> the preferred user interface for this.
> > > >
> > > > What I get is the following.  I do not see any reference for the functionality
> > > > that scales text in response to window resizing.
> > >
> > > You have an old checkout?  I'm on a pretty recent HEAD and docstring of
> > > text-scale-adjust links to global-text-scale-adjust.
> >
> > I get emacs-28.1.91 of 5 weeks ago.
>
> You've lost context: when this started I said the feature exists on
> the master branch, i.e. in Emacs 29.  You are using Emacs 28, which is
> delivered from the emacs-28 branch.

Yes, Robert told me, and got the right branch now.

Re: Contributing to Emacs

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: jaopaulolc@gmail.com, emacs-devel@gnu.org
> Date: Thu, 8 Sep 2022 16:49:57 +0200
> 
> > > @Eli, a pleasant thing would be to mention the commands for window and frame
> > > related scaling in the documentation of "text-scale-increase" and "text-scale-decrease".
> > 
> > They are mentioned in the doc string of text-scale-adjust, which is
> > the preferred user interface for this.
> 
> What I get is the following.  I do not see any reference for the functionality
> that scales text in response to window resizing.

Because you are looking at the doc string in a version of Emacs where
the globalized variant of this command doesn't exist.

Re: Contributing to Emacs

[Stefan Monnier]

>  I was looking at the file etc/TODO in the repo, and some items there
> caught my attention. For example, under 'Important Features'  I found 'Add
> an "indirect goto" byte-code'. Is this still a desired feature or is it not
> required due to recent efforts towards native compilation? (In the negative
> case, please feel free to suggest another item for me to work on)

I think I was the one to add this point to etc/TODO and AFAIK the need
is pretty much still the same, yes.  Part of the idea is to handle more
efficiently code which uses local lambda expressions (like `cl-flet`).

There's a lot of scope here.  Some steps are easy but won't bring any
(or very little) benefit, which others depend on those first steps and
require much more extensive work.

> If it is still desired I would like to work on it and would appreciate
> guidance. After taking a look at lisp/emacs-lisp/bytecomp.el,it seems that
> forms such as
>
>  (let ((foo (lambda (x) bar)))
>      (dosomething
>        (funcall foo toto)
>        (blabla (funcall foo titi))))
>
> are compiled by calling byte-compile-let. Before generating the binding for
> foo, #'(lambda (x) bar) is compiled by calling
> byte-compile-push-binding-init, which in turn compiles the lambda to
> bytecode and pushes it to the stack.
>
> So to make it more concrete for my sake, I wrote the following form
>
> (let ((foo (lambda (x) (- x 1))))
>   (* (funcall foo 2)
>      (- (funcall foo 3) 2)))

Indeed, I think it might be fairly easy to handle this code more
efficiently.  Things become more ... interesting when we have code like:

    (let* ((count 0)
           (foo (lambda (x) (setq count (1+ count)) (+ x count))))
      (* (funcall foo 2)
         (- (funcall foo 3) 2)))

Where `cconv.el` turns the `count` into a one-element list and
replaces the `setq` with a `setcar`, which wouldn't be needed if we
could directly refer to the `count` var from the inner lambda using
those new byte codes.

Even more interesting would be

    (let* ((count 0)
           (foo (lambda (x) (setq count (1+ count)) (+ x count))))
      (let ((bar (funcall foo 2)))
         (- (funcall foo 3) bar)))

where the relative position of `count` on the stack is different in the
two calls to `foo`.

> and with disassemble inspected the generated bytecode by Emacs 28.1
>
> byte code:
>   args: nil
> 0       constant  <compiled-function>
>       args: (x)
>     0       varref    x
>     1       sub1
>     2       return
>
> 1       dup
> 2       varbind   foo
> 3       constant  2
> 4       call      1
> 5       varref    foo
> 6       constant  3
> 7       call      1
> 8       constant  2
> 9       diff
> 10      mult
> 11      unbind    1
> 12      return
>
> As far as I understood,  the idea of the "indirect goto" here is to
> eliminate the calls on lines 4 and 7 and replace them with an indirect
> goto.

The ones at 4 and 7 can stay as "normal" gotos but they need to pass to
the function an additional argument which is the return address, and
then the inner function would be the one which uses an indirect goto
instead of "return".

> stack* in line 0 (constant <compiled-function>). Thus, for the indirect
> goto idea to work, the bytecode of the lambda would need to be part of the
> bytecode of the let's body**. That way, a computed branch can branch into
> the lambdas code and it is possible to branch out of it when returning.

I guess in theory there could be cases where we could use a computed
goto to jump into a function, but that needs probably too many stars to
be aligned to be worth considering.  The indirect goto is needed for
"return", OTOH.

> Aside from guidance on implementing this, I would appreciate any
> pointers on how to adequately test it.

I don't think there's currently many ways to test bytecode level
operation, other than writing normal ELisp code which we expect will use
those bytecodes and make sure they behave as expected.


        Stefan

Contributing to Emacs

[Jacob Criner]

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

Hello,

I would like to support Emacs by writing documentation. Thank you.

Best, Jacob

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

Re: Contributing to Emacs

[Xue Fuqiao]

On Tue, 19 Mar 2013 22:44:30 -0700
Jacob Criner <jacobcriner@gmail.com> wrote:

> Hello,

Hi,

> I would like to support Emacs by writing documentation.

Thanks!  What are you interested in?  Texinfo files?  Man pages?  Or doc
strings?  (Maybe refcard is also a kind of documentation.)

Some small suggestions:
1. Assign the copyright to the FSF for non-trivial contributions;
2. Use the latest version of Emacs (bzr trunk);
3. Sending the patch(es) to bug-gnu-emacs@gnu.org

See also:
http://www.gnu.org/prep/standards/html_node/Documentation.html#Documentation

-- 
Xue Fuqiao
http://www.gnu.org/software/emacs/

Re: Contributing to Emacs

[Stefan Monnier]

> I would like to support Emacs by writing documentation. Thank you.

Thank you very much.
We'd be very happy to have you help us with Emacs's documentation.
Here are the things we usually need w.r.t our documentation:
- Proof-reading the manuals.  That's also a great way to learn more
  about Emacs (even for "veterans" like myself).
  This is usually done together with reading the NEWS file to make sure
  that the manual has been updated.
- Translating the tutorial in some other language.
- Add documentation about some package/feature that isn't mentioned
  in the manual or doesn't have its own manual yet.
- Compare docstrings with the corresponding description in the manual
  (when applicable).  They usually shouldn't be identical, but they
  should not contradict each other.  Generally the manual gives a bit
  less details but more background/context.
Take your pick,


        Stefan

RE: Contributing to Emacs

[Drew Adams]

> > I would like to support Emacs by writing documentation. Thank you.
> 
> Thank you very much.
> We'd be very happy to have you help us with Emacs's documentation.
> Here are the things we usually need w.r.t our documentation:
> - Proof-reading the manuals.  That's also a great way to learn more
>   about Emacs (even for "veterans" like myself).
>   This is usually done together with reading the NEWS file to 
>   make sure that the manual has been updated.
> - Translating the tutorial in some other language.
> - Add documentation about some package/feature that isn't mentioned
>   in the manual or doesn't have its own manual yet.
> - Compare docstrings with the corresponding description in the manual
>   (when applicable).  They usually shouldn't be identical, but they
>   should not contradict each other.  Generally the manual gives a bit
>   less details but more background/context.
> Take your pick,

Not to mention that there are plenty of outstanding doc bugs.  Readers have
already proof-read the manuals to some extent, and reported specific problems
and suggestions for improvement.

http://debbugs.gnu.org/cgi/pkgreport.cgi?archive=both;include=subject%3Adoc;excl
ude=pending%3Adone;package=emacs

Not every report with Subject matching "doc" is a doc bug report, of course, and
there are reported doc bugs whose Subject does not match "doc".  But it's a
start.