commands invoked by the mouse -> commands invoked from the menu bar

commands invoked by the mouse -> commands invoked from the menu bar

[Lennart Borgman]

In "(emacs) Visiting" there is written

    commands invoked with the mouse (by clicking on the menu bar or tool
    bar) use the toolkit's standard File Selection dialog instead of
    prompting for the file name in the minibuffer.

Should it not be like this instead:

    commands invoked from the menu bar (from the keyboard or with the
    mouse) use the toolkit's standard File Selections dialog ...

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Luc Teirlinck]

Lennart Borgman wrote:

   In "(emacs) Visiting" there is written

       commands invoked with the mouse (by clicking on the menu bar or tool
       bar) use the toolkit's standard File Selection dialog instead of
       prompting for the file name in the minibuffer.

   Should it not be like this instead:

       commands invoked from the menu bar (from the keyboard or with the
       mouse) use the toolkit's standard File Selections dialog ...

I can not check, since I use the Lucid toolkit, so I _always_ get
asked in the minibuffer for filenames (fortunately).

I would expect the current text to be correct.  Does the alternative
text you give describe what _actually_ happens?  I do believe that
this would be a misfeature since if the user invoked the menu bar with
the keyboard, he probably prefers to keep using the keyboard and the
minibuffer.  If the user did not use a mouse to invoke a command, then
there is no evidence that the user is actually able to use a mouse.
At first view (I normally avoid having to use them) some of these File
Selection dialogs seem inconvenient (at best) to use without a mouse.

Does the alternative you describe even happen for `emacs -nw', the
_usual_ situation under which people invoke the menu bar from the
keyboard?  That would surprise me very much.

Sincerely,

Luc.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Jason Rumney]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Lennart Borgman wrote:
>
>    In "(emacs) Visiting" there is written
>
>        commands invoked with the mouse (by clicking on the menu bar or tool
>        bar) use the toolkit's standard File Selection dialog instead of
>        prompting for the file name in the minibuffer.
>
>    Should it not be like this instead:
>
>        commands invoked from the menu bar (from the keyboard or with the
>        mouse) use the toolkit's standard File Selections dialog ...

The second is no more accurate than the first, as it leaves out the
fact that clicking on the tool bar will use the toolkit dialog.

> I would expect the current text to be correct.

The actual condition (in fileio.c) is

#if defined (USE_MOTIF) || defined (HAVE_NTGUI) || defined (USE_GTK) || defined (HAVE_CARBON)
  if ((NILP (last_nonmenu_event) || CONSP (last_nonmenu_event))
      && use_dialog_box
      && use_file_dialog
      && have_menus_p ())
    return Qt;
#endif
  return Qnil;


So it seems to me, that if menus are disabled, then even tool bar
mouse events will not bring up a dialog, which is probably a
bug. Otherwise, it seems that the event which brings up the menu is
what is important. But on Windows, the behaviour is as Lennart
describes - ie the key sequence F10 down RET brings up the
dialog. Perhaps menu events are being saved in last_nonmenu_event, at
least on Windows.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Lennart Borgman]

Jason Rumney wrote:
> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
>
>   
>> Lennart Borgman wrote:
>>
>>    In "(emacs) Visiting" there is written
>>
>>        commands invoked with the mouse (by clicking on the menu bar or tool
>>        bar) use the toolkit's standard File Selection dialog instead of
>>        prompting for the file name in the minibuffer.
>>
>>    Should it not be like this instead:
>>
>>        commands invoked from the menu bar (from the keyboard or with the
>>        mouse) use the toolkit's standard File Selections dialog ...
>>     
>
> The second is no more accurate than the first, as it leaves out the
> fact that clicking on the tool bar will use the toolkit dialog.
>   
Sorry, I forgot the toolbar. It should have been "the menu bar or the 
toolbar".

> So it seems to me, that if menus are disabled, then even tool bar
> mouse events will not bring up a dialog, which is probably a
> bug. Otherwise, it seems that the event which brings up the menu is
> what is important. But on Windows, the behaviour is as Lennart
> describes - ie the key sequence F10 down RET brings up the
> dialog. Perhaps menu events are being saved in last_nonmenu_event, at
> least on Windows.
>   
What is the intended behaviour? Luc expects that the dialog would not be 
shown when F10 down RET is used. I am not sure. The actual behaviour now 
is to show the dialog on w32 and this is consistent with other 
applications on w32. (Which of course mostly does not have an 
alternative to the file dialog.)

Maybe the behaviour should be ruled by an option?

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Maybe the behaviour should be ruled by an option?

The behaviour is already ruled by two options (which is one too many
IMHO), I don't think we need another one to cover a subtle edge case.
We should either fix this by changing the code to match the
documentation or the documentation to match the code, after first
deciding which is the least surprising/most useful way for it to work.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Richard Stallman]

    #if defined (USE_MOTIF) || defined (HAVE_NTGUI) || defined (USE_GTK) || defined (HAVE_CARBON)
      if ((NILP (last_nonmenu_event) || CONSP (last_nonmenu_event))
	  && use_dialog_box
	  && use_file_dialog
	  && have_menus_p ())
	return Qt;

    So it seems to me, that if menus are disabled, then even tool bar
    mouse events will not bring up a dialog, which is probably a
    bug.

What do you mean by "if menus are disabled"?
have_menus_p checks whether menus are _supported_.
It assumes that if menus are not supported, no file dialog is
supported either.  Is that ever wrong?

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> What do you mean by "if menus are disabled"?
> have_menus_p checks whether menus are _supported_.
> It assumes that if menus are not supported, no file dialog is
> supported either.  Is that ever wrong?

I misunderstood. If that is the case, I doubt it is ever wrong.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Jason Rumney]

Jason Rumney <jasonr@gnu.org> writes:

> Perhaps menu events are being saved in last_nonmenu_event, at
> least on Windows.

In keyboard.c, I see the following comment. So the menu-bar event
seems to be deliberately saved in last_nonmenu_event on all toolkit
based builds.

#if defined (USE_X_TOOLKIT) || defined (HAVE_NTGUI) || defined(MAC_OS) \
    || defined (USE_GTK)
	      /* If this was a menu selection, then set the flag to inhibit
		 writing to last_nonmenu_event.  Don't do this if the event
		 we're returning is (menu-bar), though; that indicates the
		 beginning of the menu sequence, and we might as well leave
		 that as the `event with parameters' for this selection.  */

Although the comment says "we might as well leave that", it is
actually quite important that we leave it on Windows and possibly with
some or all of the other toolkits listed, since we do not see any
events that are processed by the menu bar, including the mouse event
that started the sequence.

ie. Using the mouse to select the open-file menu item, view-lossage
    reports: <menu-bar> <file> <open-file>

    Using F10 and arrow keys to select the same menu item,
    view-lossage reports: <f10> <menu-bar> <file> <open-file>


So unless we look at the event before the menu-bar event and check its
binding (which may involve prior events - how do we tell when working
backwards?) to see if it might have caused the menu to open, we cannot
tell whether the mouse or keyboard was used.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Luc Teirlinck]

Jason Rumney wrote:

   Although the comment says "we might as well leave that", it is
   actually quite important that we leave it on Windows and possibly with
   some or all of the other toolkits listed, since we do not see any
   events that are processed by the menu bar, including the mouse event
   that started the sequence.

Then we may have no choice in as far as the behavior goes.  In as far
as the doc goes, the current description actually correctly describes
the intent, although for technical reasons, that intent can not always
be realized.  To be complete we should mention that, when Emacs is
built with a suitable GUI toolkit, Emacs uses a file dialog when the
user invokes the menu bar from the keyboard, _except_ under
`emacs -nw'.  It is not immediately clear to me that it is worth
adding an extra sentence stating this, since I am not completely sure
that this is more than a technical detail.  I have no strong opinion
on this.  We would probably need an xref to the description of `-nw'.
The current text does not say that Emacs _only_ uses a file dialog for
commands invoked with the mouse and in absolutely no other situations,
although maybe it might be viewed as implicitly inferring that.

Sincerely,

Luc.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Eli Zaretskii]

> Date: Sun, 14 May 2006 22:37:50 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> Cc: lennart.borgman.073@student.lu.se, emacs-devel@gnu.org
> 
> To be complete we should mention that, when Emacs is
> built with a suitable GUI toolkit, Emacs uses a file dialog when the
> user invokes the menu bar from the keyboard, _except_ under
> `emacs -nw'.

Under -nw, we have no functional menu bar, only its very distant and
dissimilar emulation.  I don't think we even should mention tmm when
we talk about the menu bar.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Luc Teirlinck]

Eli Zaretskii wrote:

   Under -nw, we have no functional menu bar, only its very distant and
   dissimilar emulation.  I don't think we even should mention tmm when
   we talk about the menu bar.

This entire thread has been about tmm, whether on a window system or
under -nw, not about the regular mouse menubar.

Sincerely,

Luc.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Eli Zaretskii]

> Date: Mon, 15 May 2006 18:01:49 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> CC: lennart.borgman.073@student.lu.se, emacs-devel@gnu.org, jasonr@gnu.org
> 
> This entire thread has been about tmm

No, it wasn't, at least not AFAIU.  In my understanding it was about
the feature on MS-Windows, whereby in a graphics session (without -nw)
typing F10 activates the regular menubar.  Typing a letter then drops
down one of the menu-bar's menus whose name begins with that letter
(e.g. "F10 T" drops down the "Tools" menu), and you can use the arrow
keys and RET to traverse the menu hierarchy.

In that scenario, typing "F10 <down> <down> RET" will pop up the file
selection box, as if you clicked <menu-bar> <file> <open-file> with
the mouse, even though you never touched the mouse, while the docs
seems to imply that only mouse gestures cause file selector to be
popped.

Lennart, am I right in this interpretation of the situation you were
talking about when you started this thread?

(I don't know whether similar feature is available with other
toolkits, but I'd imagine it is.)

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Luc Teirlinck]

Eli Zaretskii wrote:

   (I don't know whether similar feature is available with other
   toolkits, but I'd imagine it is.)

With the Lucid toolkit, which is the default on GNU/Linux, if you do,
after `emacs -q -nbc' (but _without_ -nw), `C-h k F10' you see:

<f10> runs the command tmm-menubar

I do not know what the behavior is with GTK, LessTif, and Motif,
or on a Mac.

Sincerely,

Luc.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Lennart Borgman]

Eli Zaretskii wrote:
> In that scenario, typing "F10 <down> <down> RET" will pop up the file
> selection box, as if you clicked <menu-bar> <file> <open-file> with
> the mouse, even though you never touched the mouse, while the docs
> seems to imply that only mouse gestures cause file selector to be
> popped.
>
> Lennart, am I right in this interpretation of the situation you were
> talking about when you started this thread?
>   

Yes, you are right. (Though I myself instead use "ALT" to activate the 
menus.)

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Eli Zaretskii]

> Date: Tue, 16 May 2006 07:49:03 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Luc Teirlinck <teirllm@dms.auburn.edu>,  jasonr@gnu.org, 
>  emacs-devel@gnu.org
> 
> Though I myself instead use "ALT" to activate the menus.

This only works if you set w32-pass-alt-to-system to a non-default
value.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Lennart Borgman]

Luc Teirlinck wrote:
> Does the alternative you describe even happen for `emacs -nw', the
> _usual_ situation under which people invoke the menu bar from the
> keyboard?  That would surprise me very much.
>   
No, the w32 file dialog is not used in this case.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Luc Teirlinck]

Lennart Borgman wrote:

   Luc Teirlinck wrote:
   > Does the alternative you describe even happen for `emacs -nw', the
   > _usual_ situation under which people invoke the menu bar from the
   > keyboard?  That would surprise me very much.
   >   
   No, the w32 file dialog is not used in this case.

This is the situation in which most people invoke the menu bar from
the keyboard (because they have to, in this situation).  So, in the
main application of the keyboard menu bar feature, the file name is
read from the minibuffer.

   What is the intended behaviour? Luc expects that the dialog would not be 
   shown when F10 down RET is used. I am not sure

If somebody invokes the menu bar from the keyboard, with the regular
mouse based menu bar interface available, then it would seem to me
that this user clearly indicates that he does not want to have
anything to do with a mouse, through preference or necessity.  If he
dislikes "classical" menu bars, how likely is he to like File
Selection dialogs?

Sincerely,

Luc.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Lennart Borgman]

Luc Teirlinck wrote:
>    What is the intended behaviour? Luc expects that the dialog would not be 
>    shown when F10 down RET is used. I am not sure
>
> If somebody invokes the menu bar from the keyboard, with the regular
> mouse based menu bar interface available, then it would seem to me
> that this user clearly indicates that he does not want to have
> anything to do with a mouse, through preference or necessity.  If he
> dislikes "classical" menu bars, how likely is he to like File
> Selection dialogs?
>   

I am not sure what you mean here Luc. There are three different things here:

   - Using the mouse or the keyboard
   - What kind of menus
   - Using the file dialog box or not


In my own case I very seldom use the mouse, but I use the w32 menus. I 
am used to them since I in most programs on w32 have to use the menus.

On the other hand after using Emacs for a while I am expecting prompting 
through the mini-buffer. That gives me the advantage of the mini-buffer 
histories.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Luc Teirlinck]

Lennart Borgman wrote:

   > If somebody invokes the menu bar from the keyboard, with the regular
   > mouse based menu bar interface available, then it would seem to me
   > that this user clearly indicates that he does not want to have
   > anything to do with a mouse, through preference or necessity.  If he
   > dislikes "classical" menu bars, how likely is he to like File
   > Selection dialogs?
   >   

   I am not sure what you mean here Luc.

I was under the impression that using File Dialog boxes without the
mouse was inconvenient.  But I do not use File Dialog boxes often, so
maybe it is not that inconvenient once you are used to it.  In that
case, this particular argument would not make a lot of sense.

But there is another argument.

The rule that if you invoke something with the mouse, you get a file
dialog box and if you invoke something with the keyboard, you get to
use the minibuffer is easy to understand and remember and you can
override at least part of that using the options use-dialog-box and
use-file-dialog.  The alternative would be somewhat more complex to
document and remember.  If you invoke the menu from the keyboard, you
get the minibuffer in `emacs -nw' and a file dialog otherwise.

To me, this is no big deal however.

Sincerely,

Luc.

Re: commands invoked by the mouse -> commands invoked from the menu bar

[Richard Stallman]

    In "(emacs) Visiting" there is written

	commands invoked with the mouse (by clicking on the menu bar or tool
	bar) use the toolkit's standard File Selection dialog instead of
	prompting for the file name in the minibuffer.

    Should it not be like this instead:

	commands invoked from the menu bar (from the keyboard or with the
	mouse) use the toolkit's standard File Selections dialog ...

ISTR that this depends on whether you use the keyboard or the mouse.

What behavior do you observe, when you invoke a menu item with the
keyboard?