[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 10:51:42 -0800 (PST) |
> 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.