From: Wayne Harris via "Emacs development discussions." <emacs-devel@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: [feature/internal-msys] thoughts of a more function windows package
Date: Tue, 20 Apr 2021 11:38:47 -0300 [thread overview]
Message-ID: <86o8e9kolk.fsf@protonmail.com> (raw)
In-Reply-To: 87y2dd8g04.fsf@russet.org.uk
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.)
next prev parent reply other threads:[~2021-04-20 14:38 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-09 19:57 [feature/dll-only-windows] A new windows build, comments wanted Phillip Lord
2021-01-09 20:18 ` Eli Zaretskii
2021-01-09 21:31 ` Phillip Lord
2021-01-10 8:49 ` Arash Esbati
2021-01-10 15:19 ` Phillip Lord
2021-01-10 16:45 ` Eli Zaretskii
2021-01-10 18:23 ` Phillip Lord
2021-01-10 19:05 ` Eli Zaretskii
2021-01-10 19:20 ` Óscar Fuentes
2021-01-10 19:37 ` Eli Zaretskii
2021-01-10 20:52 ` `gzip` dependency (was: [feature/dll-only-windows] A new windows build, comments wanted) Stefan Monnier
2021-01-11 3:27 ` Eli Zaretskii
2021-01-11 10:00 ` `gzip` dependency Phillip Lord
2021-01-11 15:22 ` Eli Zaretskii
2021-01-11 14:59 ` Stefan Monnier
2021-01-11 15:15 ` Phillip Lord
2021-01-11 15:46 ` Eli Zaretskii
2021-01-20 19:29 ` [feature/internal-msys] thoughts of a more function windows package Phillip Lord
2021-01-21 12:36 ` Stephen Leake
2021-01-21 16:11 ` Phillip Lord
2021-01-21 18:22 ` Stephen Leake
2021-01-21 18:44 ` phillip.lord
2021-01-23 2:51 ` Stephen Leake
2021-01-21 18:53 ` Óscar Fuentes
2021-01-21 14:11 ` Eli Zaretskii
2021-01-21 16:44 ` Phillip Lord
2021-01-21 20:17 ` Eli Zaretskii
2021-01-21 21:37 ` Phillip Lord
2021-01-22 7:24 ` Eli Zaretskii
2021-01-22 16:14 ` Phillip Lord
2021-01-22 17:03 ` Eli Zaretskii
2021-01-24 22:13 ` Phillip Lord
2021-01-24 22:56 ` Óscar Fuentes
2021-01-24 23:34 ` Phillip Lord
2021-01-25 0:12 ` Óscar Fuentes
2021-01-25 15:24 ` Eli Zaretskii
2021-01-25 19:49 ` chad
2021-01-25 19:57 ` Eli Zaretskii
2021-01-25 20:42 ` Stefan Monnier
2021-01-25 22:13 ` chad
2021-01-25 22:28 ` Dmitry Gutov
2021-01-26 3:26 ` Eli Zaretskii
2021-01-25 15:20 ` Eli Zaretskii
2021-01-25 20:01 ` Richard Copley
2021-01-25 21:17 ` Óscar Fuentes
2021-01-26 3:29 ` Eli Zaretskii
2021-01-26 5:43 ` Óscar Fuentes
2021-01-26 6:56 ` Eli Zaretskii
2021-01-26 7:37 ` Óscar Fuentes
2021-01-26 9:57 ` Eli Zaretskii
2021-01-26 15:58 ` martin rudalics
2021-01-27 14:55 ` Stephen Leake
2021-01-27 18:36 ` Eli Zaretskii
2021-01-26 16:35 ` Stephen Leake
2021-01-26 10:43 ` Phillip Lord
2021-04-03 11:34 ` Nikolay Kudryavtsev
2021-04-20 9:25 ` Phillip Lord
2021-04-20 14:38 ` Wayne Harris via Emacs development discussions. [this message]
2021-04-21 15:51 ` Phillip Lord
2021-04-21 17:11 ` Nikolay Kudryavtsev
2021-04-24 11:46 ` Wayne Harris via Emacs development discussions.
2021-04-26 13:27 ` Phillip Lord
2021-04-21 17:19 ` Nikolay Kudryavtsev
2021-04-21 23:03 ` Óscar Fuentes
2021-04-22 19:44 ` Nikolay Kudryavtsev
2021-04-22 14:55 ` Wayne Harris via Emacs development discussions.
2021-01-11 9:59 ` [feature/dll-only-windows] A new windows build, comments wanted Phillip Lord
2021-01-11 15:21 ` Eli Zaretskii
2021-01-11 18:29 ` Phillip Lord
2021-01-09 21:36 ` Óscar Fuentes
2021-01-10 16:46 ` Eli Zaretskii
2021-01-10 18:34 ` Phillip Lord
2021-01-09 21:51 ` Andrea Corallo via Emacs development discussions.
2021-01-10 3:33 ` Eli Zaretskii
2021-01-10 15:09 ` Phillip Lord
2021-01-10 19:06 ` Andrea Corallo via Emacs development discussions.
2021-01-11 9:47 ` Phillip Lord
2021-01-11 11:01 ` Andrea Corallo via Emacs development discussions.
2021-01-11 16:29 ` Phillip Lord
2021-01-11 17:21 ` Andrea Corallo via Emacs development discussions.
2021-01-10 15:14 ` Phillip Lord
2021-01-10 17:23 ` Eli Zaretskii
2021-01-09 20:47 ` Alan Third
2021-01-09 21:33 ` Phillip Lord
2021-01-10 0:04 ` Alan Third
2021-01-10 3:28 ` Eli Zaretskii
2021-01-10 15:43 ` Phillip Lord
2021-01-12 6:01 ` Corwin Brust
2021-01-12 9:48 ` Phillip Lord
2021-01-12 10:27 ` Corwin Brust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86o8e9kolk.fsf@protonmail.com \
--to=emacs-devel@gnu.org \
--cc=wharris1@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).