emacs-devel
[Top][All Lists]
Advanced

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

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


From: Wayne Harris
Subject: Re: [feature/internal-msys] thoughts of a more function windows package
Date: Tue, 20 Apr 2021 11:38:47 -0300

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

> Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com> writes:
>
>> Sorry for late reply, but I think that while bundling msys2 is a good
>> idea in theory, in practice it would turn into a complete
>> nightmare. The problem, just like with bundling any third party
>> components is that you have to maintain them. If you bundle the latest
>> and shiniest msys2, you can never be sure if it's really properly
>> working for our use cases. And if you bundle some pretested version,
>> you run into "hey, please fix bug A, the upstream has already fixed
>> it", but we can't switch to upstream due to bug B.
>>
>> Msys2 sort of missed the boat in that they took pacman, but didn't
>> bother with making their own AUR.
>
> The work on this has stalled at the moment anyway, but my plan would be
> to work out how to link an Emacs installation to an Msys2 installation,
> by setting up paths correctly, as well as defining a set of packages
> that are useful for Emacs.
>
> There is always the risk that msys and Emacs work inconsistently since,
> with this scenario, msys could update at any point that breaks things. I
> don't think that there is any solution to this than to say that the last
> release version of Emacs will work with a version of msys which is about
> current at the time of release. What else can we do? In the case, that
> basic Emacs functionality fails, people could always fall back to the
> fully bundled Emacs with DLLs that is currently available.
>
> The current situation where Emacs without msys2 lacks basic capabilities
> such as git handling which many other editors have bundled is also
> problematic!

(*) Introduction

I'll share my opinion as a user of the GNU Emacs and Windows.  I'll try
to summarize my context to help you decide whether it's worth reading
the entire message.  Maybe the context of this thread is a bit off of
mine, so perhaps the difficulties I mention don't quite apply to what
Phillip Lord is considering.

(*) Summary

Unless this coupling Emacs-MSYS2 can be well done with a certain
long-run guarantee, I'd still prefer put them together with my own
hands, because this way I can guarantee the behavior of the programs I
expect to get.  So I think I'd need an assurance of always having a
certain exact (verified with a hash sum) version of msys2.

I guarantee this today myself by zipping my GNU Emacs directory and
moving it to another system when something happens that I need to move,
say when my computer crashes and I need to install another Windows.  My
guarantee is based on Windows' guarantee of backward compatibility and
behavior stability, which is why I have to run Windows.

(*) I manually put msys2 inside Emacs

--8<---------------cut here---------------start------------->8---
%pwd
c:/sys/emacs/usr/mingw

%file msys2.exe
msys2.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS 
Windows
--8<---------------cut here---------------end--------------->8---

Having discovered msys2 recently I immediately convinced myself to
reorganize my GNU Emacs to use msys2.  (Until then I was using a 32-bit
GNU Emacs and installed my own selections of Eli Zaretskii's ezwinports
--- they have been useful to me for various years. Thank you!)  I now
consider msys2 part of my GNU Emacs.

(*) Tangent 1: Windows was my last resort

Running Windows is not something that pleases me.  I'd much rather run
WindowMaker, say, to manage my windows, but I feel I'm stuck with
Windows because GNU systems don't help me with keeping all I need in a
single directory with an assurance that I can move that directory to a
similar system and still have everything work.

This is not a compliment to Windows.  If GNU systems did not come with
all of their variety and openess and freedom, I'm sure they could
provide the same status quo provided by Windows.

As I understand it, the core of issue here is what Torvalds calls the
``binary issue'' while answering these questions:

  https://youtu.be/5PmHRSeA2c8?t=1722
  https://youtu.be/5PmHRSeA2c8?t=2473
  
So, I'm lucky in that the programs I need are all well-designed and can
be easily ported from one system to another without requiring
reinstallations and reconfigurations, otherwise Windows would also be a
non-solution.  For instance, if Chrome or Word were software I need,
then Windows would be a non-solution.

(*) Tangent 2: I need long-term assurance

As an example, I've built my own OpenBSD distribution because I wanted
an assurance in the behavior of the system, besides a quick
installation.  I install it with a single command line and it asks no
questions.  It comes ready to do all the things *I* usually do.  The
source code of everything is exactly where I expect it to be and so on.
It allows me to quickly do all the experiments I do with a minimum of
technological struggle.  (Let me know if anyone would like a copy of
such thing, by the way.  It's OpenBSD 4.5, source code included.  Sadly,
I didn't include the GNU Emacs, though my notes say that was the very
next step.)




reply via email to

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