bug#63655: 29.0.91; Dialog box not displayed upon closing frame

bug#63655: 29.0.91; Dialog box not displayed upon closing frame

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Start Emacs, then set confirm-kill-emacs to t.
Close the last frame on the only terminal by clicking the close button
on the WM frame window.  Emacs will ask:

  Really exit Emacs? (y or n)

in the echo area, instead of displaying a popup dialog as in Emacs 28.
This makes it difficult to close Emacs using only the mouse.

bug#63655: 29.0.91; Dialog box not displayed upon closing frame

[Eli Zaretskii]

> Date: Tue, 23 May 2023 13:12:38 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Start Emacs, then set confirm-kill-emacs to t.
> Close the last frame on the only terminal by clicking the close button
> on the WM frame window.  Emacs will ask:
> 
>   Really exit Emacs? (y or n)

confirm-kill-emacs, if non-nil, should be a function.  If I try what
you described above, Emacs signals an error when I close the last
frame.

bug#63655: 29.0.91; Dialog box not displayed upon closing frame

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 23 May 2023 13:12:38 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Start Emacs, then set confirm-kill-emacs to t.
>> Close the last frame on the only terminal by clicking the close button
>> on the WM frame window.  Emacs will ask:
>> 
>>   Really exit Emacs? (y or n)
>
> confirm-kill-emacs, if non-nil, should be a function.  If I try what
> you described above, Emacs signals an error when I close the last
> frame.

Sorry, I meant to set it to `y-or-n-p'.  I did that from Custom.

bug#63655: 29.0.91; Dialog box not displayed upon closing frame

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 63655@debbugs.gnu.org
> Date: Tue, 23 May 2023 20:07:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>   Really exit Emacs? (y or n)
> >
> > confirm-kill-emacs, if non-nil, should be a function.  If I try what
> > you described above, Emacs signals an error when I close the last
> > frame.
> 
> Sorry, I meant to set it to `y-or-n-p'.  I did that from Custom.

Does the patch below give good results?

diff --git a/lisp/subr.el b/lisp/subr.el
index 52227b5..9aa28d9 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3544,6 +3544,8 @@ use-dialog-box-p
   "Return non-nil if the current command should prompt the user via a dialog box."
   (and last-input-event                 ; not during startup
        (or (consp last-nonmenu-event)   ; invoked by a mouse event
+           (and (null last-nonmenu-event)
+                (consp last-input-event))
            from--tty-menu-p)            ; invoked via TTY menu
        use-dialog-box))
 
diff --git a/src/fns.c b/src/fns.c
index e8cd621..e01739c 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -3193,8 +3193,11 @@ DEFUN ("yes-or-no-p", Fyes_or_no_p, Syes_or_no_p, 1, 1, 0,
 
   CHECK_STRING (prompt);
 
-  if ((NILP (last_nonmenu_event) || CONSP (last_nonmenu_event))
-      && use_dialog_box && ! NILP (last_input_event))
+  if (!NILP (last_input_event)
+      && (CONSP (last_nonmenu_event)
+	  || (NILP (last_nonmenu_event) && CONSP (last_input_event))
+	  || !NILP (find_symbol_value (Qfrom__tty_menu_p)))
+      && use_dialog_box)
     {
       Lisp_Object pane, menu, obj;
       redisplay_preserve_echo_area (4);
@@ -6358,4 +6361,5 @@ syms_of_fns (void)
   defsubr (&Sbuffer_line_statistics);
 
   DEFSYM (Qreal_this_command, "real-this-command");
+  DEFSYM (Qfrom__tty_menu_p, "from--tty-menu-p");
 }

bug#63655: 29.0.91; Dialog box not displayed upon closing frame

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: 63655@debbugs.gnu.org
>> Date: Tue, 23 May 2023 20:07:58 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >>   Really exit Emacs? (y or n)
>> >
>> > confirm-kill-emacs, if non-nil, should be a function.  If I try what
>> > you described above, Emacs signals an error when I close the last
>> > frame.
>> 
>> Sorry, I meant to set it to `y-or-n-p'.  I did that from Custom.
>
> Does the patch below give good results?
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 52227b5..9aa28d9 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -3544,6 +3544,8 @@ use-dialog-box-p
>    "Return non-nil if the current command should prompt the user via a dialog box."
>    (and last-input-event                 ; not during startup
>         (or (consp last-nonmenu-event)   ; invoked by a mouse event
> +           (and (null last-nonmenu-event)
> +                (consp last-input-event))
>             from--tty-menu-p)            ; invoked via TTY menu
>         use-dialog-box))
>  
> diff --git a/src/fns.c b/src/fns.c
> index e8cd621..e01739c 100644
> --- a/src/fns.c
> +++ b/src/fns.c
> @@ -3193,8 +3193,11 @@ DEFUN ("yes-or-no-p", Fyes_or_no_p, Syes_or_no_p, 1, 1, 0,
>  
>    CHECK_STRING (prompt);
>  
> -  if ((NILP (last_nonmenu_event) || CONSP (last_nonmenu_event))
> -      && use_dialog_box && ! NILP (last_input_event))
> +  if (!NILP (last_input_event)
> +      && (CONSP (last_nonmenu_event)
> +	  || (NILP (last_nonmenu_event) && CONSP (last_input_event))
> +	  || !NILP (find_symbol_value (Qfrom__tty_menu_p)))
> +      && use_dialog_box)
>      {
>        Lisp_Object pane, menu, obj;
>        redisplay_preserve_echo_area (4);
> @@ -6358,4 +6361,5 @@ syms_of_fns (void)
>    defsubr (&Sbuffer_line_statistics);
>  
>    DEFSYM (Qreal_this_command, "real-this-command");
> +  DEFSYM (Qfrom__tty_menu_p, "from--tty-menu-p");
>  }

Yes, it does.  Thanks.

BTW, could we please not change yes-or-no-p on the release branch?  It's
not involved in y-or-n-p, and doing so makes me skittish for a reason
you can surely understand.

bug#63655: 29.0.91; Dialog box not displayed upon closing frame

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 63655@debbugs.gnu.org
> Date: Tue, 23 May 2023 21:16:40 +0800
> 
> Yes, it does.  Thanks.

Thanks, installed on the release branch, after some cleanup and update
of the docs.

> BTW, could we please not change yes-or-no-p on the release branch?  It's
> not involved in y-or-n-p, and doing so makes me skittish for a reason
> you can surely understand.

I'm just being proactive -- the very next bug report we will get is
why yes-or-no-p behaves differently wrt use of dialog boxes.  Even in
the recipe you posted here, yes-or-no-p behaved differently.  It makes
no sense to me to have such subtle differences, especially when many
people replace one of these function by the other, and we even have a
user option nowadays to do that automatically.

bug#63655: 29.0.91; Dialog box not displayed upon closing frame

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm just being proactive -- the very next bug report we will get is
> why yes-or-no-p behaves differently wrt use of dialog boxes.  Even in
> the recipe you posted here, yes-or-no-p behaved differently.  It makes
> no sense to me to have such subtle differences, especially when many
> people replace one of these function by the other, and we even have a
> user option nowadays to do that automatically.

I think we really ought to wait until a complaint to make this change on
emacs-29.  I'm fine with doing it on master.

Thanks.

bug#63655: 29.0.91; Dialog box not displayed upon closing frame

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 63655-done@debbugs.gnu.org
> Date: Wed, 24 May 2023 08:18:31 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm just being proactive -- the very next bug report we will get is
> > why yes-or-no-p behaves differently wrt use of dialog boxes.  Even in
> > the recipe you posted here, yes-or-no-p behaved differently.  It makes
> > no sense to me to have such subtle differences, especially when many
> > people replace one of these function by the other, and we even have a
> > user option nowadays to do that automatically.
> 
> I think we really ought to wait until a complaint to make this change on
> emacs-29.  I'm fine with doing it on master.

I understand, but I think we are fine with the change on emacs-29.  If
I'm wrong, we'd know soon enough.