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

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

[Drew Adams]

emacs -Q

Eval this after bring up Dired:

(defun diredp-mouse-find-file-other-frame (event)
  (interactive "e")
  (let ((pop-up-frames  t)) (dired-mouse-find-file-other-window event)))

(define-key dired-mode-map [M-mouse-2] 'diredp-mouse-find-file-other-frame)

In another Emacs session, modify one of the files listed in the Dired
buffer.  Then click M-mouse-2 on it in the Dired buffer.

In my own setup I at least see a brief flash of a message.  I see
nothing at all happen with emacs -Q.  I look in *Messages* but nothing
is recorded there ("normal").  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
(since `use-file-dialog' = t):

 File blah.el changed on disk. Reread from disk?

That is the message that was flashed (in my setup, at least).  It
disappeared as soon as it was displayed, and it did not wait for any
mouse-click confirmation or canceling.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-02 on ODIEONE
Bzr revision: 116242 rudalics@gmx.at-20140202130041-n967dw77nw7ztvy9
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

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

[Eli Zaretskii]

> Date: Mon, 3 Feb 2014 20:07:26 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> emacs -Q
> 
> Eval this after bring up Dired:
> 
> (defun diredp-mouse-find-file-other-frame (event)
>   (interactive "e")
>   (let ((pop-up-frames  t)) (dired-mouse-find-file-other-window event)))
> 
> (define-key dired-mode-map [M-mouse-2] 'diredp-mouse-find-file-other-frame)
> 
> In another Emacs session, modify one of the files listed in the Dired
> buffer.  Then click M-mouse-2 on it in the Dired buffer.
> 
> In my own setup I at least see a brief flash of a message.  I see
> nothing at all happen with emacs -Q.

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

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

>  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, as Emacs tried to emulate a dialog box with a menu.  But
for a "simple dialog" such as yes/no, Emacs should have displayed a
MessageBox instead.

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.

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

[Drew Adams]

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

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.

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

[Drew Adams]

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

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

[Eli Zaretskii]

> Date: Tue, 4 Feb 2014 10:51:42 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16636@debbugs.gnu.org
> 
> > 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 because it is closer to a real dialog box, with buttons and
such likes.  It's just that no one wrote the code to implement dialogs
on Windows (more accurately, the code is incomplete and disabled), so
we are using cheap and easy replacements.

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

I don't know, I wasn't around when that was written.

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

You are not missing anything.  It is quite possible that a separate
problem still exists that causes menus to pop down without giving the
user a chance to make a selection, in some situations.  Probably some
unexpected event comes in after the menu is displayed and causes it to
pop down.  But I cannot reproduce this after fixing the message box
display, not with your recipe, anyway.  If you see any such problems,
please report them with the recipe to reproduce.

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

[Drew Adams]

> I cannot reproduce this after fixing the message box
> display, not with your recipe, anyway.  If you see any such
> problems, please report them with the recipe to reproduce.

Thx; will do.