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

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.