[Top][All Lists]

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

Re: [feature/internal-msys] thoughts of a more function windows package

From: Phillip Lord
Subject: Re: [feature/internal-msys] thoughts of a more function windows package
Date: Fri, 22 Jan 2021 16:14:33 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Phillip Lord <phillip.lord@russet.org.uk>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 21 Jan 2021 21:37:57 +0000
>> Yep, it's big. I get this before installation:
>> 319 MB (335,214,637 bytes)
>> and this after installation.
>> 826 MB (866,624,644 bytes)
>> My guess is that it's the co-install of perl that is causing this issue
>> rather than vim.
> It's Vim, and Perl, and Tcl.  And at some point I'd expect them to
> include Python as well, to support those Git commands which rely on
> it.

Yep, they don't ship a "git-core" without all this baggage

>> But, openssh comes for free with this. And "huge" is a
>> relative term. An installation under 1Gb seems reasonable to me.
> I thought this started as an attempt to make the Emacs installation
> smaller...
> If the rationale is to provide a full development environment on top
> of MS-Windows, then indeed the size will be much larger, and you will
> need to include a lot of packages there.  Just be sure to spell this
> out (including the size, perhaps) when you ask the user whether he or
> she wants to install that.

Yes, a small install for easy downloads, but with the option for a
bigger one. The small install is still important, though, because it
will also mean a small upgrade from one emacs to the next.

>> > Next, by "msys" you mean all those non-native programs that depend on
>> > msys-1.0.dll?  That's again meant for MinGW developers, not "normal"
>> > users.
>> Yes. Because it's got all the packages and tools and as far as I can
>> see, they work with Emacs.
> They mostly work, until they don't.  Like with Cygwin, there are
> subtle incompatibilities, mainly in file names and in communications
> with subprocesses and response to "signals".  Encoding defaults are
> also different.

That's true for the msys2 commands but not the mingw64 ones? In the end,
not all of the tools need for Emacs are in mingw64 part of msys2 and
msys2 comes with pacman.

>> > (Btw, pacman can ask questions and prompt the user for confirmation,
>> > but the way you invoke it in w32-msys-run doesn't seem to be prepared
>> > for such interaction?)
>> That's why I use "--no-confirm". I'm looking for the minimum here that
>> does something usable.
> What happens when pacman wants to replace Bash from which it was
> launched, or update itself or some of its component DLLs?

That happens straight away on first launch. I don't know yet, but am
working on it.

>> > I think the only good idea here is to tell the user to amend PATH by
>> > adding such-and-such directories to it.  I don't like installers that
>> > futz with my PATH, and would hate it if Emacs did that to others.
>> > It's very easy to get that wrong, especially on Windows.
>> There has to be a better way that this.
> The only way I know of is to distribute a program that writes into the
> Registry.  Don't forget that there are system-wide variables and
> variables specific to the current user.  And some systems have the
> former locked down and the latter requires a UAC elevation.  Good luck
> (you will need it) with successfully negotiating all these obstacles.

Would it be easier to have Emacs allow me to successfully update PATH
during run?


reply via email to

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