Windows binaries for emacs-28 status and TODOs

Windows binaries for emacs-28 status and TODOs

[Corwin Brust]

[-- Attachment #1: Type: text/plain, Size: 5411 bytes --]

Hi Eli, Dieter, Phil & Emacs devs,

I have confirmed that my latest binary packages are working.  When the
target system has a working msys64/mingw64 (with bin folder in the
windows path), native compilation is available.  It also works fine
for those without msys (however native compilation won't be available
in that case).  Thanks much to my kids for the use of their gaming
rigs, which I used for testing.

My latest work is in the with-native-compilation folder of this git repository:
  https://git.sr.ht/~mplscorwin/emacs-w64

Note that the builds in the parent directory are a touch older and
don't support native-compilation.  Also, this repo contains two
versions of a complete source dump for Emacs and each (recently
typical) release file:  it will take a lot of disc (~5GB) if you clone
the whole thing.  Consider hitting the repo URL in a web-browser and
using the "tree" tab to browse to and download what you need.

Since there have been several threads about building windows binary
releases for the emacs-28 pre-release, and those threads have gotten
quite long, I thought it would be good to start a new thread.

In addition to a summary of the related open discussion items/tasks, I
am attaching two files:
 - the first is my patch for build-zip.sh and build-dep-zips.sh
 - the second my ASCII armored GPG key

==Priority Tasks==
1. uploading binaries to alpha.gnu.org

I'm happy to do this and have attached my GPG key, providing (what I
hope is) the proper information for Eli to forward to
ftp-upload@gnu.org if that is, indeed, desired.  I'm comfortable
making the directives files and there's an example in the root folder
of the repo linked above.

I'm fine if someone else would like to handle the "last mile", of
course.  More over, it will be best if at least one other person is
fully checked out on this (hi Dieter) and also able to push windows
binaries via FTP.  Getting things fully working involved some trial
and error for me.  That's why I'm considering better documentation of
the process (point #3) as an high priority.

Eli, please weigh in on this point, especially.

2. fix any critical bugs specific to the binaries as I'm building them

In short, I think there are none that should prevent us from
publishing the emacs-28 pre-repease to alpha.gnu.org.  That said,
there may well be things I'm missing. (First rodeo alert.)

I suspect that the patch attached (or as eventually corrected) should
probably be applied before Emacs 28 is released.  I'm not convinced
other code (or process) changes are necessary before release.  (Even
the attached patch is arguably a documentation improvement.)  For
details see the discussion points (4-6), below.

3. better document the process for building windows binary releases

While there are many opportunities whereby we may be able to improve
the process, I think it will be best to start by documenting how the
present process works.  We can then iterate though improvements taking
pains to keep our documentation current (in proper Emacs passion).

I've had a pretty powerful machine (still) running Microsoft Windows
on the "bare metal".  Even still, I'd likely not have succeeded
(certainly not as quickly) without the many emails back and forth,
especially with Dieter, Phillip, and Eli.   If there truly are not
concerns with these packages then as soon as they are uploaded (or
that task is otherwise assigned), I think that coleasing what I've
learned (while it is fresh) should be my priority.  I think that will
get (at least Dieter) to a place of building and perhaps publishing
the builds to the FTP site(s) fairly quickly.

==Open Discussion Points==
4. Should we have separate set with and without native compilation?

This is the easiest of the discussion points, I think.  Eli has
suggested we can simply ship a native-comp enabled set of binary
release files assuming that is demonstrated to work.  I have satisfied
myself this does, in fact, work.  Moreover, no one has objected to
this approach.

FTR: I used three separate Windows machines, so far: one is where I'm
building the packages; the second has msys and native-comp does work
when I install there; the third has no msys (and had never seen Emacs
before) and there Emacs worked fine (but does not use the native
compiled elisp included in the build).

5. Is the -static flag required for windows binary releases?

My present binaries seem to work without -static. If I haven't missed
something then I am satisfied -static isn't needed to create windows
binary release files.

6. What problems exist with the installer and how urgent is each?

I think we are actively discussing several relevant things:
6.1 Is the uninstaller doing the right thing in all cases?
6.2 Should we detected existing Emacs install(s) and vary un/installer
behavior accordingly?
6.3 Should we provide version specific copies of emacsclientw, runemacs, etc.?
6.4 Should we produce an MSI instead of (or in addition to) the installer exe?

I suggest, rather than rush to closure, we should proceed in parallel
with those conversations/decisions and meanwhile focus on items 1-3.
If discussion deems some fixes urgent, I (at least) will be happy to
create and/or push new pre-release versions as we go.

I hope we can "open up" the emacs-28 pre-release to feedback from
windows users who aren't able to build locally in time to do some
good.

Thanks so much for Emacs; HTH.

[-- Attachment #2: corwin_brust_gpg_key.txt --]
[-- Type: text/plain, Size: 2448 bytes --]

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGNBF/W6/kBDADm9Ediun/6eUyTjRMEeEA0SjD8Ul9UbijqzIW3lyDoh0ACtKge
Mh0xt6B6cRCZGxnBXmdriIwPVJqvlT2EoSxL65UU2oACmaVWoFayMgObXb7kcaUq
PVhnNGd2RLjolb23b3S2xI/0lUYhlsx25ySTLruME9jacz7hT7d3hPFdr2PmbV0c
QUnCqOdmZyHyV7VFqJuPC0bQ4s2cOkcMj67QT7vLTas20hpcOXHOLxhm8vC8v/+J
FKFH4hM8ZhDGOZDiKnNi3RVhHrUgIGE6OU7tmKquevcO+B1ix0W02c2EEgRKMySx
sEGnSTP735hLbYd2KObZfGa8y82tcovIU+wTUtK0HrxNc/K/cL4vDvN+7vgRFvbE
M8WXYnigDT4BrCgI8WyYNLabnE3SIViw4LErrpWbuXjIcsSci7TkJeKnMiBM5sHZ
cMZN0g0GPROtghckqjrhFQ2va9JTxfobRfJzOtFFWb3CvDg3dtSLjrimMn7gFUmR
SrHpj0Wya20amcEAEQEAAbQcQ29yd2luIEJydXN0IDxjb3J3aW5AYnJ1LnN0PokB
1AQTAQgAPhYhBOznfPQXx2waz858K1thNVEVgPAHBQJf1uv5AhsDBQkDwmcABQsJ
CAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEFthNVEVgPAHumML/jAUSDedlnRufOpl
CKQ9wXnhiSK71qBa9a2dGhE25oiWP0NYY1SdfCt/Zc4rwVy81tG29L8j0Gjx4mJ5
sGuohE32G7UkrMykc/W5iL1H8PWknh4vBVQz/NnA3dxl75kA+Jm4Tjg081j6cJ0p
gfQeO8SFhuojh5hHedO4/7m2Up2Vj4PEsnQ8O6moC8Un9w2eLhhpIFxbLrHQZdtJ
h4Ct36yOnVg/PDJRfF7aYqRZ4beBDNzp4/MfYzyjzzUoz93EOUqiuGnMXKlSNBTo
rTX4ztblrnoJN1sUU1X/DqkRwqkrP71R2vNshBSbAgODm2LzXgz0Em8knlsLPFCK
HNOI7GMYIh/8KH6LxRzXrSaERvO+94gp09Kg2jQ3scgigeOseslnv/dVvlLLz7NX
6/jUPYmLNDSXFiD151dmqs+GQRycd/ySzTncA/YH5ku78ukicyKTnp7QgpJKVlQN
TultQtSftzelq3eIG37fl3LvRnc7dMpzGC5z1NXlD7vRD8E7/7kBjQRf1uv5AQwA
33p+GaIuSmtpfq7+7St6P4CThQldEii10mwumIrFTZVHC4tpjSDZgQblvThNZ6ZV
5Cds08VfN2h3P+lR4BXfxw7aSY5fMU0wxcO/yXdvXVS2dPaE76BPN9aSbANAtyX6
3ke2aA8SIFAqax7x+HirafNXBhd5+3lYUOknX/5gVIPgR4LZle7mHUWh3R0lrtd/
lsGYU3vq2rf1vf/g8nMckh5cgk4d77xn8F9PPE+Pr5j9nHfjdSgkP1qkLoZjINBf
sucsbBI2KN/DLE5ZsbAnidAyAXbdIge7fREmdxi32fT0t3KBjHPnsdHd3j+gzi9D
RoquzFq4kFMnXghv60j2FCg/m4gGw+KAMuBQaOpg+SpoC9LfNsY+kWhv3Nt6QVQo
SLkzX+XjVOupDh1RP9RV3aMy1ugYvVgZwZ9QrFofKo/7B3RXxiVBbeNWAKqgK30Y
p/FHEZg02kaUscOvKqUjwKEI2wlBC9LDSyqAv86jyCnpZurieC05kDsJlXhgwm5D
ABEBAAGJAbwEGAEIACYWIQTs53z0F8dsGs/OfCtbYTVRFYDwBwUCX9br+QIbDAUJ
A8JnAAAKCRBbYTVRFYDwB1agDACLsCCSM3m4Wl4Pts0yF90RtdranjaUiu3mQmwr
pH+QlRfpAY0UQcRrf5iFP4LRqnstaQLppUsWbjYq6KwxcP43EyCtP3pbUuY/fUOs
0bZFjBDSgMKF+yHwnSRkQEAmgEkgL/kbj3ICAUgUIbkO1/Dtw4jM9SLpb/lIvDGI
uEsSeKTMijDZDpHQLmTicpbTYYt8jlMJpZzIIw7H5Bi0hGWB9rcqRiVW3VTLaWj+
Nc3KJQCH/XRVjOnvsznM+tjSWwp1I+79Rn+0DEKKeUhRYFv57Y4whEB8VcGy5BZ/
4sBoVv3tmECV8B4Mv6A7v+noQlYb0islEovyZLHg0qQRcbp41P/ipiAutVwMC9NV
gPDWWI233BcoQhmjsnyChcMq5esPWBpLA3VHxJZRGTqkPCNbDrN++beDeI4p27jv
lJYYYIjUqp2K0qOpH0uNGeeZKXDFxI7CtnoNngNAv9YMwhr7xsVJ9XtiSXxngiws
KPq49blxlfAfAKKiwhNEY4x+LtA=
=vnCj
-----END PGP PUBLIC KEY BLOCK-----

[-- Attachment #3: emacs-28_nt-dist-build-scripts.patch --]
[-- Type: application/octet-stream, Size: 1858 bytes --]

diff --git a/admin/nt/dist-build/build-dep-zips.py b/admin/nt/dist-build/build-dep-zips.py
index c27045a001..974bf456fb 100755
--- a/admin/nt/dist-build/build-dep-zips.py
+++ b/admin/nt/dist-build/build-dep-zips.py
@@ -37,6 +37,7 @@
 mingw-w64-x86_64-librsvg
 mingw-w64-x86_64-libtiff
 mingw-w64-x86_64-libxml2
+mingw-w64-x86_64-gmp
 mingw-w64-x86_64-xpm-nox'''.split()
 
 DLL_REQ='''libgif
@@ -49,6 +50,7 @@
 librsvg
 libtiff
 libxml
+libgmp
 libXpm'''.split()
 
 
@@ -121,7 +123,7 @@ def ntldd_munge(out):
 
 ## Currently no packages seem to require this!
 ARCH_PKGS=[]
-SRC_REPO="https://sourceforge.net/projects/msys2/files/REPOS/MINGW/Sources"
+SRC_REPO="https://repo.msys2.org/mingw/sources"
 
 
 def immediate_deps(pkg):
@@ -167,7 +169,7 @@ def download_source(tarball):
     if not os.path.exists("../emacs-src-cache/{}".format(tarball)):
         print("Downloading {}...".format(tarball))
         check_output_maybe(
-            "wget -a ../download.log -O ../emacs-src-cache/{} {}/{}/download"
+            "wget -a ../download.log -O ../emacs-src-cache/{} {}/{}"
             .format(tarball, SRC_REPO, tarball),
             shell=True
         )
diff --git a/admin/nt/dist-build/build-zips.sh b/admin/nt/dist-build/build-zips.sh
index 77d20a5a7b..6d198c79e8 100755
--- a/admin/nt/dist-build/build-zips.sh
+++ b/admin/nt/dist-build/build-zips.sh
@@ -48,9 +48,10 @@
         echo [build] Configuring Emacs
         $REPO_DIR/$BRANCH/configure \
             --without-dbus \
+            --with-native-compilation \
             --without-compress-install \
             $CACHE \
-            CFLAGS="$CFLAGS"
+            CFLAGS="$CFLAGS" 
     fi
 
     make -j 4 $INSTALL_TARGET \
@@ -96,7 +97,7 @@ BUILD=
 BUILD_64=1
 GIT_UP=0
 CONFIG=1
-CFLAGS="-O2 -static"
+CFLAGS="-O2"
 INSTALL_TARGET="install-strip"
 
 ## The location of the git repo

Re: Windows binaries for emacs-28 status and TODOs

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sun, 23 Jan 2022 04:54:05 -0600
> 
> 1. uploading binaries to alpha.gnu.org
> 
> I'm happy to do this and have attached my GPG key, providing (what I
> hope is) the proper information for Eli to forward to
> ftp-upload@gnu.org if that is, indeed, desired.  I'm comfortable
> making the directives files and there's an example in the root folder
> of the repo linked above.
> 
> I'm fine if someone else would like to handle the "last mile", of
> course.  More over, it will be best if at least one other person is
> fully checked out on this (hi Dieter) and also able to push windows
> binaries via FTP.  Getting things fully working involved some trial
> and error for me.  That's why I'm considering better documentation of
> the process (point #3) as an high priority.
> 
> Eli, please weigh in on this point, especially.

It's up to you.  Please decide who will upload the binaries, and then
email ftp-upload@gnu.org with me in the CC.

Thanks.

Re: Windows binaries for emacs-28 status and TODOs

[Corwin Brust]

On Sun, Jan 23, 2022 at 5:19 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> It's up to you.  Please decide who will upload the binaries, and then
> email ftp-upload@gnu.org with me in the CC.

Now done.

I think it will be best if I do it for the moment.  Longer term, I'd
like if either Dieter or I can. I appreciate the prompt response.

Re: Windows binaries for emacs-28 status and TODOs

[H. Dieter Wilhelm]

Corwin Brust <corwin@bru.st> writes:

> ==Priority Tasks==
> 1. uploading binaries to alpha.gnu.org

+1 (conditionally)

I hope, with this, there will be more feedback and tested use cases,
than we can provide.

> Eli, please weigh in on this point, especially.

Yes please.

> 2. fix any critical bugs specific to the binaries as I'm building them
> ..
> 3. better document the process for building windows binary releases

Sorry, haven't checked your documentation work yet.

> ==Open Discussion Points==
> 4. Should we have separate set with and without native compilation?

As a backup scenario in case of bug reports maybe? (I can't fathom what
might go wrong on Windows..)

> 5. Is the -static flag required for windows binary releases?

So far your build seems to work flawlessly on my MSYS machine.

By the way, are the debug symbols really necessary?  Eli mentioned this,
as far as I understood, as a reason for the bigger .eln file sizes
compared to files on Gnu-Linux.  Could we spare another, maybe,
unnecessary compiler flag?

> 6. What problems exist with the installer and how urgent is each?

    (debbugs-gnu-bugs 53551)
28.0.91; Installer on Windows10 (wishlist priority)

And then there is the "side-by-side" installation in existing Emacs' tree
issue..

> 6.1 Is the uninstaller doing the right thing in all cases?

    (debbugs-gnu-bugs 53553)
28.0.91; uninstall.exe leaves traces of Emacs

> 6.2 Should we detected existing Emacs install(s) and vary un/installer
> behavior accordingly?

At least in the long run, yes.  If Emacs is designed that way for
side-by-side installations..

> 6.3 Should we provide version specific copies of emacsclientw, runemacs, etc.?

Eli said: Not necessary.

> 6.4 Should we produce an MSI instead of (or in addition to) the installer exe?

MSI is another installer type, isn't it?  I think in my company .msi
files are not allowed to download by the virus scanners.  Might be an
issue for other users as well?

> I suggest, rather than rush to closure, we should proceed in parallel
> with those conversations/decisions and meanwhile focus on items 1-3.

+1

        Dieter

Re: Windows binaries for emacs-28 status and TODOs

[H. Dieter Wilhelm]

Hello Corwin

thank you for the Windows pretest 28.0.91! :-)

  http://alpha.gnu.org/gnu/emacs/pretest/windows/

Maybe one small space "optimisation" to watch out for the NEXT pretest
or release packaging.  Please check your build folder

  lib/emacs/28.0.91/native-lisp

there are redundant folders in the pretest from previous builds.

-- 
   Dieter
   
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Windows binaries for emacs-28 status and TODOs

[Corwin Brust]

On Sun, Feb 6, 2022 at 4:40 AM H. Dieter Wilhelm
<dieter@duenenhof-wilhelm.de> wrote:
>
> Hello Corwin
>
> thank you for the Windows pretest 28.0.91! :-)

:D

>
>   http://alpha.gnu.org/gnu/emacs/pretest/windows/
>
> Maybe one small space "optimisation" to watch out for the NEXT pretest
> or release packaging.  Please check your build folder
>
>   lib/emacs/28.0.91/native-lisp
>
> there are redundant folders in the pretest from previous builds.

Oh rats!  I'm not entirely sure how I've managed that.  I have been
running the command below after running build-zips.sh and before
zipping up the Emacs sources used.

  git clean -xdf

I think I will pull down a fresh git/emacs-28.0.91 before I next package.

Much appreciated.
Corwin

Re: Windows binaries for emacs-28 status and TODOs

[H. Dieter Wilhelm]

Corwin Brust <corwin@bru.st> writes:

> On Sun, Jan 23, 2022 at 5:19 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> It's up to you.  Please decide who will upload the binaries, and then
>> email ftp-upload@gnu.org with me in the CC.
>
> Now done.
>
> I think it will be best if I do it for the moment.  Longer term, I'd
> like if either Dieter or I can. I appreciate the prompt response.

I just installed the latest Git for Windows.  During the installation
process it is possible to set up an editor.  Here follow the the
options:

1. Gnu Nano
2. Vim (the ubiquitous text editor) [default]

it seems the above are included in Git for Windows, for the following
there are links provided (supposedly when they are not found)

3. Notepad++
4. Visual Studio Code
5. Visual Studio Code Insiders
6. Sublime Text
7. Atom
8. VSCodium

And the final two programs are provided by the OS

9. Notepad (New)
10. Wordpad (New)

11. Select other editor as Git's editor

I find this quite astonishing that there is no mention of Emacs, all the
more because Linus is supposed to use µemacs a variant of it!  It seems
that the maintainers don't consider Emacs a "text editor"?

Dieter

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Windows binaries for emacs-28 status and TODOs

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Emacs developers <emacs-devel@gnu.org>,
>   Phillip Lord <phillip.lord@russet.org.uk>
> Date: Mon, 14 Feb 2022 21:03:10 +0100
> 
> 1. Gnu Nano
> 2. Vim (the ubiquitous text editor) [default]
> 
> it seems the above are included in Git for Windows, for the following
> there are links provided (supposedly when they are not found)
> 
> 3. Notepad++
> 4. Visual Studio Code
> 5. Visual Studio Code Insiders
> 6. Sublime Text
> 7. Atom
> 8. VSCodium
> 
> And the final two programs are provided by the OS
> 
> 9. Notepad (New)
> 10. Wordpad (New)
> 
> 11. Select other editor as Git's editor
> 
> I find this quite astonishing that there is no mention of Emacs, all the
> more because Linus is supposed to use µemacs a variant of it!  It seems
> that the maintainers don't consider Emacs a "text editor"?

They should have emacsclient, not Emacs.  (When I install Git, I
choose 11 and point Git to emacsclient.exe.)

Re: Windows binaries for emacs-28 status and TODOs

[H. Dieter Wilhelm]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Emacs developers <emacs-devel@gnu.org>,
>>   Phillip Lord <phillip.lord@russet.org.uk>
>> Date: Mon, 14 Feb 2022 21:03:10 +0100
>> 
>> 1. Gnu Nano
>> 2. Vim (the ubiquitous text editor) [default]
>> 
>> it seems the above are included in Git for Windows, for the following
>> there are links provided (supposedly when they are not found)
>> 
>> 3. Notepad++
>> 4. Visual Studio Code
>> 5. Visual Studio Code Insiders
>> 6. Sublime Text
>> 7. Atom
>> 8. VSCodium
>> 
>> And the final two programs are provided by the OS
>> 
>> 9. Notepad (New)
>> 10. Wordpad (New)
>> 
>> 11. Select other editor as Git's editor
>> 
>> I find this quite astonishing that there is no mention of Emacs, all the
>> more because Linus is supposed to use µemacs a variant of it!  It seems
>> that the maintainers don't consider Emacs a "text editor"?

I asked a maintainer and he said it's just the case that nobody took the
pains yet to implement Emacs in
https://github.com/git-for-windows/build-extra/blob/main/installer/install.iss.

> They should have emacsclient, not Emacs.

Yes, I agree.

But then, the user has to know about emacsclient(w) AND how to set up
the server beforehand.

I believe it should also work for emacs.exe (which it is) and
runemacs.exe (which is not working, please see the attached image).  Or,
even better, suggesting a command line option for emacsclient(w) in case
the server is not running.  (Unfortunately I couldn't get emacsclient to
run with a command line option, probably a bug in the Git installer.:-/)

   Dieter

[-- Attachment #2: git_editor_test_runemacs_exe_2022-02-16.png --]
[-- Type: image/png, Size: 32409 bytes --]

[-- Attachment #3: Type: text/plain, Size: 56 bytes --]


-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Windows binaries for emacs-28 status and TODOs

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: corwin@bru.st,  emacs-devel@gnu.org,  phillip.lord@russet.org.uk
> Date: Wed, 16 Feb 2022 10:50:03 +0100
> 
> > They should have emacsclient, not Emacs.
> 
> Yes, I agree.
> 
> But then, the user has to know about emacsclient(w) AND how to set up
> the server beforehand.

No, the user should be able to select emacsclient, and the installer
should produce the actual command using that.  Just like with the
other editors they offer.

> I believe it should also work for emacs.exe (which it is) and
> runemacs.exe (which is not working, please see the attached image).

Why is that a good idea?

> Or, even better, suggesting a command line option for emacsclient(w)
> in case the server is not running.

That's what I had in mind.  (And no, emacsclientw is NOT the right
choice here, since Git is a console executable.)

> (Unfortunately I couldn't get emacsclient to
> run with a command line option, probably a bug in the Git installer.:-/)

Which seems to indicate that integrating emacsclient into Git is not
as simple as its maintainer thinks.

Re: Windows binaries for emacs-28 status and TODOs

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> Cc: corwin@bru.st,  emacs-devel@gnu.org,  phillip.lord@russet.org.uk
>> Date: Wed, 16 Feb 2022 10:50:03 +0100
>> 
>> > They should have emacsclient, not Emacs.
>> 
>> Yes, I agree.
>> 
>> But then, the user has to know about emacsclient(w) AND how to set up
>> the server beforehand.
>
> No, the user should be able to select emacsclient, and the installer
> should produce the actual command using that.  Just like with the
> other editors they offer.
>
>> I believe it should also work for emacs.exe (which it is) and
>> runemacs.exe (which is not working, please see the attached image).
>
> Why is that a good idea?

To be prepared for all eventualities when a user might overwrite a
suggestion of emacsclient?  It took many years of Emacs usage before I
understood what emacsclient is.

>> Or, even better, suggesting a command line option for emacsclient(w)
>> in case the server is not running.
>
> That's what I had in mind.  (And no, emacsclientw is NOT the right
> choice here, since Git is a console executable.)

Ah right, just considered the installer test.

>> (Unfortunately I couldn't get emacsclient to
>> run with a command line option, probably a bug in the Git installer.:-/)
>
> Which seems to indicate that integrating emacsclient into Git is not
> as simple as its maintainer thinks.

Sigh, unfortunately yes. Asked the maintainer about the command line
issue, anyway.

And there's also GitGui to consider, which is not a console program
(regarding the choice of emacsclient and emacsclientw)..

Let's see, thank you

      Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Windows binaries for emacs-28 status and TODOs

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: corwin@bru.st,  emacs-devel@gnu.org,  phillip.lord@russet.org.uk
> Date: Wed, 16 Feb 2022 13:52:56 +0100
> 
> >> I believe it should also work for emacs.exe (which it is) and
> >> runemacs.exe (which is not working, please see the attached image).
> >
> > Why is that a good idea?
> 
> To be prepared for all eventualities when a user might overwrite a
> suggestion of emacsclient?  It took many years of Emacs usage before I
> understood what emacsclient is.

Ther option could say "emacs", but configure Git to use emacsclient
instead.

> And there's also GitGui to consider, which is not a console program
> (regarding the choice of emacsclient and emacsclientw)..

That one should use emacsclientw.

Re: Windows binaries for emacs-28 status and TODOs

[Corwin Brust]

On Wed, Feb 16, 2022 at 7:32 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> > Date: Wed, 16 Feb 2022 13:52:56 +0100
> >
> > And there's also GitGui to consider, which is not a console program
> > (regarding the choice of emacsclient and emacsclientw)..
>
> That one should use emacsclientw.

Eli,

Can you share your incantation to launch emacsclient?  I normally
launch using the below.

C:\emacs-28.0.91\bin\emacsclientw.exe -n -a "" -eval "(raise-frame)"

I haven't tried to configure it as the editor for git-for-windows yet
but I'm interested to try it out.

Re: Windows binaries for emacs-28 status and TODOs

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Wed, 16 Feb 2022 07:40:03 -0600
> Cc: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>, Emacs developers <emacs-devel@gnu.org>, 
> 	Phillip Lord <phillip.lord@russet.org.uk>
> 
> On Wed, Feb 16, 2022 at 7:32 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> Can you share your incantation to launch emacsclient?  I normally
> launch using the below.
> 
> C:\emacs-28.0.91\bin\emacsclientw.exe -n -a "" -eval "(raise-frame)"
> 
> I haven't tried to configure it as the editor for git-for-windows yet
> but I'm interested to try it out.

Git should use something similar to what you use:

  emacsclient -a ""

Re: Windows binaries for emacs-28 status and TODOs

[H. Dieter Wilhelm]

Corwin Brust <corwin@bru.st> writes:

> On Wed, Feb 16, 2022 at 7:32 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> > Date: Wed, 16 Feb 2022 13:52:56 +0100
>> >
>> > And there's also GitGui to consider, which is not a console program
>> > (regarding the choice of emacsclient and emacsclientw)..
>>
>> That one should use emacsclientw.
>
> Eli,
>
> Can you share your incantation to launch emacsclient?  I normally
> launch using the below.
>
> C:\emacs-28.0.91\bin\emacsclientw.exe -n -a "" -eval "(raise-frame)"

Hi Corwin, why --no-wait?

> I haven't tried to configure it as the editor for git-for-windows yet
> but I'm interested to try it out.

If you have a running Emacs already with M-x server-start, or in the
init file.  Then pointing the installer to

  C:\emacs-28.0.91\bin\emacsclientw.exe

without any options was enough in my case to get the test file in my
Emacs GUI frame.

(Probably there's a config file to specify this, I don't know, sorry.)

          Dieter

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

Re: Windows binaries for emacs-28 status and TODOs

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> And there's also GitGui to consider, which is not a console program
>> (regarding the choice of emacsclient and emacsclientw)..
>
> That one should use emacsclientw.

In fact, it seems that Git GUI isn't using editors at all.  There's a
separate commit message window..

       Dieter

Re: Windows binaries for emacs-28 status and TODOs

[H. Dieter Wilhelm]

"H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de> writes:

> Corwin Brust <corwin@bru.st> writes:
>
>> On Wed, Feb 16, 2022 at 7:32 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>>
>>> > From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>>> > Date: Wed, 16 Feb 2022 13:52:56 +0100
>>> >
>>> > And there's also GitGui to consider, which is not a console program
>>> > (regarding the choice of emacsclient and emacsclientw)..
>>>
>>> That one should use emacsclientw.
>>
>> Eli,
>>
>> Can you share your incantation to launch emacsclient?  I normally
>> launch using the below.
>>
>> C:\emacs-28.0.91\bin\emacsclientw.exe -n -a "" -eval "(raise-frame)"
>
> Hi Corwin, why --no-wait?
>
>> I haven't tried to configure it as the editor for git-for-windows yet
>> but I'm interested to try it out.
>
> If you have a running Emacs already with M-x server-start, or in the
> init file.  Then pointing the installer to
>
>   C:\emacs-28.0.91\bin\emacsclientw.exe
>
> without any options was enough in my case to get the test file in my
> Emacs GUI frame.

Yep, but only for the installer tests.. 

 After actually using Git Bash I realised that the installer doesn't
change the global git configuration file

  ~/.gitconfig

when there's an editor line already there, no matter what the installer
gets fed.

At last I got emacsclient to run from Git Bash but, funnily, only with
the last line!?  (Please note the quotes and /C/ without colons.)

  [core]
  #	editor = \"C:/Program Files (x86)/GitExtensions/GitExtensions.exe\" fileeditor
  #	editor = /C/Program Files/Emacs/emacs-28.0.91/bin/emacsclient.exe --alternate-editor=\"\"
          editor = \"/C/Program Files/Emacs/emacs-28.0.91/bin/emacsclient.exe\" --alternate-editor=\"\"
  

Possibly using backlashes might also be a permissible pattern but I've
got enough for today.

Have a good time

  Dieter