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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58877 in the body.
You can then email your comments to 58877 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] When killing Emacs from a client frame with no other
 frames, Emacs shows a useless error prompt
Date: Sat, 29 Oct 2022 14:33:42 -0700

[Message part 1 (text/plain, inline)]

(Note: I originally mentioned this in bug#51993, but it's only 
somewhat-related to that bug. To make things easier to follow, I pulled 
this part out into a separate bug.)

To see this in action:

  $ emacs -Q -f server-start
  $ emacsclient -c foo.txt

  ;; From the first (non-client) frame:
  C-x 5 0  ;; delete-frame

  ;; From the second (client) frame:
  M-x kill-emacs
  ;; Emacs prompts:
  Error (error Attempt to delete the sole visible or iconified frame); 
continue? (y or n)

Pressing "y" will properly kill Emacs, but there's no real use for the 
warning in this case. It happens because 'server-force-stop' 
(indirectly) tries to delete the last (client) frame before killing 
Emacs, meaning that Emacs would have zero frames for a bit.

Since 'server-force-stop's docstring says, "This function is meant to be 
called from `kill-emacs-hook'," it should be safe to have 
'server-force-stop' avoid deleting any frames: they'll just get deleted 
when Emacs is actually killed.

Attached is a patch to do this. Note that I named the new argument 
"noframe" because that matches the existing code in server.el (see 
'server-delete-client'). It's a bit of a misnomer though, and maybe 
"keep-frames" would be better...

[0001-Don-t-explicitly-delete-client-frames-when-killing-E.patch (text/plain, attachment)]

Message #8 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50;
 [PATCH] When killing Emacs from a client frame with no other frames,
 Emacs shows a useless error prompt
Date: Sun, 30 Oct 2022 08:14:44 +0200

> Date: Sat, 29 Oct 2022 14:33:42 -0700
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> Attached is a patch to do this. Note that I named the new argument 
> "noframe" because that matches the existing code in server.el (see 
> 'server-delete-client'). It's a bit of a misnomer though, and maybe 
> "keep-frames" would be better...

Hmm... it doesn't look very elegant to add to server-start an extra
argument whose purpose is to affect server-delete-client.  Can we do
this in some more elegant way?  For example, how about making most of
the code in server-start an internal function with an additional
argument, and then have server-start and server-force-stop call that
internal function?  At the very least the new argument to server-start
shouldn't be advertised, I think, since it's entirely for internal use
by us.

Thanks.

Message #11 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sun, 30 Oct 2022 14:14:59 -0700

[Message part 1 (text/plain, inline)]

On 10/29/2022 11:14 PM, Eli Zaretskii wrote:
>> Date: Sat, 29 Oct 2022 14:33:42 -0700
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> Attached is a patch to do this. Note that I named the new argument
>> "noframe" because that matches the existing code in server.el (see
>> 'server-delete-client'). It's a bit of a misnomer though, and maybe
>> "keep-frames" would be better...
> 
> Hmm... it doesn't look very elegant to add to server-start an extra
> argument whose purpose is to affect server-delete-client.  Can we do
> this in some more elegant way?  For example, how about making most of
> the code in server-start an internal function with an additional
> argument, and then have server-start and server-force-stop call that
> internal function?  At the very least the new argument to server-start
> shouldn't be advertised, I think, since it's entirely for internal use
> by us.

Thanks for taking a look. I had hesitated to make any big changes to 
this code since it doesn't have regression tests, but I think the 
attached patch should be more elegant while retaining the flow of the 
code as much as possible. Do you know of a good way to write regression 
tests for this code? I couldn't find any existing tests that start/stop 
Emacs processes in a way that I could use for testing this. It seems 
like we'd need to be able to start a new Emacs process and then be able 
to send arbitrary key combinations to it to drive it...

Back to the patch itself though: one small functional change I made was 
that I slightly changed how 'server-ensure-safe-dir' is called in 
'server-start'. (I only mention this because this code looks to be 
security-related, so I think it should have extra attention.)

It used to check the 'server-dir', defined as:

  (if server-use-tcp server-auth-dir server-socket-dir)

Now, it checks the directory of the server *file*. The file is defined as:

  (expand-file-name server-name server-dir)

This could be different if 'server-name' (a defcustom) contains a slash. 
I think the new code is actually safer, since it checks the proper 
directory even if a user customized 'server-name' to have a slash or 
'..' or whatever. Still, I thought this change deserved a mention so 
that I don't inadvertently open a security hole.

[0001-Don-t-explicitly-delete-client-frames-when-killing-E.patch (text/plain, attachment)]

Message #14 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Mon, 21 Nov 2022 21:06:31 -0800

[Message part 1 (text/plain, inline)]

On 10/30/2022 2:14 PM, Jim Porter wrote:
> Thanks for taking a look. I had hesitated to make any big changes to 
> this code since it doesn't have regression tests...
Since server.el could probably use more tests anyway, I added a few ERT 
tests covering the most common use cases (see the first patch), and then 
added another test for the second patch. The test in the second patch is 
pretty indirect, but that's because it's testing something that normally 
happens when killing Emacs; it'd be hard to kill the current Emacs 
instance and still be able to check test results!

[0001-Add-more-tests-for-the-Emacs-server.patch (text/plain, attachment)]

[0002-Don-t-explicitly-delete-client-frames-when-killing-E.patch (text/plain, attachment)]

Message #17 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Thu, 24 Nov 2022 13:51:13 +0200

> Date: Mon, 21 Nov 2022 21:06:31 -0800
> From: Jim Porter <jporterbugs <at> gmail.com>
> Cc: 58877 <at> debbugs.gnu.org
> 
> On 10/30/2022 2:14 PM, Jim Porter wrote:
> > Thanks for taking a look. I had hesitated to make any big changes to 
> > this code since it doesn't have regression tests...
> Since server.el could probably use more tests anyway, I added a few ERT 
> tests covering the most common use cases (see the first patch), and then 
> added another test for the second patch. The test in the second patch is 
> pretty indirect, but that's because it's testing something that normally 
> happens when killing Emacs; it'd be hard to kill the current Emacs 
> instance and still be able to check test results!

This is fine with me, but please fix the typo before installing:

> +(defun server-stop (&optional noframe)
> +  "If this Emacs process has a server communication subprocess, stop it.
> +If the server is running in some other Emac process (see
                                          ^^^^

Message #22 received at 58877-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877-done <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Thu, 24 Nov 2022 17:36:11 -0800

On 11/24/2022 3:51 AM, Eli Zaretskii wrote:
>> Date: Mon, 21 Nov 2022 21:06:31 -0800
>> From: Jim Porter <jporterbugs <at> gmail.com>
>> Cc: 58877 <at> debbugs.gnu.org
>>
>> Since server.el could probably use more tests anyway, I added a few ERT
>> tests covering the most common use cases (see the first patch), and then
>> added another test for the second patch. The test in the second patch is
>> pretty indirect, but that's because it's testing something that normally
>> happens when killing Emacs; it'd be hard to kill the current Emacs
>> instance and still be able to check test results!
> 
> This is fine with me, but please fix the typo before installing:

Whoops! Good catch, thanks.

Merged as 28c444f72a9843ce335032db1fa0f484dfeb4833 with the typo fixed. 
Closing this now.

Message #25 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Fri, 25 Nov 2022 15:25:36 +0200

> Date: Thu, 24 Nov 2022 17:36:11 -0800
> Cc: 58877-done <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> Merged as 28c444f72a9843ce335032db1fa0f484dfeb4833 with the typo fixed. 

Thanks.

Are the tests supposed to be portable?  Here on MS-Windows 5 tests fail:

  5 unexpected results:
     FAILED  server-tests/emacsclient/create-frame
     FAILED  server-tests/emacsclient/eval
     FAILED  server-tests/emacsclient/server-edit
     FAILED  server-tests/server-force-stop/keeps-frames
     FAILED  server-tests/server-start/stop-prompt-with-client

All of them fail due to some timeout:

  Test server-tests/emacsclient/create-frame backtrace:
    signal(ert-test-failed ("timed out waiting for (length= (frame-list)
    ert-fail("timed out waiting for (length= (frame-list) 2) to ...")

so this sounds like some fundamental issue common to all those tests.

On GNU/Linux all the tests pass.

Let me know if you want me to investigate something.

Message #28 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Fri, 25 Nov 2022 11:31:07 -0800

[Message part 1 (text/plain, inline)]

On 11/25/2022 5:25 AM, Eli Zaretskii wrote:
> Are the tests supposed to be portable?

In theory, they should be. Apparently they aren't in practice.

> All of them fail due to some timeout:
> 
>    Test server-tests/emacsclient/create-frame backtrace:
>      signal(ert-test-failed ("timed out waiting for (length= (frame-list)
>      ert-fail("timed out waiting for (length= (frame-list) 2) to ...")
> 
> so this sounds like some fundamental issue common to all those tests.

Hm, it looks like the emacsclient may not be starting up correctly. 
Could you try the attached patch? I doubt this will fix the tests, but 
hopefully you'll get some more-useful error messages.

[0001-Improve-robustness-of-server.el-tests.patch (text/plain, attachment)]

Message #31 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Fri, 25 Nov 2022 22:18:56 +0200

> Date: Fri, 25 Nov 2022 11:31:07 -0800
> Cc: 58877 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> Hm, it looks like the emacsclient may not be starting up correctly. 
> Could you try the attached patch? I doubt this will fix the tests, but 
> hopefully you'll get some more-useful error messages.

Here are the failure info from each failed test after this patch:

Test server-tests/emacsclient/create-frame condition:
    Output:
    (ert-test-failed "timed out waiting for (or (= (length server-clients) (1+ starting-client-count)) (eq (process-status emacsclient) exit-status)) to be non-nil")
   FAILED  1/7  server-tests/emacsclient/create-frame (5.062500 sec) at lisp/server-tests.el:138

Test server-tests/emacsclient/eval condition:
    Output:
    (wrong-type-argument number-or-marker-p nil)
   FAILED  2/7  server-tests/emacsclient/eval (0.109375 sec) at lisp/server-tests.el:150

Test server-tests/emacsclient/server-edit condition:
    Output:
    (ert-test-failed "timed out waiting for (get-buffer \"file.txt\") to be non-nil")
   FAILED  3/7  server-tests/emacsclient/server-edit (5.156250 sec) at lisp/server-tests.el:129

Test server-tests/server-force-stop/keeps-frames condition:
    Output:
    (ert-test-failed
     ((should
       (eq
        (process-status emacsclient)
        'run))
      :form
      (eq exit run)
      :value nil))
   FAILED  4/7  server-tests/server-force-stop/keeps-frames (0.109375 sec) at lisp/server-tests.el:159

Test server-tests/server-start/stop-prompt-with-client condition:
    Output:
    (ert-test-failed
     ((should
       (length=
        (frame-list)
        2))
      :form
      (length=
       (#<frame F1 06d263c0>)
       2)
      :value nil))
   FAILED  7/7  server-tests/server-start/stop-prompt-with-client (0.125000 sec) at lisp/server-tests.el:106

Message #34 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Fri, 25 Nov 2022 12:57:37 -0800

[Message part 1 (text/plain, inline)]

On 11/25/2022 12:18 PM, Eli Zaretskii wrote:
>> Date: Fri, 25 Nov 2022 11:31:07 -0800
>> Cc: 58877 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> Hm, it looks like the emacsclient may not be starting up correctly.
>> Could you try the attached patch? I doubt this will fix the tests, but
>> hopefully you'll get some more-useful error messages.
> 
> Here are the failure info from each failed test after this patch:
> 
> Test server-tests/emacsclient/create-frame condition:
>      Output:
>      (ert-test-failed "timed out waiting for (or (= (length server-clients) (1+ starting-client-count)) (eq (process-status emacsclient) exit-status)) to be non-nil")
>     FAILED  1/7  server-tests/emacsclient/create-frame (5.062500 sec) at lisp/server-tests.el:138

Oops, sorry about that. I didn't realize until now that 'ert-info' 
computes its message immediately, rather than at the time of printing 
the info.[1] I've added a bit of code to ert.el to support this case, 
which will hopefully produce better output.

I also added the server.el logs to the output of test failures. Note 
that they'll print the environment variables of the client, so it's 
probably worth skimming over them before posting just in case there are 
any secrets in there.

[1] Maybe there's a better way to do this, but it should at least work 
for the time being. I'm open to alternatives here so that these tests 
are as informative as possible when they fail.

[0001-Improve-robustness-of-server.el-tests.patch (text/plain, attachment)]

Message #37 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sat, 26 Nov 2022 16:43:57 +0200

> Date: Fri, 25 Nov 2022 12:57:37 -0800
> Cc: 58877 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> >> Hm, it looks like the emacsclient may not be starting up correctly.
> >> Could you try the attached patch? I doubt this will fix the tests, but
> >> hopefully you'll get some more-useful error messages.
> > 
> > Here are the failure info from each failed test after this patch:
> > 
> > Test server-tests/emacsclient/create-frame condition:
> >      Output:
> >      (ert-test-failed "timed out waiting for (or (= (length server-clients) (1+ starting-client-count)) (eq (process-status emacsclient) exit-status)) to be non-nil")
> >     FAILED  1/7  server-tests/emacsclient/create-frame (5.062500 sec) at lisp/server-tests.el:138
> 
> Oops, sorry about that. I didn't realize until now that 'ert-info' 
> computes its message immediately, rather than at the time of printing 
> the info.[1] I've added a bit of code to ert.el to support this case, 
> which will hopefully produce better output.

Never mind, I think I know what's the cause of the problem: I have my
production session of Emacs running on the system ,and it already has the
server started.  So a plain call to server-start fails.

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.

Message #40 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sat, 26 Nov 2022 11:04:48 -0800

[Message part 1 (text/plain, inline)]

On 11/26/2022 6:43 AM, Eli Zaretskii wrote:
> Never mind, I think I know what's the cause of the problem: I have my
> production session of Emacs running on the system ,and it already has the
> server started.  So a plain call to server-start fails.
> 
> 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.

[0001-Improve-robustness-of-server.el-tests.patch (text/plain, attachment)]

Message #43 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sat, 26 Nov 2022 21:45:19 +0200

> Date: Sat, 26 Nov 2022 11:04:48 -0800
> Cc: 58877 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> 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.

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?

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.

Message #46 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sat, 26 Nov 2022 12:17:59 -0800

On 11/26/2022 11:45 AM, Eli Zaretskii wrote:
>> Date: Sat, 26 Nov 2022 11:04:48 -0800
>> Cc: 58877 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> 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?

Message #49 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sat, 26 Nov 2022 22:35:57 +0200

> Date: Sat, 26 Nov 2022 12:17:59 -0800
> Cc: 58877 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> >      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?

I guess.  And I'm not prepared to spend time trying to make emacsclient work
with a batch-mode server 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?

Fine with me, thanks.

Message #52 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sat, 26 Nov 2022 13:44:50 -0800

On 11/26/2022 12:35 PM, Eli Zaretskii wrote:
>> Date: Sat, 26 Nov 2022 12:17:59 -0800
>> Cc: 58877 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> 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?
> 
> Fine with me, thanks.

Thanks. I've merged the fixes for the tests as 
14d54212ea46dbd8c950c9852318597e0e47908d. If you see any other issues, 
just let me know.

Message #55 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sun, 27 Nov 2022 17:28:41 -0800

[Message part 1 (text/plain, inline)]

On 11/26/2022 1:44 PM, Jim Porter wrote:
> On 11/26/2022 12:35 PM, Eli Zaretskii wrote:
>>> Date: Sat, 26 Nov 2022 12:17:59 -0800
>>> Cc: 58877 <at> debbugs.gnu.org
>>> From: Jim Porter <jporterbugs <at> gmail.com>
>>>
>>> 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?
>>
>> Fine with me, thanks.
> 
> Thanks. I've merged the fixes for the tests as 
> 14d54212ea46dbd8c950c9852318597e0e47908d. If you see any other issues, 
> just let me know.

Here's one tiny followup fix. Currently on master, if you restart the 
Emacs server, it emits a "Server stopped" message. That's not right, and 
it should do what it used to: emit a "Restarting server" message. Here's 
a fix.

[0001-Don-t-emit-a-Server-stopped-message-when-restarting-.patch (text/plain, attachment)]

Message #58 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Mon, 28 Nov 2022 05:31:26 +0200

> Date: Sun, 27 Nov 2022 17:28:41 -0800
> From: Jim Porter <jporterbugs <at> gmail.com>
> Cc: 58877 <at> debbugs.gnu.org
> 
> > Thanks. I've merged the fixes for the tests as 
> > 14d54212ea46dbd8c950c9852318597e0e47908d. If you see any other issues, 
> > just let me know.
> 
> Here's one tiny followup fix. Currently on master, if you restart the 
> Emacs server, it emits a "Server stopped" message. That's not right, and 
> it should do what it used to: emit a "Restarting server" message. Here's 
> a fix.

Thanks, please install.

Message #61 received at 58877 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58877 <at> debbugs.gnu.org
Subject: Re: bug#58877: 29.0.50; [PATCH] When killing Emacs from a client
 frame with no other frames, Emacs shows a useless error prompt
Date: Sun, 27 Nov 2022 22:27:40 -0800

On 11/27/2022 7:31 PM, Eli Zaretskii wrote:
>> Date: Sun, 27 Nov 2022 17:28:41 -0800
>> From: Jim Porter <jporterbugs <at> gmail.com>
>> Cc: 58877 <at> debbugs.gnu.org
>>
>> Here's one tiny followup fix. Currently on master, if you restart the
>> Emacs server, it emits a "Server stopped" message. That's not right, and
>> it should do what it used to: emit a "Restarting server" message. Here's
>> a fix.
> 
> Thanks, please install.

Thanks for taking a look. Merged as 
a85ff22300736212e38f43cc7d56e8e3d4ae1203.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.