Change to `use-dialog-box-p'

Change to `use-dialog-box-p'

[Po Lu]

After:

2023-04-02  Eli Zaretskii  <eliz@gnu.org>

	* lisp/subr.el (use-dialog-box-p): Fix conditions for GUI dialogs.

dialog boxes will no longer be used when there is no last input event at
all, i.e. when `last-nonmenu-event' is nil.

Previously, `use-dialog-box-p' would only return nil if
`last-nonmenu-event' was a key event, which is the correct behavior;
`Fyes_or_no_p' still uses the correct test.

Why was that change made?

Re: Change to `use-dialog-box-p'

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Sat, 20 May 2023 10:45:21 +0800
> 
> After:
> 
> 2023-04-02  Eli Zaretskii  <eliz@gnu.org>
> 
> 	* lisp/subr.el (use-dialog-box-p): Fix conditions for GUI dialogs.
> 
> dialog boxes will no longer be used when there is no last input event at
> all, i.e. when `last-nonmenu-event' is nil.
> 
> Previously, `use-dialog-box-p' would only return nil if
> `last-nonmenu-event' was a key event, which is the correct behavior;
> `Fyes_or_no_p' still uses the correct test.
> 
> Why was that change made?

Because last-nonmenu-event being nil happens in too many cases where
showing the GUI dialog is not TRT.  Immediately after startup, for
example.

What is the situation where you need to show a GUI dialog even though
last-nonmenu-event is nil?

Re: Change to `use-dialog-box-p'

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Because last-nonmenu-event being nil happens in too many cases where
> showing the GUI dialog is not TRT.  Immediately after startup, for
> example.
>
> What is the situation where you need to show a GUI dialog even though
> last-nonmenu-event is nil?

Precisely this one: immediately after start up.  I don't understand why
it's not correct to show a dialog box in that situation; in many cases,
it's much easier to use the dialog box than to use the keyboard.

Re: Change to `use-dialog-box-p'

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 20 May 2023 14:29:44 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Because last-nonmenu-event being nil happens in too many cases where
> > showing the GUI dialog is not TRT.  Immediately after startup, for
> > example.
> >
> > What is the situation where you need to show a GUI dialog even though
> > last-nonmenu-event is nil?
> 
> Precisely this one: immediately after start up.  I don't understand why
> it's not correct to show a dialog box in that situation; in many cases,
> it's much easier to use the dialog box than to use the keyboard.

Can you show a specific recipe where this happens?  Otherwise it is
hard to reason about the issue.

AFAIR, without that change, just invoking y-or-n-p after startup would
show a GUI dialog, and that doesn't sound right to me.

IME, showing GUI dialogs by default is not TRT, because Emacs
generally defaults to keyboard input via the minibuffer, and only
shows the GUI dialog when the command was invoked via a mouse or from
a menu.  In other cases we don't force users to use the mouse for
Emacs interaction.

Re: Change to `use-dialog-box-p'

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you show a specific recipe where this happens?  Otherwise it is
> hard to reason about the issue.

Yes: when Emacs starts, I restack the frame below another window.  After
startup completes, a dialog is displayed asking me whether or not I want
to restore the desktop save file, at which point I confirm the dialog
and return to Emacs.  Or at least that's how should -- and did -- behave
prior to this change.

Re: Change to `use-dialog-box-p'

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 20 May 2023 16:32:24 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you show a specific recipe where this happens?  Otherwise it is
> > hard to reason about the issue.
> 
> Yes: when Emacs starts, I restack the frame below another window.

Restack how? with what commands or gestures?

> After startup completes, a dialog is displayed asking me whether or
> not I want to restore the desktop save file, at which point I
> confirm the dialog and return to Emacs.  Or at least that's how
> should -- and did -- behave prior to this change.

Why would Emacs pop up a GUI dialog by default in this situation?
IOW, what would be the reason for us to show a GUI dialog, which
requires the user to use the mouse?

Re: Change to `use-dialog-box-p'

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Restack how? with what commands or gestures?

By clicking that other window.  It's maximized, so it fills the whole
screen and obscures Emacs.

> Why would Emacs pop up a GUI dialog by default in this situation?
> IOW, what would be the reason for us to show a GUI dialog, which

To alert him that Emacs has finished starting up.

> requires the user to use the mouse?

Not necessarily; typing RET also confirms the dialog.

Re: Change to `use-dialog-box-p'

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 20 May 2023 19:17:29 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Restack how? with what commands or gestures?
> 
> By clicking that other window.  It's maximized, so it fills the whole
> screen and obscures Emacs.
> 
> > Why would Emacs pop up a GUI dialog by default in this situation?
> > IOW, what would be the reason for us to show a GUI dialog, which
> 
> To alert him that Emacs has finished starting up.
> 
> > requires the user to use the mouse?
> 
> Not necessarily; typing RET also confirms the dialog.

On what OS?

Anyway, I see no reason to change the current behavior due to this
scenario and similar ones.  Emacs didn't see any mouse-related input,
so it has no reason to prefer GUI dialogs.  We will surprise and annoy
users if we do.

Re: Change to `use-dialog-box-p'

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> On what OS?

X, with both Motif and no toolkit (where the XMenu library is used for
dialog boxes.)

> Anyway, I see no reason to change the current behavior due to this
> scenario and similar ones.  Emacs didn't see any mouse-related input,
> so it has no reason to prefer GUI dialogs.  We will surprise and annoy
> users if we do.

But the existing behavior has existed for a very long time, and its
removal is now surprising me, and probably others as well.  I'd hate to
need to advise use-dialog-box-p...

Re: Change to `use-dialog-box-p'

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 21 May 2023 08:47:18 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > On what OS?
> 
> X, with both Motif and no toolkit (where the XMenu library is used for
> dialog boxes.)

I guess that's only with a Yes/No dialog, and only if you press RET to
accept the default response.  But GUI dialogs can show much more than
that, and this function is for all of them.  It would be unthinkable
for us to pop up a File Selection dialog, for example, when
last-nonmenu-event is nil.

> > Anyway, I see no reason to change the current behavior due to this
> > scenario and similar ones.  Emacs didn't see any mouse-related input,
> > so it has no reason to prefer GUI dialogs.  We will surprise and annoy
> > users if we do.
> 
> But the existing behavior has existed for a very long time, and its
> removal is now surprising me, and probably others as well.  I'd hate to
> need to advise use-dialog-box-p...

If you want to convince me to make some change, please describe how to
distinguish between this particular case which is of interest to you
and the other ones, when last-nonmenu-event is nil.

And even then I still don't see why we should pop up a GUI dialog in
this situation.  Once again: Emacs defaults to not showing GUI
dialogs, it's our long-time behavior, and this situation doesn't seem
to have any aspects that would require us to show a dialog.  It is
simply a bug that we were showing a dialog in previous versions: the
code didn't distinguish between nil and a proper list.  Just get over
it.

Re: Change to `use-dialog-box-p'

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I guess that's only with a Yes/No dialog, and only if you press RET to
> accept the default response.  But GUI dialogs can show much more than
> that, and this function is for all of them.  It would be unthinkable
> for us to pop up a File Selection dialog, for example, when
> last-nonmenu-event is nil.

Right, but then, what could lead to a file selection dialog being
displayed immediately after startup?

> If you want to convince me to make some change, please describe how to
> distinguish between this particular case which is of interest to you
> and the other ones, when last-nonmenu-event is nil.

How about ``if the function displaying the dialog is y-or-n-p?''  BTW,
this is simply a specific case which happens to affect me; the change
could also affect many other people.

> And even then I still don't see why we should pop up a GUI dialog in
> this situation.  Once again: Emacs defaults to not showing GUI
> dialogs, it's our long-time behavior, and this situation doesn't seem
> to have any aspects that would require us to show a dialog.  It is
> simply a bug that we were showing a dialog in previous versions: the
> code didn't distinguish between nil and a proper list.

But then, why does yes-or-no-p say:

  If dialog boxes are supported, a dialog box will be used
  if `last-nonmenu-event' is nil, and `use-dialog-box' is non-nil.

I would expect use-dialog-box-p to behave identically to yes-or-no-p.

> Just get over it.

I don't think that's the right attitude to take towards user visible
changes in behavior.

Thanks.

Re: Change to `use-dialog-box-p'

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 21 May 2023 14:41:48 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I guess that's only with a Yes/No dialog, and only if you press RET to
> > accept the default response.  But GUI dialogs can show much more than
> > that, and this function is for all of them.  It would be unthinkable
> > for us to pop up a File Selection dialog, for example, when
> > last-nonmenu-event is nil.
> 
> Right, but then, what could lead to a file selection dialog being
> displayed immediately after startup?

Where's the condition "immediately after startup" in this case?  This
function is general-purpose.

And why should a question Emacs asks after startup _always_ pop up the
GUI dialog?  Such behavior makes no sense at all!

> > If you want to convince me to make some change, please describe how to
> > distinguish between this particular case which is of interest to you
> > and the other ones, when last-nonmenu-event is nil.
> 
> How about ``if the function displaying the dialog is y-or-n-p?''

No, not good enough.  We ask these questions all the time.  See below
for some descriptive examples.

> > And even then I still don't see why we should pop up a GUI dialog in
> > this situation.  Once again: Emacs defaults to not showing GUI
> > dialogs, it's our long-time behavior, and this situation doesn't seem
> > to have any aspects that would require us to show a dialog.  It is
> > simply a bug that we were showing a dialog in previous versions: the
> > code didn't distinguish between nil and a proper list.
> 
> But then, why does yes-or-no-p say:
> 
>   If dialog boxes are supported, a dialog box will be used
>   if `last-nonmenu-event' is nil, and `use-dialog-box' is non-nil.
> 
> I would expect use-dialog-box-p to behave identically to yes-or-no-p.

Is this a documentation problem?  Augmenting yes-or-no-p's doc string
is easy.  Or do you mean that you want

  emacs -Q --eval "(yes-or-no-p \"What?\")"

to pop up a GUI dialog?

Also, please note that use-dialog-box is nowadays non-nil on TTY
frames as well, so what you want will make

  emacs -Q -nw --eval "(yes-or-no-p \"What?\")"

pop up the dialog as well.  Is that reasonable behavior?

Btw, use-dialog-box-p also looks at last-input-event, and only pops up
a dialog box if that is non-nil.  In your scenario, is
last-input-event non-nil?  If so, what is it, and where did it come
from?

> > Just get over it.
> 
> I don't think that's the right attitude to take towards user visible
> changes in behavior.

It's not a "behavior", it's a bug!  The behavior we will get with the
change you suggest will surprise (and annoy) many more users!

Re: Re: Change to `use-dialog-box-p'

[Pedro A. Aranda Gutiérrez]

Eli writes,

 > It's not a "behavior", it's a bug!  The behavior we will get with the
 > change you suggest will surprise (and annoy) many more users!

This thread comes in quite timely. I was wondering whether there is a 
way to avoid GUI dialogs completely, even when you trigger a 
functionality from the menu. Simple example would be 'File'->'Save as'. 
Hidden files and directories are much easier accessed from the 
minibuffer than from the GUI. So sometimes it's describe-key for the 
menu-entry and then M-x the function and that's a bit convoluted from 
the user point-of-view.


Thx, /PA

PS: This might be an RTFM, but I hope it gives you more input in your 
discussion.

Re: Change to `use-dialog-box-p'

[Po Lu]

Pedro A. Aranda Gutiérrez <paaguti@gmail.com> writes:

> Eli writes,
>
>> It's not a "behavior", it's a bug!  The behavior we will get with the
>> change you suggest will surprise (and annoy) many more users!

But we've had this old behavior for decades without complaints.

> This thread comes in quite timely. I was wondering whether there is a
> way to avoid GUI dialogs completely

Customize the variable use-dialog-box.

Thanks.

Re: Change to `use-dialog-box-p'

[Pedro Andres Aranda Gutierrez]

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

On Mon, 22 May 2023 at 11:27, Po Lu <luangruo@yahoo.com> wrote:

> Pedro A. Aranda Gutiérrez <paaguti@gmail.com> writes:
>
> > Eli writes,
> >
> >> It's not a "behavior", it's a bug!  The behavior we will get with the
> >> change you suggest will surprise (and annoy) many more users!
>
> But we've had this old behavior for decades without complaints.
>

Maybe because some of us are not very vocal ;-) or have other more pressing
issues
but I wasn't too happy with this.


> > This thread comes in quite timely. I was wondering whether there is a
> > way to avoid GUI dialogs completely
>
> Customize the variable use-dialog-box.
>

Yes, again, you are right and it surely is an RTFM but the info is
somewhere down in Chapter 21.x ;-)

Thank you...

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1912 bytes --]

Re: Change to `use-dialog-box-p'

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org,  eliz@gnu.org
> Date: Mon, 22 May 2023 17:27:25 +0800
> 
> Pedro A. Aranda Gutiérrez <paaguti@gmail.com> writes:
> 
> > Eli writes,
> >
> >> It's not a "behavior", it's a bug!  The behavior we will get with the
> >> change you suggest will surprise (and annoy) many more users!
> 
> But we've had this old behavior for decades without complaints.

The situation you are talking about almost never happens, because
last-nonmenu-event is almost never nil.  So the lack of complaints
does not surprise me.

And you haven't answered my question:

> Btw, use-dialog-box-p also looks at last-input-event, and only pops up
> a dialog box if that is non-nil.  In your scenario, is
> last-input-event non-nil?  If so, what is it, and where did it come
> from?

Please answer this, I think there's some factor here we need to
understand.  Right after startup, last-input-event should be nil.

Re: Change to `use-dialog-box-p'

[Samuel Wales]

btw in my case i am in either kb mode or gui mode; i do not combine
them as that is an accessibility issue.

btw there is at least one case where you want gui when you invoked the
command kb, and kb when you invoked it gui: type-break.el.  what it
/should/ do in its ... hook? is find out if you are /currently/ using
kb or gui, then match that.

i am not on the mailing list.  if anything significant, please cc me.

Re: Change to `use-dialog-box-p'

[Eli Zaretskii]

> From: Samuel Wales <samologist@gmail.com>
> Date: Mon, 22 May 2023 18:39:46 -0700
> 
> btw in my case i am in either kb mode or gui mode; i do not combine
> them as that is an accessibility issue.
> 
> btw there is at least one case where you want gui when you invoked the
> command kb, and kb when you invoked it gui: type-break.el.  what it
> /should/ do in its ... hook? is find out if you are /currently/ using
> kb or gui, then match that.

I don't think I understand the issue, but one possibility is to invoke
x-popup-dialog directly.