bug#58877: 29.0.50; [PATCH] When killing Emacs from a client frame with no other frames, Emacs shows a useless error prompt

[Jim Porter]

On 11/26/2022 11:45 AM, Eli Zaretskii wrote:
> > Date: Sat, 26 Nov 2022 11:04:48 -0800
> > Cc: 58877@debbugs.gnu.org
> > From: Jim Porter <jporterbugs@gmail.com>
> >
> > > I think you need to modify the tests to ensure the server file is created in
> > > a temporary directory.  And keep in mind that the variable which affects
> > > that is different depending on whether server-use-tcp is or isn't non-nil.
> >
> > Hm, I'm surprised the tests failed again for you then. Both of the
> > patches I posted to fix the tests set the 'server-name' to a (hopefully)
> > unique value.
> >
> > Still, I think it's a good idea to use a temporary directory to hold the
> > server file, so here's a patch that does that. I've tried this patch
> > with a production Emacs server running at the same time in several
> > different configurations (with 'server-use-tcp' on and off, and with
> > --daemon), and the tests all pass locally for me on GNU/Linux.
>
> Still fails, and here's why:
>
>      Client output: d:\gnu\git\emacs\trunk\lib-src\emacsclient.exe: 
> unrecognized option '--socket-name'
>                     Try 'd:\gnu\git\emacs\trunk\lib-src\emacsclient.exe --help' 
> for more information
>
>                     Process d:/gnu/git/emacs/trunk/lib-src/emacsclient exited 
> abnormally with code 1
>
> There's no --socket-name switch on MS-Windows; you need to use --server-file
> instead.

Ah ha, that explains it. I didn't realize that distinction.

> If I change server-tests/start-client to use --server-file, the next problem
> rears its ugly head:
>
>      Client output: *ERROR*: Not using an ASCII terminal now; cannot make a new 
> ASCII frame
>
>                     Process d:/gnu/git/emacs/trunk/lib-src/emacsclient exited 
> abnormally with code 1
>
> This is because emacsclient on Windows cannot create new terminal frames,
> only new GUI frames, unless Emacs was started as "emacs -nw".
>
> Why do these tests need TTY frames?

The test code just calls "emacsclient -c", and they should be happy with 
any kind of frame, TTY or GUI. I guess that by running in batch mode, 
Emacs will try to create TTY frames, but that fails on MS Windows?

> Btw, with the above changes, only 3 tests fail:
>
>    3 unexpected results:
>       FAILED  server-tests/emacsclient/create-frame
>       FAILED  server-tests/server-force-stop/keeps-frames
>       FAILED  server-tests/server-start/stop-prompt-with-client
>
> So this is progress, thanks.

All these tests involve creating client frames, so that makes sense. I'm 
not sure how to coax Emacs into creating GUI frames on MS Windows for 
these tests though. Still, I don't think these failures are a sign of 
anything broken exactly; it's just the combination of MS Windows' 
limitations with trying to create frames in an Emacs batch session.

Unless you have an idea for how to fix that (I've got no clue, 
unfortunately), how about just skipping these tests on MS Windows, with 
a comment explaining what the limitation is?