Emacs 26.1 on Windows is HUGE

Emacs 26.1 on Windows is HUGE

[Björn Lindqvist]

I thought it was time to update my version of Emacs on Windows. So I
download emacs-26.1-x86_64-no-deps.zip package from
http://ftp.gnu.org/gnu/emacs/windows/emacs-26/. It is a whopping 109
mb and consumes 407 mb of space uncompressed. The emacs.exe file
itself is 121 mb. In comparison the emacs 24.5 installation consumes
160 mb and emacs.exe itself 8 mb.

I posit that there is something wrong with the way Emacs is packaged
for Windows. Perhaps there is a more lightweight distribution?


-- 
mvh/best regards Björn Lindqvist

Re: Emacs 26.1 on Windows is HUGE

[Óscar Fuentes]

Björn Lindqvist <bjourne@gmail.com> writes:

> I thought it was time to update my version of Emacs on Windows. So I
> download emacs-26.1-x86_64-no-deps.zip package from
> http://ftp.gnu.org/gnu/emacs/windows/emacs-26/. It is a whopping 109
> mb and consumes 407 mb of space uncompressed. The emacs.exe file
> itself is 121 mb. In comparison the emacs 24.5 installation consumes
> 160 mb and emacs.exe itself 8 mb.
>
> I posit that there is something wrong with the way Emacs is packaged
> for Windows. Perhaps there is a more lightweight distribution?

Most likely the executables include debug information. It uses disk
space but no RAM.

On addition to that, one thing that makes little for this distribution
is to include emacs.exe and emacs-26.1.exe, which are identical.

BTW, 26.2 was just released, although the binary pretests on

https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/

have the same size.

You can use `strip.exe' (from binutils) to remove the debug information.

You can use M-x report-emacs-bug to suggest removing debug info prior to
packaging and/or not including redundant executables as emacs-26.1.exe.

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

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

> Björn Lindqvist <bjourne@gmail.com> writes:
>
>> I thought it was time to update my version of Emacs on Windows. So I
>> download emacs-26.1-x86_64-no-deps.zip package from
>> http://ftp.gnu.org/gnu/emacs/windows/emacs-26/. It is a whopping 109
>> mb and consumes 407 mb of space uncompressed. The emacs.exe file
>> itself is 121 mb. In comparison the emacs 24.5 installation consumes
>> 160 mb and emacs.exe itself 8 mb.
>>
>> I posit that there is something wrong with the way Emacs is packaged
>> for Windows. Perhaps there is a more lightweight distribution?
>
> Most likely the executables include debug information. It uses disk
> space but no RAM.

They do. In addition, between 24 and 25 there was a change of build system.

> On addition to that, one thing that makes little for this distribution
> is to include emacs.exe and emacs-26.1.exe, which are identical.
>
> BTW, 26.2 was just released, although the binary pretests on
>
> https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/
>
> have the same size.
>
> You can use `strip.exe' (from binutils) to remove the debug information.
>
> You can use M-x report-emacs-bug to suggest removing debug info prior to
> packaging and/or not including redundant executables as emacs-26.1.exe.

Removing the redundant executables would break things for people who
want to unpack over an MSYS installation. If you really care about the
disk space (100Mb is really stretching the definition of "huge" these
days), using file system level compression would solve this problem, as
well as reducing the size of other parts of Emacs also.

Happy for there to be a discussion about debug information of
emacs-devel, though. If it's not needed, it can be removed.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Óscar Fuentes]

Phillip Lord <phillip.lord@russet.org.uk> writes:

> Removing the redundant executables would break things for people who
> want to unpack over an MSYS installation.

"People who want to install multiple Emacs versions on the same
directory root", not necessarily those who use MSYS, correct?

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

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

> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>> Removing the redundant executables would break things for people who
>> want to unpack over an MSYS installation.
>
> "People who want to install multiple Emacs versions on the same
> directory root", not necessarily those who use MSYS, correct?

Yes, this generalization is correct. AFAICT, though, only people with a
lot of other, non emacs, files are going to benefit from doing this as
multiple versions of emacs with one root take up the same size as
multiple versions with several roots. This is why msys was in my head.

I have checked now. Building Emacs with no debug reduces the size of the
executable from 120M to about 30M. The overall impact on install size is
as follows. For released versions we have:


170M	24
359M	25
742M	26-deps
412M	26-no-deps
109M	emacs-26.2-x86_64-no-deps.zip
211M	emacs-26.2-x86_64.zip

So, the size with no dependences has gone up a lot (this data is from
files on GNU/Linux).

For direct comparision with and without debugging we have without:

307M    deps
148M    emacs-26.2-i686.zip
50M     emacs-26.2-i686-no-deps.zip
150M    emacs-26.2-x86_64.zip
51M     emacs-26.2-x86_64-no-deps.zip
99M     no-deps
803M    total


and with:

$ du -shc *
401M    deps
208M    emacs-26.2-x86_64.zip
109M    emacs-26.2-x86_64-no-deps.zip
193M    nodeps
909M    total


So, for the no-deps version, we have a 50% reduction in the zip file
which equates to a 100% reduction on disk (assuming no file system
compression). Obviously for the with deps version, the proportions are
much smaller, but the actual size change the same.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Björn Lindqvist]

> Most likely the executables include debug information. It uses disk
> space but no RAM.
>
> On addition to that, one thing that makes little for this distribution
> is to include emacs.exe and emacs-26.1.exe, which are identical.
>
> BTW, 26.2 was just released, although the binary pretests on
>
> https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/
>
> have the same size.
>
> You can use `strip.exe' (from binutils) to remove the debug information.

I tried that. I downloaded the strip.exe fom

https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.28/

But when running it on the binary:

    > C:\code\langs\MingGW\bin\strip.exe -s emacs.exe
    C:\code\langs\MingGW\bin\strip.exe:emacs.exe: File format not recognized


--
mvh/best regards Björn Lindqvist

Re: Emacs 26.1 on Windows is HUGE

[Óscar Fuentes]

Björn Lindqvist <bjourne@gmail.com> writes:

>> Most likely the executables include debug information. It uses disk
>> space but no RAM.
>>
>> On addition to that, one thing that makes little for this distribution
>> is to include emacs.exe and emacs-26.1.exe, which are identical.
>>
>> BTW, 26.2 was just released, although the binary pretests on
>>
>> https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/
>>
>> have the same size.
>>
>> You can use `strip.exe' (from binutils) to remove the debug information.
>
> I tried that. I downloaded the strip.exe fom
>
> https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.28/
>
> But when running it on the binary:
>
>     > C:\code\langs\MingGW\bin\strip.exe -s emacs.exe
>     C:\code\langs\MingGW\bin\strip.exe:emacs.exe: File format not recognized

You have Emacs x86_64 and that "strip.exe" executable is for i686. That
means that you have a 64 bits Emacs Windows executable but the strip.exe
executable was configured for working on 32 bits executables.

Re: Emacs 26.1 on Windows is HUGE

[Björn Lindqvist]

Den mån 15 apr. 2019 kl 13:42 skrev Phillip Lord <phillip.lord@russet.org.uk>:
> > On addition to that, one thing that makes little for this distribution
> > is to include emacs.exe and emacs-26.1.exe, which are identical.
> >
> > BTW, 26.2 was just released, although the binary pretests on
> >
> > https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/
> >
> > have the same size.
> >
> > You can use `strip.exe' (from binutils) to remove the debug information.
> >
> > You can use M-x report-emacs-bug to suggest removing debug info prior to
> > packaging and/or not including redundant executables as emacs-26.1.exe.
>
> Removing the redundant executables would break things for people who
> want to unpack over an MSYS installation.

Perhaps the MSYS users can be taught to run cp emacs.exe
emacs-26.1.exe as a post-installation command? It seems like a vastly
superior alternative to wasting both bandwidth and disk space for the
large majority of Emacs users on Windows who are not interested in
MSYS.

> If you really care about the disk space (100Mb is really stretching
> the definition of "huge" these days), using file system level
> compression would solve this problem, as well as reducing the size
> of other parts of Emacs also.
>
> Happy for there to be a discussion about debug information of
> emacs-devel, though. If it's not needed, it can be removed.

I'm using old hardware with a small SSD which I'm happy with. I don't
want to have to update my hardware to accommodate Emacs growing
requirements.

While the 100mb file doesn't consume more memory, it takes longer to
load than an 8mb executable. Compressing it would increase the load
time further.

I'll happily start a discussion on emacs-devel. I just wanted to first
make sure I'm not resurrecting an old flame war or something along
those lines. Like political reasons for Windows Emacs being packaged
that way. If it is just neglect causing the bad packaging then I can
probably help fix that. I have some experience packaging Linux
applications for Windows.


--
mvh/best regards Björn Lindqvist

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Björn Lindqvist <bjourne@gmail.com> writes:

>> Removing the redundant executables would break things for people who
>> want to unpack over an MSYS installation.
>
> Perhaps the MSYS users can be taught to run cp emacs.exe
> emacs-26.1.exe as a post-installation command? It seems like a vastly
> superior alternative to wasting both bandwidth and disk space for the
> large majority of Emacs users on Windows who are not interested in
> MSYS.

Maybe. We are talking about 100Mb, which currently costs a fraction of
the smallest unit of most currencies; so I am struggling with
"vastly". I would guess that it is the minority of users who care about
this; they can, of course, rm emacs-26.1.exe with no harmful effects.

>
>> If you really care about the disk space (100Mb is really stretching
>> the definition of "huge" these days), using file system level
>> compression would solve this problem, as well as reducing the size
>> of other parts of Emacs also.
>>
>> Happy for there to be a discussion about debug information of
>> emacs-devel, though. If it's not needed, it can be removed.
>
> I'm using old hardware with a small SSD which I'm happy with. I don't
> want to have to update my hardware to accommodate Emacs growing
> requirements.
>
> While the 100mb file doesn't consume more memory, it takes longer to
> load than an 8mb executable. Compressing it would increase the load
> time further.

Likewise here I am a bit surprised. You can notice the difference
between 100mb vs 8mb on a SSD drive?

I use compression on the build machine for Emacs for Windows and it does
have an impact on the overall size, although that machine has lots of
copies of the same files.

> I'll happily start a discussion on emacs-devel. I just wanted to first
> make sure I'm not resurrecting an old flame war or something along
> those lines. Like political reasons for Windows Emacs being packaged
> that way. If it is just neglect causing the bad packaging then I can
> probably help fix that. I have some experience packaging Linux
> applications for Windows.

I genuinely do not know why it is that way, although it was probably me
that made it so. I would guess because Eli finds it easier to get better
bug reports. Maybe it's just a mess up on my behalf. That's why I
suggest you ask.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Björn Lindqvist]

Den tis 16 apr. 2019 kl 23:19 skrev Phillip Lord <phillip.lord@russet.org.uk>:
> >> Removing the redundant executables would break things for people who
> >> want to unpack over an MSYS installation.
> >
> > Perhaps the MSYS users can be taught to run cp emacs.exe
> > emacs-26.1.exe as a post-installation command? It seems like a vastly
> > superior alternative to wasting both bandwidth and disk space for the
> > large majority of Emacs users on Windows who are not interested in
> > MSYS.
>
> Maybe. We are talking about 100Mb, which currently costs a fraction of
> the smallest unit of most currencies; so I am struggling with
> "vastly". I would guess that it is the minority of users who care about
> this; they can, of course, rm emacs-26.1.exe with no harmful effects.

Yes, if they are power users like you and me who knows that removing
that file is safe. I think for most users one file is sufficient
because it reduces bandwidth usage (I'm on a metered internet
connection so larger files are more expensive) and disk space.

As someone who don't use MSYS I don't understand the advantage of
duplicating the files? You mentioned unzipping Emacs over an MSYS
installation, but that seems a little odd. Usually on Windows you
don't install software that way. But maybe for your use case you can
use the larger emacs-26.1-x86_64.zip file? It includes a lot of
dependencies like Python2.7, Sqlite 3.20, and OpenGL headers which I
don't understand what they are doing.

> > I'm using old hardware with a small SSD which I'm happy with. I don't
> > want to have to update my hardware to accommodate Emacs growing
> > requirements.
> >
> > While the 100mb file doesn't consume more memory, it takes longer to
> > load than an 8mb executable. Compressing it would increase the load
> > time further.
>
> Likewise here I am a bit surprised. You can notice the difference
> between 100mb vs 8mb on a SSD drive?

For sure. :) But I like to waste time optimizing software so perhaps
I'm more sensitive than most. Hot start of Emacs 24.5.1 takes almost
exactly 7 seconds and of 26.1 8 seconds. I do not know how much of the
slowdown is caused by the larger executable, but I bet at least some
of it is (I will have to check after I have installed the right
version of MinGW and the right version of strip.exe). If Windows is
doing stuff in the background (like disk indexing or whatever its
services are doing) the load times increases further.

> I genuinely do not know why it is that way, although it was probably me
> that made it so. I would guess because Eli finds it easier to get better
> bug reports. Maybe it's just a mess up on my behalf. That's why I
> suggest you ask.

Will do!


--
mvh/best regards Björn Lindqvist

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: Björn Lindqvist <bjourne@gmail.com>
> Date: Wed, 17 Apr 2019 00:18:27 +0200
> Cc: Óscar Fuentes <ofv@wanadoo.es>, help-gnu-emacs@gnu.org
> 
> As someone who don't use MSYS I don't understand the advantage of
> duplicating the files?

This has nothing to do with MSYS.  It's for when you install the next
version, emacs.exe gets overwritten, but emacs-26.1.exe stays, and you
can still invoke it.  IOW, it allows you to have several Emacs
versions installed simultaneously.

We didn't invent this for Windows, this is how Emacs installs itself
on all supported systems.  We just follow that on Windows, to be
consistent with all the other systems.

Re: Emacs 26.1 on Windows is HUGE

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Lindqvist <bjourne@gmail.com>
>> Date: Wed, 17 Apr 2019 00:18:27 +0200
>> Cc: Óscar Fuentes <ofv@wanadoo.es>, help-gnu-emacs@gnu.org
>> 
>> As someone who don't use MSYS I don't understand the advantage of
>> duplicating the files?
>
> This has nothing to do with MSYS.  It's for when you install the next
> version, emacs.exe gets overwritten, but emacs-26.1.exe stays, and you
> can still invoke it.  IOW, it allows you to have several Emacs
> versions installed simultaneously.
>
> We didn't invent this for Windows, this is how Emacs installs itself
> on all supported systems.  We just follow that on Windows, to be
> consistent with all the other systems.

To be fair, on *nix (where the current build and install system was
developed) emacs is a symlink to emacs-XX-Y, so there is no disk space
wasted. On Windows that's not the case.

Having multiple installed versions makes sense for Emacs developers and
for users who build from sources and don't want to delete the old
version before testing the new one. But for most users, who install
packaged binaries, it is not all that important.

I see little real application for that duplication on Windows and hardly
anybody will care about not having emacs.XX.Y.exe along with emacs.exe.
For many years that was the case and nobody complained AFAIK.

I don't really care about this duplication on Emacs, though, as it is
a comparatively minor offender. The lack of usable symlinks on Windows
makes certain packages to use more than 1 GB of disk space (without
debug info) when on GNU/Linux use a fraction of that, just because the
developers of those packages work on *nix and take symlinks for granted.

Re: Emacs 26.1 on Windows is HUGE

[Björn Lindqvist]

Den tis 16 apr. 2019 kl 22:54 skrev Óscar Fuentes <ofv@wanadoo.es>:
>
> Björn Lindqvist <bjourne@gmail.com> writes:
>
> >> Most likely the executables include debug information. It uses disk
> >> space but no RAM.
> >>
> >> On addition to that, one thing that makes little for this distribution
> >> is to include emacs.exe and emacs-26.1.exe, which are identical.
> >>
> >> BTW, 26.2 was just released, although the binary pretests on
> >>
> >> https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/
> >>
> >> have the same size.
> >>
> >> You can use `strip.exe' (from binutils) to remove the debug information.
> >
> > I tried that. I downloaded the strip.exe fom
> >
> > https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.28/
> >
> > But when running it on the binary:
> >
> >     > C:\code\langs\MingGW\bin\strip.exe -s emacs.exe
> >     C:\code\langs\MingGW\bin\strip.exe:emacs.exe: File format not recognized
>
> You have Emacs x86_64 and that "strip.exe" executable is for i686. That
> means that you have a 64 bits Emacs Windows executable but the strip.exe
> executable was configured for working on 32 bits executables.

I downloaded the 64bit MinGW (from here
https://sourceforge.net/projects/mingw-w64/)
and that strip.exe doesn't work either:

    >C:\code\langs\MingGW-64\mingw32\bin\strip.exe emacs.exe
    C:\code\langs\MingGW-64\mingw32\bin\strip.exe:emacs.exe: File
format not recognized


-- 
mvh/best regards Björn Lindqvist

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

On April 17, 2019 6:34:40 AM GMT+03:00, "Óscar Fuentes" <ofv@wanadoo.es> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Björn Lindqvist <bjourne@gmail.com>
> >> Date: Wed, 17 Apr 2019 00:18:27 +0200
> >> Cc: Óscar Fuentes <ofv@wanadoo.es>, help-gnu-emacs@gnu.org
> >> 
> >> As someone who don't use MSYS I don't understand the advantage of
> >> duplicating the files?
> >
> > This has nothing to do with MSYS.  It's for when you install the
> next
> > version, emacs.exe gets overwritten, but emacs-26.1.exe stays, and
> you
> > can still invoke it.  IOW, it allows you to have several Emacs
> > versions installed simultaneously.
> >
> > We didn't invent this for Windows, this is how Emacs installs itself
> > on all supported systems.  We just follow that on Windows, to be
> > consistent with all the other systems.
> 
> To be fair, on *nix (where the current build and install system was
> developed) emacs is a symlink to emacs-XX-Y, so there is no disk space
> wasted. On Windows that's not the case.
> 
> Having multiple installed versions makes sense for Emacs developers
> and
> for users who build from sources and don't want to delete the old
> version before testing the new one. But for most users, who install
> packaged binaries, it is not all that important.
> 
> I see little real application for that duplication on Windows and
> hardly
> anybody will care about not having emacs.XX.Y.exe along with
> emacs.exe.
> For many years that was the case and nobody complained AFAIK.
> 
> I don't really care about this duplication on Emacs, though, as it is
> a comparatively minor offender. The lack of usable symlinks on Windows
> makes certain packages to use more than 1 GB of disk space (without
> debug info) when on GNU/Linux use a fraction of that, just because the
> developers of those packages work on *nix and take symlinks for
> granted.

The build procedure creates a link on Windows as well.  If ln.exe used at build time supports symlinks, you get a symlink; but in most cases, that will be a hard link.  It doesn't really matter, since both avoid wasting disk space (actually, a hard link uses even less space than a symlink).

However, I think zip format on Windows doesn't support links.  Or maybe it's a problem with the version of zip.exe used to create the binary distribution.  So installation from zip ends up with 2 identical files.

You are entitled to your opinion regarding the usefulness of producing 2 names for the binary, but that is not a Windows specific problem.  As long as Emacs as a project does that, I see no good reasons to deviate from that practice only on Windows.

Re: Emacs 26.1 on Windows is HUGE

[Óscar Fuentes]

Björn Lindqvist <bjourne@gmail.com> writes:

>> >     > C:\code\langs\MingGW\bin\strip.exe -s emacs.exe
>> >     C:\code\langs\MingGW\bin\strip.exe:emacs.exe: File format not recognized
>>
>> You have Emacs x86_64 and that "strip.exe" executable is for i686. That
>> means that you have a 64 bits Emacs Windows executable but the strip.exe
>> executable was configured for working on 32 bits executables.
>
> I downloaded the 64bit MinGW (from here
> https://sourceforge.net/projects/mingw-w64/)
> and that strip.exe doesn't work either:
>
>     >C:\code\langs\MingGW-64\mingw32\bin\strip.exe emacs.exe
>     C:\code\langs\MingGW-64\mingw32\bin\strip.exe:emacs.exe: File
> format not recognized

You downloaded the 32bit MinGW-w64 toolset, as hinted by the "\mingw32\"
part on the path to strip.exe in your command line.

Despite its name, MinGW-w64 distributes both 32bit and 64bit toolsets.

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Lindqvist <bjourne@gmail.com>
>> Date: Wed, 17 Apr 2019 00:18:27 +0200
>> Cc: Óscar Fuentes <ofv@wanadoo.es>, help-gnu-emacs@gnu.org
>> 
>> As someone who don't use MSYS I don't understand the advantage of
>> duplicating the files?
>
> This has nothing to do with MSYS.  It's for when you install the next
> version, emacs.exe gets overwritten, but emacs-26.1.exe stays, and you
> can still invoke it.  IOW, it allows you to have several Emacs
> versions installed simultaneously.
>
> We didn't invent this for Windows, this is how Emacs installs itself
> on all supported systems.  We just follow that on Windows, to be
> consistent with all the other systems.


Yes, if you install them in the same location. But if you do the
suggested thing of unpacking them with "extract" from the file explorer
menu, each will get their own directory, so you will have
emacs-26.1/bin/emacs.exe and emacs-26.2/bin/emacs.exe.

How many people unpack one Emacs version over another? There isn't any
real advantage to doing so, unless you want to share files between the
two versions.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 17 Apr 2019 17:25:31 +0200
> Cc: help-gnu-emacs@gnu.org
> 
> >     >C:\code\langs\MingGW-64\mingw32\bin\strip.exe emacs.exe
> >     C:\code\langs\MingGW-64\mingw32\bin\strip.exe:emacs.exe: File
> > format not recognized
> 
> You downloaded the 32bit MinGW-w64 toolset, as hinted by the "\mingw32\"
> part on the path to strip.exe in your command line.

A nit: that doesn't necessarily mean anything, because a 32-bit build
of 'strip' could well support 64-bit PE executables.  It all depends
on how it was configured.  To know whether it does, say "strip --help"
and look at the list of supported targets at the end.  My 32-bit
binary says:

  strip: supported targets: pe-i386 pei-i386 elf32-i386 elf32-iamcu elf32-little elf32-big pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big plugin srec symbolsrec verilog tekhex binary ihex

See that pe-x86-64 stuff there?

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: help-gnu-emacs@gnu.org
> Date: Wed, 17 Apr 2019 16:28:54 +0100
> 
> > We didn't invent this for Windows, this is how Emacs installs itself
> > on all supported systems.  We just follow that on Windows, to be
> > consistent with all the other systems.
> 
> Yes, if you install them in the same location. But if you do the
> suggested thing of unpacking them with "extract" from the file explorer
> menu, each will get their own directory, so you will have
> emacs-26.1/bin/emacs.exe and emacs-26.2/bin/emacs.exe.

The Explorer lets you control the root directory where you extract the
files.  What you say above is only the default, if the user doesn't
change what Explorer suggests.

> How many people unpack one Emacs version over another? There isn't any
> real advantage to doing so, unless you want to share files between the
> two versions.

If you want to make the second binary optional, or remove it tell
people who want to keep the old version what do, it's entirely up to
you.  Since you are producing the binaries, you get to decide on these
details (and also to handle the complaints ;-).

I wrote the above to explain that this arrangement is not something
invented for Windows, it's how Emacs installs itself on all
platforms.

Re: Emacs 26.1 on Windows is HUGE

[Tomas Nordin]

Björn Lindqvist <bjourne@gmail.com> writes:

> As someone who don't use MSYS I don't understand the advantage of
> duplicating the files? You mentioned unzipping Emacs over an MSYS
> installation, but that seems a little odd. Usually on Windows you
> don't install software that way. But maybe for your use case you can
> use the larger emacs-26.1-x86_64.zip file? It includes a lot of
> dependencies like Python2.7, Sqlite 3.20, and OpenGL headers which I

Since it is mentioned, what is the possible depence on Python for the
emacs installation?

> don't understand what they are doing.
>
>> > I'm using old hardware with a small SSD which I'm happy with. I don't
>> > want to have to update my hardware to accommodate Emacs growing
>> > requirements.

Happy Easter
--
Tomas

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Tomas Nordin <tomasn@posteo.net> writes:

> Björn Lindqvist <bjourne@gmail.com> writes:
>
>> As someone who don't use MSYS I don't understand the advantage of
>> duplicating the files? You mentioned unzipping Emacs over an MSYS
>> installation, but that seems a little odd. Usually on Windows you
>> don't install software that way. But maybe for your use case you can
>> use the larger emacs-26.1-x86_64.zip file? It includes a lot of
>> dependencies like Python2.7, Sqlite 3.20, and OpenGL headers which I
>
> Since it is mentioned, what is the possible depence on Python for the
> emacs installation?


I don't know. I calculate the dependencies based on the metadata from
msys. You can see the code at admin/nt/dist-build/build-deps-zips.py and
work out where this comes from.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Tomas Nordin]

Phillip Lord <phillip.lord@russet.org.uk> writes:

> Tomas Nordin <tomasn@posteo.net> writes:
>
>> Björn Lindqvist <bjourne@gmail.com> writes:
>>
>>> As someone who don't use MSYS I don't understand the advantage of
>>> duplicating the files? You mentioned unzipping Emacs over an MSYS
>>> installation, but that seems a little odd. Usually on Windows you
>>> don't install software that way. But maybe for your use case you can
>>> use the larger emacs-26.1-x86_64.zip file? It includes a lot of
>>> dependencies like Python2.7, Sqlite 3.20, and OpenGL headers which I
>>
>> Since it is mentioned, what is the possible depence on Python for the
>> emacs installation?
>
>
> I don't know. I calculate the dependencies based on the metadata from
> msys. You can see the code at admin/nt/dist-build/build-deps-zips.py and
> work out where this comes from.

I had a look and couldn't work it out from there, but it doesn't really
matter. I was just a bit surprised at work some time ago when I upgraded
to emacs 26 and got Python into the bargain. I do understand the need
for Python to run that script though :)

Have a nice evening
--
Tomas

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Tomas Nordin <tomasn@posteo.net> writes:

> Phillip Lord <phillip.lord@russet.org.uk> writes:
>
>> Tomas Nordin <tomasn@posteo.net> writes:
>>
>>> Björn Lindqvist <bjourne@gmail.com> writes:
>>>
>>>> As someone who don't use MSYS I don't understand the advantage of
>>>> duplicating the files? You mentioned unzipping Emacs over an MSYS
>>>> installation, but that seems a little odd. Usually on Windows you
>>>> don't install software that way. But maybe for your use case you can
>>>> use the larger emacs-26.1-x86_64.zip file? It includes a lot of
>>>> dependencies like Python2.7, Sqlite 3.20, and OpenGL headers which I
>>>
>>> Since it is mentioned, what is the possible depence on Python for the
>>> emacs installation?
>>
>>
>> I don't know. I calculate the dependencies based on the metadata from
>> msys. You can see the code at admin/nt/dist-build/build-deps-zips.py and
>> work out where this comes from.
>
> I had a look and couldn't work it out from there, but it doesn't really
> matter. I was just a bit surprised at work some time ago when I upgraded
> to emacs 26 and got Python into the bargain. I do understand the need
> for Python to run that script though :)


Well, I was curious enough to look it up -- it's librsvg which has three
python scripts as part of it. Whether it actually uses them or not I
don't know. And, it is this that brings in lots of other things,
including, for example, bzip2.

There would be some justification for excluding it, but it's a slippery
slope. There is also justification of adding things.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Fri, 26 Apr 2019 17:22:45 +0100
> Cc: Óscar Fuentes <ofv@wanadoo.es>, help-gnu-emacs@gnu.org,
> 	Björn Lindqvist <bjourne@gmail.com>
> 
> Well, I was curious enough to look it up -- it's librsvg which has three
> python scripts as part of it. Whether it actually uses them or not I
> don't know. And, it is this that brings in lots of other things,
> including, for example, bzip2.

Maybe report that to the MSYS2 packagers.  It's IMO wrong to consider
every package that comes with a few Python script not essential to its
functionality to be dependent on Python.

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Date: Fri, 26 Apr 2019 17:22:45 +0100
>> Cc: Óscar Fuentes <ofv@wanadoo.es>, help-gnu-emacs@gnu.org,
>> 	Björn Lindqvist <bjourne@gmail.com>
>> 
>> Well, I was curious enough to look it up -- it's librsvg which has three
>> python scripts as part of it. Whether it actually uses them or not I
>> don't know. And, it is this that brings in lots of other things,
>> including, for example, bzip2.
>
> Maybe report that to the MSYS2 packagers.  It's IMO wrong to consider
> every package that comes with a few Python script not essential to its
> functionality to be dependent on Python.

Hmmm. Actually, it's indirect, via libglib2.

The dependency was added deliberately in this commit.

d394f202ab275d931f9408c68a4dc1fa95ad723c

viewable here:

https://github.com/msys2/MINGW-packages/commit/d394f202ab275d931f9408c68a4dc1fa95ad723c#diff-4edc48d8f1e38f841d1aa74999389b6e

A priori, I am a bit surprised this is a runtime rather than build time
dependency, or possibly the dependency on python should be in
gobject-introspection only. Adding a python dependency to glib seems
quite a blunt solution. But my knowledge in this is limited to say the
least. What do think, Eli? Worth reporting?


Phil

Re: Emacs 26.1 on Windows is HUGE

[Óscar Fuentes]

phillip.lord@russet.org.uk (Phillip Lord) writes:

>> Maybe report that to the MSYS2 packagers.  It's IMO wrong to consider
>> every package that comes with a few Python script not essential to its
>> functionality to be dependent on Python.
>
> Hmmm. Actually, it's indirect, via libglib2.
>
> The dependency was added deliberately in this commit.
>
> d394f202ab275d931f9408c68a4dc1fa95ad723c
>
> viewable here:
>
> https://github.com/msys2/MINGW-packages/commit/d394f202ab275d931f9408c68a4dc1fa95ad723c#diff-4edc48d8f1e38f841d1aa74999389b6e
>
> A priori, I am a bit surprised this is a runtime rather than build time
> dependency, or possibly the dependency on python should be in
> gobject-introspection only. Adding a python dependency to glib seems
> quite a blunt solution. But my knowledge in this is limited to say the
> least. What do think, Eli? Worth reporting?

On that URL an user asked about the dependency on python, no response.

MSYS2 is strongly influenced by Archlinux. Although MSYS2 is quite
sloppy about dependencies (among other things) Archlinux is a differente
beast, and on its PKGBUILD (1) for glib2 python is listed on
`makedepends' and `optdepends', not on `depends'. For me, that warrants
a report. Better, create a PR moving python to `makedepends' and
`optdepends' and CC the author of the commit you referred to on the PR
message.

But... don't expect that MSYS2 makes changes to adapt to your specific
needs. Creating an stand-alone distribution of Emacs is not the same as
managing packages in MSYS2. For instance: as you know, lib* packages in
MSYS2 comes with binaries + development files (.a & *.h ...) while
distributing those with Emacs is dubious. You already remove them from
your zipfiles, why don't do the same with python? BTW, since MSYS2 is
sloppy with dependencies, you can't rely on them for making sure that
everything is included.

And on different topic, did you test that C-h i works as it should? Does
it show the Emacs info files? There is a long-standing problem with
Emacs on MSYS2 about this, although IIRC only happens when you install
Emacs as an MSYS2 package. But since testing it only takes a few
seconds... (I can't test myself, computer attracted lightning)


1 https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/glib2

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: help-gnu-emacs@gnu.org
> Date: Fri, 26 Apr 2019 21:59:08 +0100
> 
> > Maybe report that to the MSYS2 packagers.  It's IMO wrong to consider
> > every package that comes with a few Python script not essential to its
> > functionality to be dependent on Python.
> 
> Hmmm. Actually, it's indirect, via libglib2.
> 
> The dependency was added deliberately in this commit.
> 
> d394f202ab275d931f9408c68a4dc1fa95ad723c
> 
> viewable here:
> 
> https://github.com/msys2/MINGW-packages/commit/d394f202ab275d931f9408c68a4dc1fa95ad723c#diff-4edc48d8f1e38f841d1aa74999389b6e
> 
> A priori, I am a bit surprised this is a runtime rather than build time
> dependency, or possibly the dependency on python should be in
> gobject-introspection only.

I think it should be a build-time dependency, indeed.

> Adding a python dependency to glib seems quite a blunt solution.


> But my knowledge in this is limited to say the least. What do think,
> Eli? Worth reporting?

I think you are exactly right.  There's already a question to that
effect from another user in that issue, and it didn't get any response
AFAICS.  Perhaps showing them the bloat in the Emacs distribution due
to this could change their minds.

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

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

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>>> Maybe report that to the MSYS2 packagers.  It's IMO wrong to consider
>>> every package that comes with a few Python script not essential to its
>>> functionality to be dependent on Python.
>>
>> Hmmm. Actually, it's indirect, via libglib2.
>>
>> The dependency was added deliberately in this commit.
>>
>> d394f202ab275d931f9408c68a4dc1fa95ad723c
>>
>> viewable here:
>>
>> https://github.com/msys2/MINGW-packages/commit/d394f202ab275d931f9408c68a4dc1fa95ad723c#diff-4edc48d8f1e38f841d1aa74999389b6e
>>
>> A priori, I am a bit surprised this is a runtime rather than build time
>> dependency, or possibly the dependency on python should be in
>> gobject-introspection only. Adding a python dependency to glib seems
>> quite a blunt solution. But my knowledge in this is limited to say the
>> least. What do think, Eli? Worth reporting?
>
> On that URL an user asked about the dependency on python, no response.
>
> MSYS2 is strongly influenced by Archlinux. Although MSYS2 is quite
> sloppy about dependencies (among other things) Archlinux is a differente
> beast, and on its PKGBUILD (1) for glib2 python is listed on
> `makedepends' and `optdepends', not on `depends'. For me, that warrants
> a report. Better, create a PR moving python to `makedepends' and
> `optdepends' and CC the author of the commit you referred to on the PR
> message.

Well, we shall see -- I have put in a comment.


> But... don't expect that MSYS2 makes changes to adapt to your specific
> needs. Creating an stand-alone distribution of Emacs is not the same as
> managing packages in MSYS2. For instance: as you know, lib* packages in
> MSYS2 comes with binaries + development files (.a & *.h ...) while
> distributing those with Emacs is dubious. You already remove them from
> your zipfiles, why don't do the same with python?

No, I don't. I put in all the files that are declared as part of the
dependency package.

I could detect and remove specific dependencies, or with a bit more
work, remove a part of the dependency tree. But I rather not go down the
path of maintaining a metadata list for msys2 independtly.

> BTW, since MSYS2 is sloppy with dependencies, you can't rely on them
> for making sure that everything is included.

So far, I have had no bug reports about this, just the opposite -- that
too much is included. And some requests to add other things. I'm just
not convinced that effectively producing a seperate minimal MSYS2
distribution is where I want to go. For people who want a lot more or
less, installing msys2 independently and then droppping the no-deps
package on top seems the way to go.


> And on different topic, did you test that C-h i works as it should? Does
> it show the Emacs info files? There is a long-standing problem with
> Emacs on MSYS2 about this, although IIRC only happens when you install
> Emacs as an MSYS2 package. But since testing it only takes a few
> seconds... (I can't test myself, computer attracted lightning)

Hmmm. Sort of. If you click runemacs.exe from the windows explorer it
works. If you launch it from a mingw64 shell, no, it doesn't. Or rather
it works, but you get the msys info which doesn't link to Emacs.

I am rather dependent here on people filling bugs; I don't actually use
Emacs on windows, just build it.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Eli Zaretskii <eliz@gnu.org>,  help-gnu-emacs@gnu.org
> Date: Sat, 27 Apr 2019 12:17:40 +0100
> 
> > And on different topic, did you test that C-h i works as it should? Does
> > it show the Emacs info files? There is a long-standing problem with
> > Emacs on MSYS2 about this, although IIRC only happens when you install
> > Emacs as an MSYS2 package. But since testing it only takes a few
> > seconds... (I can't test myself, computer attracted lightning)
> 
> Hmmm. Sort of. If you click runemacs.exe from the windows explorer it
> works. If you launch it from a mingw64 shell, no, it doesn't. Or rather
> it works, but you get the msys info which doesn't link to Emacs.

Doesn't surprise me, since MSYS2 doesn't have a native Windows port of
Texinfo, so the place they put the manuals probably only works for
MSYS itself.  Does the shell set INFOPATH, perhaps?  If not, in which
directory do the MSYS Info files get installed, relative to the root
of the MSYS installation tree?

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: Eli Zaretskii <eliz@gnu.org>,  help-gnu-emacs@gnu.org
>> Date: Sat, 27 Apr 2019 12:17:40 +0100
>> 
>> > And on different topic, did you test that C-h i works as it should? Does
>> > it show the Emacs info files? There is a long-standing problem with
>> > Emacs on MSYS2 about this, although IIRC only happens when you install
>> > Emacs as an MSYS2 package. But since testing it only takes a few
>> > seconds... (I can't test myself, computer attracted lightning)
>> 
>> Hmmm. Sort of. If you click runemacs.exe from the windows explorer it
>> works. If you launch it from a mingw64 shell, no, it doesn't. Or rather
>> it works, but you get the msys info which doesn't link to Emacs.
>
> Doesn't surprise me, since MSYS2 doesn't have a native Windows port of
> Texinfo, so the place they put the manuals probably only works for
> MSYS itself.  Does the shell set INFOPATH, perhaps?  If not, in which
> directory do the MSYS Info files get installed, relative to the root
> of the MSYS installation tree?


It does, yes, so Emacs is just doing what it is told. I guess Emacs
could ignore INFOPATH or just use it as a supplement its own files,
given that it knows their location.


Phil

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: help-gnu-emacs@gnu.org
> Date: Mon, 29 Apr 2019 14:55:10 +0100
> 
> It does, yes, so Emacs is just doing what it is told. I guess Emacs
> could ignore INFOPATH or just use it as a supplement its own files,
> given that it knows their location.

That'd be against the Texinfo documentation.  What MSYS should have
done is end INFOPATH with a semi-colon, which should cause the
built-in defaults be appended to the value.  It is IMO extremely rude
to override the end-user's INFOPATH setting in this way.

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: help-gnu-emacs@gnu.org
>> Date: Mon, 29 Apr 2019 14:55:10 +0100
>> 
>> It does, yes, so Emacs is just doing what it is told. I guess Emacs
>> could ignore INFOPATH or just use it as a supplement its own files,
>> given that it knows their location.
>
> That'd be against the Texinfo documentation.  What MSYS should have
> done is end INFOPATH with a semi-colon, which should cause the
> built-in defaults be appended to the value.  It is IMO extremely rude
> to override the end-user's INFOPATH setting in this way.

I will have a poke around and see if I can find out where this is set
for msys.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 30 Apr 2019 10:48:22 +0100
> 
> > That'd be against the Texinfo documentation.  What MSYS should have
> > done is end INFOPATH with a semi-colon, which should cause the
> > built-in defaults be appended to the value.  It is IMO extremely rude
> > to override the end-user's INFOPATH setting in this way.
> 
> I will have a poke around and see if I can find out where this is set
> for msys.

Regardless, I think this should be reported to MSYS, because they need
to fix it.

Re: Emacs 26.1 on Windows is HUGE

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I will have a poke around and see if I can find out where this is set
>> for msys.
>
> Regardless, I think this should be reported to MSYS, because they need
> to fix it.

https://github.com/msys2/MINGW-packages/issues/631

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 30 Apr 2019 17:35:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I will have a poke around and see if I can find out where this is set
> >> for msys.
> >
> > Regardless, I think this should be reported to MSYS, because they need
> > to fix it.
> 
> https://github.com/msys2/MINGW-packages/issues/631

Wow, 4 years!

I think they should be told about the trailing colon feature, maybe
that will help them fix the problem.  Or not.

Thanks.

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Tue, 30 Apr 2019 17:35:45 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> I will have a poke around and see if I can find out where this is set
>> >> for msys.
>> >
>> > Regardless, I think this should be reported to MSYS, because they need
>> > to fix it.
>> 
>> https://github.com/msys2/MINGW-packages/issues/631
>
> Wow, 4 years!
>
> I think they should be told about the trailing colon feature, maybe
> that will help them fix the problem.  Or not.


Or not, am afraid.

The fix is very simple. INFOPATH is set in /etc/profile.

https://github.com/msys2/MSYS2-packages/blob/master/filesystem/profile

But, Emacs will ignore the final colon regardless. The code is
below. The problem is we match against path-separator which is ";" not
":", so we never do the `append'.

(defun info-initialize ()
  "Initialize `Info-directory-list', if that hasn't been done yet."
  (unless Info-directory-list
    (let ((path (getenv "INFOPATH"))
	  (sep (regexp-quote path-separator)))
      (setq Info-directory-list
	    (prune-directory-list
	     (if path
		 (if (string-match-p (concat sep "\\'") path)
		     (append (split-string (substring path 0 -1) sep)
			     (Info-default-dirs))
		   (split-string path sep))
	       (Info-default-dirs))))
   ......SNIP


This follows the info documentation which says:

  However you set INFOPATH, if its last character is a colon (on
  MS-DOS/MS-Windows systems, use a semicolon instead), this is replaced
  by the default (compiled-in) path. This gives you a way to augment the
  default path with new directories without having to list all the
  standard places.

Both Emacs and the Info documentation are wrong, I think, since they
assume the path seperator for environment variables on MS-Windows
systems in ";" which isn't true in general.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: help-gnu-emacs@gnu.org
> Date: Tue, 30 Apr 2019 22:13:57 +0100
> 
> >> https://github.com/msys2/MINGW-packages/issues/631
> >
> > Wow, 4 years!
> >
> > I think they should be told about the trailing colon feature, maybe
> > that will help them fix the problem.  Or not.
> 
> 
> Or not, am afraid.
> 
> The fix is very simple. INFOPATH is set in /etc/profile.

And /etc/profile didn't come with the MSYS installation?  It's a file
you concocted?  If the file comes with the installation, then MSYS are
the ones who need to fix it.

> But, Emacs will ignore the final colon regardless. The code is
> below. The problem is we match against path-separator which is ";" not
> ":", so we never do the `append'.

??? You mean MSYS2 Bash doesn't convert the colons to semi-colons (and
the /d/foo/bar file names to Windows d:\foo\bar) when they pass
INFOPATH to native MS-Windows programs?  That's a terrible bug.  Doing
these conversions are the main reason for MSYS existence, and the main
difference between it and Cygwin.

Do they perform these conversion on PATH?

>   However you set INFOPATH, if its last character is a colon (on
>   MS-DOS/MS-Windows systems, use a semicolon instead), this is replaced
>   by the default (compiled-in) path. This gives you a way to augment the
>   default path with new directories without having to list all the
>   standard places.
> 
> Both Emacs and the Info documentation are wrong, I think, since they
> assume the path seperator for environment variables on MS-Windows
> systems in ";" which isn't true in general.

No, the path separator on Windows is _always_ semi-colon.  Emacs and
our docs are right, and MSYS should be fixed.

Re: Emacs 26.1 on Windows is HUGE

[Eli Zaretskii]

On May 1, 2019 5:43:06 AM GMT+03:00, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: phillip.lord@russet.org.uk (Phillip Lord)
> > Cc: help-gnu-emacs@gnu.org
> > Date: Tue, 30 Apr 2019 22:13:57 +0100
> > 
> > >> https://github.com/msys2/MINGW-packages/issues/631
> > >
> > > Wow, 4 years!
> > >
> > > I think they should be told about the trailing colon feature,
> maybe
> > > that will help them fix the problem.  Or not.
> > 
> > 
> > Or not, am afraid.
> > 
> > The fix is very simple. INFOPATH is set in /etc/profile.
> 
> And /etc/profile didn't come with the MSYS installation?  It's a file
> you concocted?  If the file comes with the installation, then MSYS are
> the ones who need to fix it.
> 
> > But, Emacs will ignore the final colon regardless. The code is
> > below. The problem is we match against path-separator which is ";"
> not
> > ":", so we never do the `append'.
> 
> ??? You mean MSYS2 Bash doesn't convert the colons to semi-colons (and
> the /d/foo/bar file names to Windows d:\foo\bar) when they pass
> INFOPATH to native MS-Windows programs?  That's a terrible bug.  Doing
> these conversions are the main reason for MSYS existence, and the main
> difference between it and Cygwin.



I just checked, and MSYS does perform this conversion, both on INFOPATH and on any other FOOPATH variable that looks like a list of directories.

So INFOPATH should look in MinGW Emacs as expected, separated by semi-colons.  If it doesn't happen for you, there's some other factor at work here.

INFOPATH on MSYS(2) (WAS: Emacs 26.1 on Windows is HUGE)

[Noam Postavsky]

On Wed, 1 May 2019 at 00:04, Eli Zaretskii <eliz@gnu.org> wrote:

> > ??? You mean MSYS2 Bash doesn't convert the colons to semi-colons (and
> > the /d/foo/bar file names to Windows d:\foo\bar) when they pass
> > INFOPATH to native MS-Windows programs?  That's a terrible bug.  Doing
> > these conversions are the main reason for MSYS existence, and the main
> > difference between it and Cygwin.

> I just checked, and MSYS does perform this conversion, both on INFOPATH and on any other FOOPATH variable that looks like a list of directories.
>
> So INFOPATH should look in MinGW Emacs as expected, separated by semi-colons.  If it doesn't happen for you, there's some other factor at work here.
>

It seems that it does perform the conversion, but in doing so drops
the the trailing colon.

$ export INFOPATH=/c/foo:/c/bar:
$ emacs -Q --batch --eval '(print (getenv "INFOPATH"))'
"C:\\foo;C:\\bar"

Re: INFOPATH on MSYS(2) (WAS: Emacs 26.1 on Windows is HUGE)

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Wed, 1 May 2019 10:22:08 -0400
> Cc: Help Gnu Emacs mailing list <help-gnu-emacs@gnu.org>
> 
> > I just checked, and MSYS does perform this conversion, both on INFOPATH and on any other FOOPATH variable that looks like a list of directories.
> >
> > So INFOPATH should look in MinGW Emacs as expected, separated by semi-colons.  If it doesn't happen for you, there's some other factor at work here.
> >
> 
> It seems that it does perform the conversion, but in doing so drops
> the the trailing colon.
> 
> $ export INFOPATH=/c/foo:/c/bar:
> $ emacs -Q --batch --eval '(print (getenv "INFOPATH"))'
> "C:\\foo;C:\\bar"

That's a bug that should be reported, but Phillip said the situation
was much worse.

Re: INFOPATH on MSYS(2)

[Phillip Lord]

Noam Postavsky <npostavs@gmail.com> writes:

> On Wed, 1 May 2019 at 00:04, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > ??? You mean MSYS2 Bash doesn't convert the colons to semi-colons (and
>> > the /d/foo/bar file names to Windows d:\foo\bar) when they pass
>> > INFOPATH to native MS-Windows programs?  That's a terrible bug.  Doing
>> > these conversions are the main reason for MSYS existence, and the main
>> > difference between it and Cygwin.
>
>> I just checked, and MSYS does perform this conversion, both on INFOPATH and on any other FOOPATH variable that looks like a list of directories.
>>
>> So INFOPATH should look in MinGW Emacs as expected, separated by semi-colons.  If it doesn't happen for you, there's some other factor at work here.
>>
>
> It seems that it does perform the conversion, but in doing so drops
> the the trailing colon.
>
> $ export INFOPATH=/c/foo:/c/bar:
> $ emacs -Q --batch --eval '(print (getenv "INFOPATH"))'
> "C:\\foo;C:\\bar"


Yes, apologies, my last email was nonsense. Running "export" in a
mingw64 we see

declare -x INFOPATH="/usr/local/info:/usr/share/info:/usr/info:/share/info:"


Running export in a shell inside Emacs we see.

declare -x INFOPATH="C:\\msys64\\usr\\local\\info;C:\\msys64\\usr\\share\\info;C:\\msys64\\usr\\info;C:\\msys64\\share\\info"

Final ":" gone, hence Emacs never appends its own info files.

No idea where this is caused and it's a lot harder to chase down than
setting the INFOPATH.

Phil

Re: INFOPATH on MSYS(2)

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Eli Zaretskii <eliz@gnu.org>,  Help Gnu Emacs mailing list <help-gnu-emacs@gnu.org>
> Date: Wed, 01 May 2019 23:07:53 +0100
> 
> Yes, apologies, my last email was nonsense. Running "export" in a
> mingw64 we see
> 
> declare -x INFOPATH="/usr/local/info:/usr/share/info:/usr/info:/share/info:"
> 
> 
> Running export in a shell inside Emacs we see.
> 
> declare -x INFOPATH="C:\\msys64\\usr\\local\\info;C:\\msys64\\usr\\share\\info;C:\\msys64\\usr\\info;C:\\msys64\\share\\info"
> 
> Final ":" gone, hence Emacs never appends its own info files.
> 
> No idea where this is caused and it's a lot harder to chase down than
> setting the INFOPATH.

It no doubt happens in the same code which converts paths to their
Windows format.  Someone decided that trailing colons are a mistake of
sorts that needs to be "fixed".  Or maybe it's just an unintended
consequence of how the code was written, with this special use case
unaccounted for.

In any case, this is a bug that should be reported, IMO.

Re: Emacs 26.1 on Windows is HUGE

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Tue, 30 Apr 2019 17:35:45 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> I will have a poke around and see if I can find out where this is set
>> >> for msys.
>> >
>> > Regardless, I think this should be reported to MSYS, because they need
>> > to fix it.
>> 
>> https://github.com/msys2/MINGW-packages/issues/631
>
> Wow, 4 years!
>
> I think they should be told about the trailing colon feature, maybe
> that will help them fix the problem.  Or not.
>

I've updated the bug report. It looks like msys2 has more bug reports
than they can cope with unfortunately.

Phil

Re: Emacs 26.1 on Windows is HUGE

[Óscar Fuentes]

phillip.lord@russet.org.uk (Phillip Lord) writes:

>>> > Regardless, I think this should be reported to MSYS, because they need
>>> > to fix it.
>>> 
>>> https://github.com/msys2/MINGW-packages/issues/631
>>
>> Wow, 4 years!
>>
>> I think they should be told about the trailing colon feature, maybe
>> that will help them fix the problem.  Or not.
>>
>
> I've updated the bug report. It looks like msys2 has more bug reports
> than they can cope with unfortunately.

The bug report you updated is not for MSYS2 proper but for
MINGW-packages. No big problem because the people who can fix the bug
monitors both lists.

It is not surprising that the bugs pile up when a project deals with
several thousand packages and the team consists on 1+epsilon members.