[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs 26.1 on Windows is HUGE

From: Phillip Lord
Subject: Re: Emacs 26.1 on Windows is HUGE
Date: Tue, 16 Apr 2019 22:19:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.92 (gnu/linux)

Björn Lindqvist <> 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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]