[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16636: 24.3.50; REGRESSION: y/n file dialog is only flashed; input i
From: |
Drew Adams |
Subject: |
bug#16636: 24.3.50; REGRESSION: y/n file dialog is only flashed; input is not read |
Date: |
Tue, 4 Feb 2014 08:30:07 -0800 (PST) |
> You should hear the "ding" that is sounded when you type C-g or
> dismiss a menu. (And the file in question should have been already
> visited inside Emacs before the "in another Emacs session" step,
> otherwise Emacs has no need to display any dialogs.)
OK, but I had sound turned off (as I usually do). But that's a
good reminder. Still, that does not distinguish this situation
from, as you say, C-g and other events.
> > I look in *Messages* but nothing is recorded there ("normal").
>
> You should see "Quit" there, which is a sign that none of the
> possible selections were chosen, i.e. the dialog was dismissed
> without making a selection.
Maybe Quit was there, but there are lots of Quits in *Messages*.
Again, that does not distinguish this situation.
And I did not dismiss any dialog without making a selection.
I never saw any dialog. I never saw any question posed, in any
manner.
> > There should have been a file dialog displayed, and it should
> > have waited for me to click y or n to dismiss it.
> >
> > Do `M-x debug-on-entry diredp-mouse-find-file-other-frame', then
> > repeat: click `M-mouse-2' on the same (modified) file. Walk
> > through the debugger and you will see the file dialog displayed
> > as it should be
>
> Displayed, yes. But not "as it should be": the appearance is
> entirely different,
Different from what? What I see when using the debugger is what
I normally see when Emacs asks a question using a dialog box.
> as Emacs tried to emulate a dialog box with a menu.
No idea what that means or why it is important. I saw no
question asked, regardless of how the question might be displayed.
> But for a "simple dialog" such as yes/no, Emacs should have
> displayed a MessageBox instead.
See previous.
> Sorry, this was my bad: some code which supported this use case was
> inadvertently deleted when the TTY menus were implemented.
>
> Now fixed in trunk revision 116260.
OK, thanks. I understood only part of what you wrote. But this
part I understand, at least. Thx.