bug#16636: 24.3.50; REGRESSION: y/n file dialog is only flashed; input is not read

[Eli Zaretskii]

> Date: Tue, 4 Feb 2014 08:30:07 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16636-done@debbugs.gnu.org
> 
> > 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.

It isn't distinguishable by design: dismissing a menu is translated
into a keyboard quit.  You can try this with any menu in Emacs --
after dropping down a menu, just click somewhere outside the menu, and
you will see "Quit" in the echo area.

> > > 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.

Right.  Again, by design.

> 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.

The menu flashes very quickly.  And yes, you never selected anything,
and the dialog still popped down -- that's the bug.  What you reported
was a real bug, I'm just describing the details and add some
explanations, not saying it isn't a bug.

> > >  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?

>From a dialog that should be popped up when Emacs wants to ask a
yes/no question.

> What I see when using the debugger is what I normally see when Emacs
> asks a question using a dialog box.

Are you sure?  Because that's not what I saw, before fixing the bug.
I saw an emulation of a dialog box with a menu.

To see what I mean, compare the effect of evaluating the following two
expressions:

  (let ((fr (selected-frame)))
    (x-popup-dialog fr
                    '("Dialog" ("Foo" . t) ("Bar" . nil) ("Baz" . maybe))))

  (let ((fr (selected-frame)))
    (x-popup-dialog fr
                    '("Dialog" ("Yes" . t) ("No" . nil))))

(Since you don't yet have a binary where the bug is fixed, try this in
an Emacs that was built before Oct 2013.)  Do you see how Emacs
displays a message box for the latter, but not for the former?  Now
try the same with the recent trunk, e.g. the one where you saw this
bug, and see how the second case looks similar to the first.

For "simple" Yes/No questions, Emacs on Windows uses a message box.
For more complex dialogs, it displays a menu, because no one has yet
written code that displays Windows dialog boxes for that.

The bug happened because the code which invokes the "simple dialog"
was inadvertently deleted.

> > 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.

Right, because of the bug.  But even when the dialog _is_ displayed,
the same bug displays it incorrectly, see above.

> > 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.

Hope you understand the issue better now.