gnulib fsusage

gnulib fsusage

[Po Lu]

Apparently lib/fsusage.o is not built when there is no suitable way for
it to get the necessary information, but it is still used
unconditionally by Emacs.

Is this the right way to detect whether or not get_fs_usage is actually
present?

diff --git a/src/fileio.c b/src/fileio.c
index 6fa524b3bb4..87d7e901203 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -6360,6 +6360,10 @@ DEFUN ("file-system-info", Ffile_system_info, Sfile_system_info, 1, 1, 0,
       error ("Invalid handler in `file-name-handler-alist'");
     }
 
+#if defined STAT_STATFS2_BSIZE || defined STAT_STATFS2_FRSIZE	\
+  || defined STAT_STATFS2_FSIZE || defined STAT_STATFS3_OSF1	\
+  || defined STAT_STATFS4 || defined STAT_STATVFS		\
+  || defined STAT_STATVFS64
   struct fs_usage u;
   if (get_fs_usage (SSDATA (ENCODE_FILE (filename)), NULL, &u) != 0)
     return errno == ENOSYS ? Qnil : file_attribute_errno (filename, errno);
@@ -6367,6 +6371,9 @@ DEFUN ("file-system-info", Ffile_system_info, Sfile_system_info, 1, 1, 0,
 		blocks_to_bytes (u.fsu_blocksize, u.fsu_bfree, false),
 		blocks_to_bytes (u.fsu_blocksize, u.fsu_bavail,
 				 u.fsu_bavail_top_bit_set));
+#else
+  return Qnil;
+#endif
 }
 
 #endif /* !DOS_NT */

It's probably not, but I don't have any better ideas.

Thanks.

Re: gnulib fsusage

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Thu, 19 Jan 2023 10:24:29 +0800
> 
> Apparently lib/fsusage.o is not built when there is no suitable way for
> it to get the necessary information, but it is still used
> unconditionally by Emacs.

Not unconditionally: the implementation of file-system-info in
fileio.c is conditioned on !DOS_NT, and both MSDOS and WINDOWSNT ports
have their separate implementations which don't use Gnulib's fsusage.

> Is this the right way to detect whether or not get_fs_usage is actually
> present?

Which port needs to exclude it, and why?  Is that port going to
implement its own version of file-system-info?  We must have a
non-trivial working implementation for each supported platform,
because Dired (and Tramp?) uses it.

If the port you are considering will have its own implementation, then
the same method as DOS_NT uses will be appropriate.

> +#else
> +  return Qnil;
> +#endif

I don't think this could fly, because Dired and other places need a
real implementation.  Please tell more about the problem you are
trying to solve.

Re: gnulib fsusage

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

>> Is this the right way to detect whether or not get_fs_usage is actually
>> present?
>
> Which port needs to exclude it, and why?  Is that port going to
> implement its own version of file-system-info?  We must have a
> non-trivial working implementation for each supported platform,
> because Dired (and Tramp?) uses it.
>
> If the port you are considering will have its own implementation, then
> the same method as DOS_NT uses will be appropriate.

Tramp has its own implementation(s) of file-system-info, which doesn't
depend on get_fs_usage. Even if this libray function is not available on
the local system, Tramp could return proper information.

Best regards, Michael.

Re: gnulib fsusage

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Date: Thu, 19 Jan 2023 10:24:29 +0800
>> 
>> Apparently lib/fsusage.o is not built when there is no suitable way for
>> it to get the necessary information, but it is still used
>> unconditionally by Emacs.
>
> Not unconditionally: the implementation of file-system-info in
> fileio.c is conditioned on !DOS_NT, and both MSDOS and WINDOWSNT ports
> have their separate implementations which don't use Gnulib's fsusage.
>
>> Is this the right way to detect whether or not get_fs_usage is actually
>> present?
>
> Which port needs to exclude it, and why?  Is that port going to
> implement its own version of file-system-info?  We must have a
> non-trivial working implementation for each supported platform,
> because Dired (and Tramp?) uses it.

The Android port doesn't support statvfs, because that function is
missing from the Android C library, apparently for security reasons.

> If the port you are considering will have its own implementation, then
> the same method as DOS_NT uses will be appropriate.

I cannot find any way to do such an implementation, sorry.  But if
someone else knows, that would be great.  Thanks.

Re: gnulib fsusage

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jan 2023 18:11:45 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Which port needs to exclude it, and why?  Is that port going to
> > implement its own version of file-system-info?  We must have a
> > non-trivial working implementation for each supported platform,
> > because Dired (and Tramp?) uses it.
> 
> The Android port doesn't support statvfs, because that function is
> missing from the Android C library, apparently for security reasons.

Don't you think your work on the Android port should be discussed
more, and not just for the current minor issue?  I'd hate to have
those discussions when the port is ready, which means you will have
invested a lot of hard labor in it.

> > If the port you are considering will have its own implementation, then
> > the same method as DOS_NT uses will be appropriate.
> 
> I cannot find any way to do such an implementation, sorry.  But if
> someone else knows, that would be great.  Thanks.

At least return a list of 3 numbers (zeros?), not nil.

Re: gnulib fsusage

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Don't you think your work on the Android port should be discussed
> more, and not just for the current minor issue?  I'd hate to have
> those discussions when the port is ready, which means you will have
> invested a lot of hard labor in it.

Well, I only just found out this problem, and have immediately begun
discussing it.  Isn't that fast enough? :D

> At least return a list of 3 numbers (zeros?), not nil.

OK.  But the doc string says it can return nil if the system call fails.

Re: gnulib fsusage

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jan 2023 19:59:54 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Don't you think your work on the Android port should be discussed
> > more, and not just for the current minor issue?  I'd hate to have
> > those discussions when the port is ready, which means you will have
> > invested a lot of hard labor in it.
> 
> Well, I only just found out this problem, and have immediately begun
> discussing it.  Isn't that fast enough? :D

I didn't just read your request, I've looked at the branch.  I'm not
sure I'm happy with what I see there.  Too much stuff that IMNSHO
should have been discussed before coding it.

> > At least return a list of 3 numbers (zeros?), not nil.
> 
> OK.  But the doc string says it can return nil if the system call fails.

<Shrug> Suit yourself.

Re: gnulib fsusage

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't just read your request, I've looked at the branch.  I'm not
> sure I'm happy with what I see there.  Too much stuff that IMNSHO
> should have been discussed before coding it.

Could you please explain what that would be?
This seems like a good opportunity to start discussing it now, thanks.

Re: Android port (was: gnulib fsusage)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jan 2023 21:40:18 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I didn't just read your request, I've looked at the branch.  I'm not
> > sure I'm happy with what I see there.  Too much stuff that IMNSHO
> > should have been discussed before coding it.
> 
> Could you please explain what that would be?
> This seems like a good opportunity to start discussing it now, thanks.

First, we need to decide whether we indeed want to have this in Emacs.
Android is not a free platform, so when its support comes with a lot
of additional non-trivial code that we'd need to understand and
support/maintain (including a lot of Java), we had better discussed
that first.

If we do decide to have this, I'd definitely want more documentation
of the internals and how they differ from the "traditional" platforms
than you have there now, and preferably in one place, not scattered
among the many source files, Makefile's, and READMEs.

Then there are the design decisions you made: how to support windows
and frames, how to handle the "task-killer" issues, how to handle the
Android's access rights and privileges system, etc.  For instance, I
was quite surprised to see lack of support for scroll bars on account
of them being "useless": I'm a happy user of an Android smartphone,
and I use the scroll bars all the time.

If we are to have a serious discussion of this, I'd encourage people
to read the code of the branch and bring up issues here.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> First, we need to decide whether we indeed want to have this in Emacs.
> Android is not a free platform, so when its support comes with a lot
> of additional non-trivial code that we'd need to understand and
> support/maintain (including a lot of Java), we had better discussed
> that first.

OK.  But to be fair, I had zero experience with Android development
myself before working on this; I have taken care to keep the Java code
as minimal as possible and comprehensible to C developers.

> If we do decide to have this, I'd definitely want more documentation
> of the internals and how they differ from the "traditional" platforms
> than you have there now, and preferably in one place, not scattered
> among the many source files, Makefile's, and READMEs.

Sure.  Please feel free to describe what you find confusing, and I will
try to document it in the README in the java directory.

> Then there are the design decisions you made: how to support windows
> and frames, how to handle the "task-killer" issues, how to handle the
> Android's access rights and privileges system, etc.

> For instance, I was quite surprised to see lack of support for scroll
> bars on account of them being "useless": I'm a happy user of an
> Android smartphone, and I use the scroll bars all the time.

I tried to find the scroll bars in a real (as in, not Emacs) Android
application, and could not find any at all.  The scroll bar in the
toolkit does not respond to input at all, and disappears after you
finish scrolling.  Besides, the Emacs scroll bar implementation I worked
on had major problems adapting to touch screen input.

> If we are to have a serious discussion of this, I'd encourage people
> to read the code of the branch and bring up issues here.

Yes, please do so.  Thanks.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 19 Jan 2023 22:34:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If we do decide to have this, I'd definitely want more documentation
> > of the internals and how they differ from the "traditional" platforms
> > than you have there now, and preferably in one place, not scattered
> > among the many source files, Makefile's, and READMEs.
> 
> Sure.  Please feel free to describe what you find confusing, and I will
> try to document it in the README in the java directory.

It isn't just about the Java directory.  It's every point where the
Android port deviates from its desktop/laptop behavior.  Starting with
dumping, then the fact that we compile to shared libraries instead of
executables, etc. etc.

> > Then there are the design decisions you made: how to support windows
> > and frames, how to handle the "task-killer" issues, how to handle the
> > Android's access rights and privileges system, etc.
> 
> > For instance, I was quite surprised to see lack of support for scroll
> > bars on account of them being "useless": I'm a happy user of an
> > Android smartphone, and I use the scroll bars all the time.
> 
> I tried to find the scroll bars in a real (as in, not Emacs) Android
> application, and could not find any at all.

?? The Web browser comes to mind and the email client.  The scroll bar
in both is quite functional.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> It isn't just about the Java directory.  It's every point where the
> Android port deviates from its desktop/laptop behavior.  Starting with
> dumping, then the fact that we compile to shared libraries instead of
> executables, etc. etc.

Where should that information be put?

> ?? The Web browser comes to mind and the email client.  The scroll bar
> in both is quite functional.

Ah.  Here, in Mozilla Firefox, I can't find any scroll bars at all.
K9 mail does have them, but of the disappearing kind.  What vendor made
your Android device?

Re: Android port (was: gnulib fsusage)

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: emacs-devel@gnu.org
> > Date: Thu, 19 Jan 2023 21:40:18 +0800
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > I didn't just read your request, I've looked at the branch.  I'm not
> > > sure I'm happy with what I see there.  Too much stuff that IMNSHO
> > > should have been discussed before coding it.
> > 
> > Could you please explain what that would be?
> > This seems like a good opportunity to start discussing it now, thanks.
> 
> First, we need to decide whether we indeed want to have this in Emacs.
> Android is not a free platform, so when its support comes with a lot
> of additional non-trivial code that we'd need to understand and
> support/maintain (including a lot of Java), we had better discussed
> that first.

Replicant is free platform.

Replicant:
https://www.replicant.us/

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 20 Jan 2023 08:18:14 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It isn't just about the Java directory.  It's every point where the
> > Android port deviates from its desktop/laptop behavior.  Starting with
> > dumping, then the fact that we compile to shared libraries instead of
> > executables, etc. etc.
> 
> Where should that information be put?

Preferably on the android_*.c files, each file with its part of the
story.  Alternatively, you could have a separate android-internals.txt
file in admin/notes/, I suppose.

> > ?? The Web browser comes to mind and the email client.  The scroll bar
> > in both is quite functional.
> 
> Ah.  Here, in Mozilla Firefox, I can't find any scroll bars at all.
> K9 mail does have them, but of the disappearing kind.  What vendor made
> your Android device?

Samsung.  I tried their own browser (which AFAIU is a derivative of
Chromium), not Firefox.

It sounds like on Android, scroll bars are not unified, and each app
provides what it wants.  But it is definitely possible to have a
functional scroll bar.

Re: Android port (was: gnulib fsusage)

[Eli Zaretskii]

> Date: Fri, 20 Jan 2023 09:47:34 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > First, we need to decide whether we indeed want to have this in Emacs.
> > Android is not a free platform, so when its support comes with a lot
> > of additional non-trivial code that we'd need to understand and
> > support/maintain (including a lot of Java), we had better discussed
> > that first.
> 
> Replicant is free platform.

That fact is not relevant to this discussion.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Preferably on the android_*.c files, each file with its part of the
> story.  Alternatively, you could have a separate android-internals.txt
> file in admin/notes/, I suppose.

OK, thanks.  I think the latter would be easier.

>> > ?? The Web browser comes to mind and the email client.  The scroll bar
>> > in both is quite functional.
>> 
>> Ah.  Here, in Mozilla Firefox, I can't find any scroll bars at all.
>> K9 mail does have them, but of the disappearing kind.  What vendor made
>> your Android device?
>
> Samsung.  I tried their own browser (which AFAIU is a derivative of
> Chromium), not Firefox.

Thanks.  I'll take a look at what the Samsung browser does.

> It sounds like on Android, scroll bars are not unified, and each app
> provides what it wants.  But it is definitely possible to have a
> functional scroll bar.

I guess so.  The non-functional scroll bar I was referring to is the
scroll bar provided by the Android toolkit as part of the ScrollView
widget.

Re: Android port

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Preferably on the android_*.c files, each file with its part of the
> story.  Alternatively, you could have a separate android-internals.txt
> file in admin/notes/, I suppose.

I ended up putting a significant writeup in java/README, as that's where
the Nextstep port has its documentation, which is supposed to teach us
Emacs developers Objective-C.

Would you please read it and say what you think?
I will extend it in the next few days to describe more of the GUI code
as well.

Thanks.

Re: Android port

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 25 Jan 2023 18:48:05 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Preferably on the android_*.c files, each file with its part of the
> > story.  Alternatively, you could have a separate android-internals.txt
> > file in admin/notes/, I suppose.
> 
> I ended up putting a significant writeup in java/README, as that's where
> the Nextstep port has its documentation, which is supposed to teach us
> Emacs developers Objective-C.
> 
> Would you please read it and say what you think?

Thanks, will do when I have time.

Re: Android port (was: gnulib fsusage)

[Konstantin Kharlamov]

On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
> > Date: Fri, 20 Jan 2023 09:47:34 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > > First, we need to decide whether we indeed want to have this in Emacs.
> > > Android is not a free platform, so when its support comes with a lot
> > > of additional non-trivial code that we'd need to understand and
> > > support/maintain (including a lot of Java), we had better discussed
> > > that first.
> > 
> > Replicant is free platform.
> 
> That fact is not relevant to this discussion.

I think the point Jean meant to make is that Android platform per se isn't
closed, even if the unfortunate situation is that many vendors ship a lot of
closed code, mainly drivers (tho situation with closed drivers is slowly
improving, Google seem to be working on that).

The link Jean posted is just one of (free and open source) derivatives of
Android platform. The other one very popular comes to mind was CyanogenMod,
which later was succeeded by LineageOS.

Re: Android port (was: gnulib fsusage)

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 28 Jan 2023 10:50:02 +0300
> 
> On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
> > > Date: Fri, 20 Jan 2023 09:47:34 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> > > 
> > > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > > > First, we need to decide whether we indeed want to have this in Emacs.
> > > > Android is not a free platform, so when its support comes with a lot
> > > > of additional non-trivial code that we'd need to understand and
> > > > support/maintain (including a lot of Java), we had better discussed
> > > > that first.
> > > 
> > > Replicant is free platform.
> > 
> > That fact is not relevant to this discussion.
> 
> I think the point Jean meant to make is that Android platform per se isn't
> closed, even if the unfortunate situation is that many vendors ship a lot of
> closed code, mainly drivers (tho situation with closed drivers is slowly
> improving, Google seem to be working on that).
> 
> The link Jean posted is just one of (free and open source) derivatives of
> Android platform. The other one very popular comes to mind was CyanogenMod,
> which later was succeeded by LineageOS.

Since the absolute majority of Android devices out there are non-free,
the fact that a small number of free ones exist is not relevant to
the main points of this discussion.

Re: Android port (was: gnulib fsusage)

[Konstantin Kharlamov]

On Sat, 2023-01-28 at 10:49 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sat, 28 Jan 2023 10:50:02 +0300
> > 
> > On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
> > > > Date: Fri, 20 Jan 2023 09:47:34 +0300
> > > > From: Jean Louis <bugs@gnu.support>
> > > > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> > > > 
> > > > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > > > > First, we need to decide whether we indeed want to have this in Emacs.
> > > > > Android is not a free platform, so when its support comes with a lot
> > > > > of additional non-trivial code that we'd need to understand and
> > > > > support/maintain (including a lot of Java), we had better discussed
> > > > > that first.
> > > > 
> > > > Replicant is free platform.
> > > 
> > > That fact is not relevant to this discussion.
> > 
> > I think the point Jean meant to make is that Android platform per se isn't
> > closed, even if the unfortunate situation is that many vendors ship a lot of
> > closed code, mainly drivers (tho situation with closed drivers is slowly
> > improving, Google seem to be working on that).
> > 
> > The link Jean posted is just one of (free and open source) derivatives of
> > Android platform. The other one very popular comes to mind was CyanogenMod,
> > which later was succeeded by LineageOS.
> 
> Since the absolute majority of Android devices out there are non-free,
> the fact that a small number of free ones exist is not relevant to
> the main points of this discussion.

You seem to be confusing a platform per se with customer devices it installed on. The Android platform is free: it has its sources open, it is being developed in the open, and it even has derivatives.

The unfortunate fact that majority of the customer devices has a *modified* Android where the modifications were not released in the public is in my opinion irrelevant. That is because you are not developing against specific proprietary device, instead you are developing against open Android libraries, which are supported by those devices anyway.

Re: Android port (was: gnulib fsusage)

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: bugs@gnu.support, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sat, 28 Jan 2023 12:06:02 +0300
> 
> > Since the absolute majority of Android devices out there are non-free,
> > the fact that a small number of free ones exist is not relevant to
> > the main points of this discussion.
> 
> You seem to be confusing a platform per se with customer devices it installed on. The Android platform is free: it has its sources open, it is being developed in the open, and it even has derivatives.

AFAIK, even this part is not true: most Android devices have custom
proprietary additions and changes to the platform specific to each
vendor.

> The unfortunate fact that majority of the customer devices has a *modified* Android where the modifications were not released in the public is in my opinion irrelevant. That is because you are not developing against specific proprietary device, instead you are developing against open Android libraries, which are supported by those devices anyway.

I don't see how this is relevant, sorry.  The platform is still
non-free, and the fact that it started from free baseline doesn't
matter.

Re: Android port (was: gnulib fsusage)

[Konstantin Kharlamov]

On Sat, 2023-01-28 at 11:21 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <hi-angel@yandex.ru>
> > Cc: bugs@gnu.support, luangruo@yahoo.com, emacs-devel@gnu.org
> > Date: Sat, 28 Jan 2023 12:06:02 +0300
> > 
> > > Since the absolute majority of Android devices out there are non-free,
> > > the fact that a small number of free ones exist is not relevant to
> > > the main points of this discussion.
> > 
> > You seem to be confusing a platform per se with customer devices it
> > installed on. The Android platform is free: it has its sources open, it is
> > being developed in the open, and it even has derivatives.
> 
> AFAIK, even this part is not true: most Android devices have custom
> proprietary additions and changes to the platform specific to each
> vendor.

Please don't generalize actions of individual companies to the platform as whole. Your reply doesn't make my statement false, because the original Android is the one where no such vendor additions were made.

Either way, I doubt Po is planning to make any use of such proprietary additions, so discussing those additions has no value.

Re: Android port

[Po Lu]

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

> On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
>> > Date: Fri, 20 Jan 2023 09:47:34 +0300
>> > From: Jean Louis <bugs@gnu.support>
>> > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
>> > 
>> > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
>> > > First, we need to decide whether we indeed want to have this in Emacs.
>> > > Android is not a free platform, so when its support comes with a lot
>> > > of additional non-trivial code that we'd need to understand and
>> > > support/maintain (including a lot of Java), we had better discussed
>> > > that first.
>> > 
>> > Replicant is free platform.
>> 
>> That fact is not relevant to this discussion.
>
> I think the point Jean meant to make is that Android platform per se isn't
> closed, even if the unfortunate situation is that many vendors ship a lot of
> closed code, mainly drivers (tho situation with closed drivers is slowly
> improving, Google seem to be working on that).

Google is working on allowing the proprietary drivers to run alongside
any version of Linux, not on removing them entirely.

Google themselves develop Play Services, arguably the most problematic
piece of proprietary software in Android.

> The link Jean posted is just one of (free and open source) derivatives of
> Android platform. The other one very popular comes to mind was CyanogenMod,
> which later was succeeded by LineageOS.

LineageOS and CyanogenMod are not free software, because both contain
proprietary device driver files, and in the case of CyanogenMod,
proprietary user level libraries as well.

AOSP, on the other hand, is really free software.  But that doesn't help
when you can only run it in an emulator.

If you had read the Android appendix of the Emacs manual, you would have
seen that it explains this situation:

H.1 Android history
===================

Android is an operating system for mobile devices developed by the Open
Handset Alliance, a group of companies interested in developing handsets
that can run a common set of software.  It is supposedly free software.

   Like the X Consortium of times past, the Open Handset Alliance
believes that “openness” (namely, the regular release of the Android
source code) is simply a tool to increase the popularity of the Android
platform.  Computer companies normally produce proprietary software.
The companies in the Open Handset Alliance are no different – most
versions of Android installed on devices are proprietary, by virtue of
containing proprietary components, that often cannot even be replaced by
the user.

   Android is not designed to respect users’ freedom.  Almost all
versions of Android (including some which are supposedly free software)
include support for Digital Restrictions Management, technology that is
designed to limit users’ ability to copy media to and from their own
devices.  Most Android devices also come with proprietary Google
applications which are required to run the system, and many other
Android applications.

   Thus, it must be necessary to consider Android proprietary software
from a practical standpoint.  That is an injustice.  If you use Android,
we urge you to switch to a free operating system, if only for your
freedom’s sake.

   We support GNU Emacs on proprietary operating systems because we hope
this taste of freedom will inspire users to escape from them.

Re: Android port

[Po Lu]

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

> Please don't generalize actions of individual companies to the platform as whole. Your reply doesn't make my statement false, because the original Android is the one where no such vendor additions were made.
>
> Either way, I doubt Po is planning to make any use of such proprietary
> additions, so discussing those additions has no value.

We are not going to use features only in proprietary versions of Android
because we hope that the resulting Emacs binaries will also work on free
operating systems such as AOSP and Replicant.

But Android itself is proprietary from a practical standpoint, so we
will continue to treat it as a proprietary platform wrt its support in
Emacs, if only because free Android is available for a minuscule amount
of users.

Re: Android port

[Konstantin Kharlamov]

On Sat, 2023-01-28 at 17:57 +0800, Po Lu wrote:
> Google is working on allowing the proprietary drivers to run alongside
> any version of Linux, not on removing them entirely.
> 
> Google themselves develop Play Services, arguably the most problematic
> piece of proprietary software in Android.
> 
> > The link Jean posted is just one of (free and open source) derivatives of
> > Android platform. The other one very popular comes to mind was CyanogenMod,
> > which later was succeeded by LineageOS.
> 
> LineageOS and CyanogenMod are not free software, because both contain
> proprietary device driver files, and in the case of CyanogenMod,
> proprietary user level libraries as well.
> 
> AOSP, on the other hand, is really free software.  But that doesn't help
> when you can only run it in an emulator.
> 
> If you had read the Android appendix of the Emacs manual, you would have
> seen that it explains this situation:

I didn't because a link to the branch was never posted in the thread ☺

Either way, now I see the point you are trying to make as you're using an
expression "from a practical standpoint it is closed". So, like, in theory it is
open, but in practice no device runs the original Android.

In my head I still can't connect the relevance of that "practice" to Emacs
Android  port though, because you can treat the port as a program that is
supposed to run on the original open platform, and then, almost "accidentally"
(not really, but I hope you see my point), as an app that can run on any other
Android device…

But I won't be going into that further because my main motivation for
participation was to make sure your work on making the port isn't wasted, which,
judging by your reply, seem to have been resolved before I joined.

So, anyway, thanks for your work!

Re: Android port (was: gnulib fsusage)

[Jean Louis]

* Konstantin Kharlamov <hi-angel@yandex.ru> [2023-01-28 10:50]:
> On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
> > > Date: Fri, 20 Jan 2023 09:47:34 +0300
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> > > 
> > > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > > > First, we need to decide whether we indeed want to have this in Emacs.
> > > > Android is not a free platform, so when its support comes with a lot
> > > > of additional non-trivial code that we'd need to understand and
> > > > support/maintain (including a lot of Java), we had better discussed
> > > > that first.
> > > 
> > > Replicant is free platform.
> > 
> > That fact is not relevant to this discussion.
> 
> I think the point Jean meant to make is that Android platform per se isn't
> closed, even if the unfortunate situation is that many vendors ship a lot of
> closed code, mainly drivers (tho situation with closed drivers is slowly
> improving, Google seem to be working on that).

Yes, Eli mentioned "Android is not free platform", and I have
mentioned Android-based fully free platform.

LineageOS is not free that I know as it includes non-free drivers or something.

-- 
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 (was: gnulib fsusage)

[Jean Louis]

We have important fact at hand that there is more and more
Android-based operating systems. They tend to remove Google's
surveillance, and some of them tend to be "free" (quoted), and may not
be perfect as they may include blobs in kernel or drivers.

There is also new trend of efforts to provide fully free phones.

I cannot know if this OS has tendency to be fully free, but is based
on Android:

https://calyxos.org/

And some others:
https://itsfoss.com/android-distributions-roms/

Upcoming trends:
----------------

1. New OS-es based on Android
2. New OS-es not-based on Android
3. Phones coming to market being more and more free

Thus making an Android-based Emacs is more than useful for future.

Another interesting reference:
------------------------------

zielmicha/emacs-android: Emacs port to Android.:
https://github.com/zielmicha/emacs-android

Which runs Emacs in modified emulator.

-- 
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 (was: gnulib fsusage)

[Eli Zaretskii]

> Date: Sun, 29 Jan 2023 12:38:11 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Eli Zaretskii <eliz@gnu.org>, luangruo@yahoo.com,
>   emacs-devel@gnu.org
> 
> * Konstantin Kharlamov <hi-angel@yandex.ru> [2023-01-28 10:50]:
> > On Fri, 2023-01-20 at 09:19 +0200, Eli Zaretskii wrote:
> > > > Date: Fri, 20 Jan 2023 09:47:34 +0300
> > > > From: Jean Louis <bugs@gnu.support>
> > > > Cc: Po Lu <luangruo@yahoo.com>, emacs-devel@gnu.org
> > > > 
> > > > * Eli Zaretskii <eliz@gnu.org> [2023-01-19 17:28]:
> > > > > First, we need to decide whether we indeed want to have this in Emacs.
> > > > > Android is not a free platform, so when its support comes with a lot
> > > > > of additional non-trivial code that we'd need to understand and
> > > > > support/maintain (including a lot of Java), we had better discussed
> > > > > that first.
> > > > 
> > > > Replicant is free platform.
> > > 
> > > That fact is not relevant to this discussion.
> > 
> > I think the point Jean meant to make is that Android platform per se isn't
> > closed, even if the unfortunate situation is that many vendors ship a lot of
> > closed code, mainly drivers (tho situation with closed drivers is slowly
> > improving, Google seem to be working on that).
> 
> Yes, Eli mentioned "Android is not free platform", and I have
> mentioned Android-based fully free platform.
> 
> LineageOS is not free that I know as it includes non-free drivers or something.

This is all irrelevant to the issue at hand in this thread.  The issue
at hand here is whether and how much of an effort we want to invest in
this non-free platform.  It is exactly the same question as we ask
ourselves wrt MS-Windows.