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

[Drew Adams <drew.adams@oracle.com>]

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

Yes, that was my point: seeing Quit does not say anything about
whether a dialog or menu was displayed and dismissed.

> > Maybe Quit was there, but there are lots of Quits in *Messages*.
> > Again, that does not distinguish this situation.
> 
> Right.  Again, by design.

And again, saying to look for Quit doesn't mean much here, because
there are so many possible causes for Quit to be logged.

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

Right; that's what I noticed in my setup.  My guess was/is that
for emacs -Q the flashed display was so quick that it couldn't
be seen.

> What you reported was a real bug, I'm just describing the details
> and add some explanations, not saying it isn't a bug.

I got that.  And thanks for the info.

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

Sorry, I don't follow.  But maybe I do not need to.
I thought this was a situation where a dialog _should_ be popped up
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.

If you are asking about what flashed before me, I cannot confirm
what it was.  If you are asking whether what I saw when in the
debugger seemed like the same thing as, or similar to, what I am
used to seeing from Emacs, then the answer is yes.

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

OK, I understand now.

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

Out of curiosity, why do we think that one is better than the other?

I guess the message box is better because you can just hit RET if
you want the default?  I agree that that is important, but is that
the only reason to prefer a message box?

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

I see.  But in that case, shouldn't the menu have been displayed
normally, in place of the message box?  I would think that the
problem was the invisible and automatically dismissed menu, not
the fact that the menu was used instead of a message box.  I feel
like I must be missing something, but I'm guessing that it's not
important that I understand.

> Hope you understand the issue better now.

I do, though obviously not completely.  Thx.