From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wayne Harris via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [feature/internal-msys] thoughts of a more function windows package Date: Tue, 20 Apr 2021 11:38:47 -0300 Message-ID: <86o8e9kolk.fsf@protonmail.com> References: <87pn2dq3xv.fsf@russet.org.uk> <83ft39hnk1.fsf@gnu.org> <87h7nppzjy.fsf@russet.org.uk> <838s90hhb6.fsf@gnu.org> <87zh1gircl.fsf@russet.org.uk> <83turofw8r.fsf@gnu.org> <87sg6v76fd.fsf_-_@russet.org.uk> <87y2dd8g04.fsf@russet.org.uk> Reply-To: Wayne Harris Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12072"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Cancel-Lock: sha1:nB7VnsW8nZ/PhlLInAeLqTLh7I4= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 20 16:40:03 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lYrXn-00030E-PR for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Apr 2021 16:40:03 +0200 Original-Received: from localhost ([::1]:48450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lYrXm-0001kF-T6 for ged-emacs-devel@m.gmane-mx.org; Tue, 20 Apr 2021 10:40:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36220) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYrWz-0000zI-HQ for emacs-devel@gnu.org; Tue, 20 Apr 2021 10:39:13 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:36040) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lYrWu-0001e8-27 for emacs-devel@gnu.org; Tue, 20 Apr 2021 10:39:13 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lYrWq-0001qq-QQ for emacs-devel@gnu.org; Tue, 20 Apr 2021 16:39:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268207 Archived-At: Phillip Lord writes: > Nikolay Kudryavtsev 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.)