when to bind *down-mouse* vs *mouse*?

when to bind *down-mouse* vs *mouse*?

[Drew Adams]

I sent this to help-gnu-emacs a few days ago, but got no response. Can
anyone here help?

--

When is it recommended to bind *down-mouse* and when is it recommended to
bind just *mouse*? If the intention is to bind a mouse _click_ event (as
opposed to a drag), then which is generally the key sequence to bind?

I haven't been able to find any recommendations on this in the Info manuals.

If you grep the Emacs Lisp sources for "down-mouse" you will find zillions
of bindings. If you search for "down-mouse" in the Elisp Info doc you will
find that it seems to be used there too, if not explicitly recommended.
Similarly, however, if you grep or Info-search for "mouse-[123]" (and
flush/ignore hits for "down-mouse").

It would seem to make sense generally to bind *mouse* instead of
*down-mouse* for a mouse-click event, but perhaps there are considerations
having to do with multi-click or drag events that confuse the issue.

Now, this I think I can understand:

 - down-mouse-1 is bound to mouse-drag-region.
 - mouse-1 is bound to mouse-set-point.

If you press mouse-1 and don't follow it by a release in the same spot, you
get mouse-drag-region. (In fact, you get mouse-drag-region when you press,
and then mouse-drag-region reads another event and calls mouse-set-point.)

However, some of the standard bindings seem contradictory to me (but I'm no
doubt missing some fundamental logic behind mouse-button bindings):

 - S-down-mouse-1 is bound to mouse-set-font.
 - M-mouse-2 is bound to mouse-yank-secondary.

So, for instance:

- If you want to override `mouse-set-font' in, say, Dired mode, you would
presumably do something like this:

 (define-key dired-mode-map [S-down-mouse-1] 'my-S-m1-cmd)

- If you want to override `mouse-yank-secondary' in Dired mode, you would
presumably do something (different) like this:

 (define-key dired-mode-map [M-mouse-2] 'my-M-m2-cmd)

- If however, you did the following (for instance), then clicking
[M-mouse-2] in Dired could presumably (depending on when you released the
mouse button): 1) open the clicked file in another frame and then 2)
`mouse-yank-secondary' into that opened file - probably not what you want.

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

- Note that even this additional binding wouldn't help in that situation, if
you released the button after the clicked file was opened:

 (define-key dired-mode-map [M-mouse-2] 'ignore)

[This behavior is in fact what I see on Emacs 20. On Emacs 21, this problem
does not appear to arise (the `mouse-yank-secondary' does not take place) -
but I'm not sure why.]

Can someone clear this up for me? What is the recommendation? What is the
logic behind mouse bindings for click events? Are some of the standard
bindings inconsistent, or am I just missing something?

Thanks,

   Drew

Re: when to bind *down-mouse* vs *mouse*?

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> I sent this to help-gnu-emacs a few days ago, but got no response. Can
> anyone here help?

*Note Rebinding Mouse Buttons: (emacs)Mouse Buttons, for an explanation of
how the mouse events work.  Which event should be bound basically depends
on when the action is supposed to happen.

If you press a mouse button you get a down event.  If you release the
button you get a click event (no modifier).  If you move the mouse while
pressing a button you get a drag event.  Double and triple click events
are generated when you release and press a button (twice for triple click)
in less than double-click-time without moving the mouse.  Note that all
those events are actually generated, but some are discarded if unbound.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: when to bind *down-mouse* vs *mouse*?

[Drew Adams]

    *Note Rebinding Mouse Buttons: (emacs)Mouse Buttons, for an
    explanation of
    how the mouse events work.  Which event should be bound
    basically depends
    on when the action is supposed to happen.

    If you press a mouse button you get a down event.  If you release the
    button you get a click event (no modifier).  If you move the mouse while
    pressing a button you get a drag event.  Double and triple click events
    are generated when you release and press a button (twice for
    triple click)
    in less than double-click-time without moving the mouse.  Note that all
    those events are actually generated, but some are discarded if unbound.

Thanks, but that doesn't respond to my question, unfortunately. As I
mentioned, I already read the doc in the Emacs and Elisp manuals. I'm not
asking how mouse events work. I'm asking about recommended practice.

 - Drew

Re: when to bind *down-mouse* vs *mouse*?

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> Thanks, but that doesn't respond to my question, unfortunately. As I
> mentioned, I already read the doc in the Emacs and Elisp manuals. I'm not
> asking how mouse events work. I'm asking about recommended practice.

The essence of my answer was: Which event should be bound basically
depends on when the action is supposed to happen.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: when to bind *down-mouse* vs *mouse*?

[Drew Adams]

    > I'm not asking how mouse events work.
    > I'm asking about recommended practice.

    The essence of my answer was: Which event should be bound basically
    depends on when the action is supposed to happen.

Of course. My question was: when, besides when you want to work around a
bound drag (or other motion) event, would one bind *down-mouse* instead of
*mouse*?

That is the only case mentioned in the doc, for when you would want the
action to take place on button release instead of button press. But it
doesn't appear to be the only case where *down-mouse* is bound instead of
*mouse*.

To take the specific example I gave, why is `mouse-set-font' bound to
S-down-mouse-1 instead of being bound to S-mouse-1? I see no mouse motion
involved in that example. Luc has indicated a reason involving changing
mouse position (motion), but it's not yet clear to me.

- Drew

Re: when to bind *down-mouse* vs *mouse*?

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> To take the specific example I gave, why is `mouse-set-font' bound to
> S-down-mouse-1 instead of being bound to S-mouse-1?

You surely want the menu to pop up when you press the button, don't you?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: when to bind *down-mouse* vs *mouse*?

[Richard Stallman]

    To take the specific example I gave, why is `mouse-set-font' bound to
    S-down-mouse-1 instead of being bound to S-mouse-1?

Because it pops up a menu.  It is traditional for menus to appear
when you push the mouse button, so that you can select by releasing
the button.

Re: when to bind *down-mouse* vs *mouse*?

[Luc Teirlinck]

Drew Adams wrote:

   However, some of the standard bindings seem contradictory to me (but I'm no
   doubt missing some fundamental logic behind mouse-button bindings):

    - S-down-mouse-1 is bound to mouse-set-font.
    - M-mouse-2 is bound to mouse-yank-secondary.

and:

   Can someone clear this up for me? What is the recommendation? What is the
   logic behind mouse bindings for click events? Are some of the standard
   bindings inconsistent, or am I just missing something?

I do not see any inconsistency in the above.  S-down-mouse-1 brings up
the Font menu and where you release it (S-mouse-1) determines what
happens next.  I believe that it is in general preferable to bind
click events, rather than button-down events, unless you either want
to look for a drag type event or you want a two step process, like the
S-down-mouse-1 - S-mouse-1 sequence.

>From `(elisp)Button-Down Events':

     The usual reason to define a button-down event is so that you can
    track mouse motion (by reading motion events) until the button is
    released.

Sincerely,

Luc.

RE: when to bind *down-mouse* vs *mouse*?

[Drew Adams]

       However, some of the standard bindings seem contradictory
        - S-down-mouse-1 is bound to mouse-set-font.
        - M-mouse-2 is bound to mouse-yank-secondary.

       Can someone clear this up for me? What is the recommendation?
       What is the logic behind mouse bindings for click events?
       Are some of the standard bindings inconsistent, or am I just
       missing something?

    I do not see any inconsistency in the above.  S-down-mouse-1 brings up
    the Font menu and where you release it (S-mouse-1) determines what
    happens next.  I believe that it is in general preferable to bind
    click events, rather than button-down events, unless you either want
    to look for a drag type event or you want a two step process, like the
    S-down-mouse-1 - S-mouse-1 sequence.

Thanks for your reply, Luc. I'm getting a better idea of what I'm missing.

I'm still unclear about S-down-mouse-1, however. What do you mean by "where
you release it (S-mouse-1) determines what happens next"? Maybe I'm missing
something because I'm using Emacs on Windows?

On Windows, S-down-mouse-1 just brings up the standard Windows Font dialog
box, by default. Where you release the mouse button does not seem to have
any effect.

I also tried setting `w32-use-w32-font-dialog' to nil, to get the
non-Windows dialog "like X does" (to quote the doc string). I still do not
notice any change in behavior depending on where I release the mouse button,
however.

What difference in behavior do you notice, depending on where you release
the mouse button?

Thanks,

  Drew

Re: when to bind *down-mouse* vs *mouse*?

[Luc Teirlinck]

Drew Adams wrote:

   I'm still unclear about S-down-mouse-1, however. What do you mean by "where
   you release it (S-mouse-1) determines what happens next"? Maybe I'm missing
   something because I'm using Emacs on Windows?

On GNU/Linux with the default Lucid menu widgets, if you press
S-down-mouse-1, the Font menu comes up.  It has three submenus: Misc,
Courier and Fontset.  If you keep the mouse pressed down and move the
mouse over one of these, the summenu pops up.  Say we move it to
Fontset.  Then we see `default' and `standard 16-dot medium'.  If you
move the mouse to `standard 16-dot medium' and then release it, the
fontset changes to `standard 16-dot medium'.

Sincerely,

Luc.

Re: when to bind *down-mouse* vs *mouse*?

[Jason Rumney]

"Drew Adams" <drew.adams@oracle.com> writes:

> I'm still unclear about S-down-mouse-1, however. What do you mean by "where
> you release it (S-mouse-1) determines what happens next"? Maybe I'm missing
> something because I'm using Emacs on Windows?

Your assumption is correct. Windows does not allow for such efficient
use of the menus. It always requires you to click twice. Maybe we
could rewrite the basic mouse handling code of the menus instead of
letting the system handle it, but that would be quite a lot of work.

Re: when to bind *down-mouse* vs *mouse*?

[Alex Schroeder]

When the action creates a popup menu, I think we want to bind it to
the mouse-down event.  I seem to situations where the menu would
disappear as soon as you released the mouse.  If you released the
mouse on a menu item, that menu item has been "chosen" by the user.

Similary, when the action involves a position, we want to use
mouse-down.  One example is yanking with the mouse.  We want to yank
where the user clicked the mouse button (down), not where the user
released it.

Conversely, when the action is triggered by clicking into some
sensitive area (eg. buttons, links), then we should use mouse-up, so
that the user can change his mind after mouse-down and move away from
the button or link in order to cancel.

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: when to bind *down-mouse* vs *mouse*?

[Lennart Borgman]

----- Original Message ----- 
From: "Alex Schroeder" <alex@emacswiki.org>


> When the action creates a popup menu, I think we want to bind it to
> the mouse-down event.  I seem to situations where the menu would
> disappear as soon as you released the mouse.  If you released the
> mouse on a menu item, that menu item has been "chosen" by the user.

I do not agree on this. The reason we do not agree is perhaps that I am
using MS Windows and you are not (I do not know what you are using)? On MS
Windows I believe it is standard that CLICKING mouse 2 brings up a popup
menu (if there is any). You can then use the keyboard or the mouse to choose
from this menu.

My impression of this "standard" is that it is good because you do not have
to use the mouse very much, which can be difficult for some people and for
some other is an unnecessary burden and a hazard. I believe that this could
be a reason for the choice MS has made here.

- Lennart

Re: when to bind *down-mouse* vs *mouse*?

[Jan D.]

>
>> When the action creates a popup menu, I think we want to bind it to
>> the mouse-down event.  I seem to situations where the menu would
>> disappear as soon as you released the mouse.  If you released the
>> mouse on a menu item, that menu item has been "chosen" by the user.
>
> I do not agree on this. The reason we do not agree is perhaps that I am
> using MS Windows and you are not (I do not know what you are using)? 
> On MS
> Windows I believe it is standard that CLICKING mouse 2 brings up a 
> popup
> menu (if there is any). You can then use the keyboard or the mouse to 
> choose
> from this menu.
>
> My impression of this "standard" is that it is good because you do not 
> have
> to use the mouse very much, which can be difficult for some people and 
> for
> some other is an unnecessary burden and a hazard. I believe that this 
> could
> be a reason for the choice MS has made here.

FWIW, the standard behaviour for X toolkits is that if the mouse down, 
mouse up happens within a certain time, the menu stays up and you can 
navigate it with keys and/or mouse.  That way you get the best of both 
behaviours.

	Jan D.

Re: when to bind *down-mouse* vs *mouse*?

[Luc Teirlinck]

Lennart Borgman wrote:

   My impression of this "standard" is that it is good because you do not have
   to use the mouse very much, which can be difficult for some people and for
   some other is an unnecessary burden and a hazard. I believe that this could
   be a reason for the choice MS has made here.

As Jan already pointed out, the current behavior is standard on X and
has its advantages.  I believe it is important that users can do
everything in Emacs without the mouse, if that is what they either
choose or have to do.  The "MS standard" is not mouse-independent
either.  The Font Menu and much of Enriched mode rely on the <f10>
mouse-less menubar access to enable users to get by without the
mouse.  This is not ideal, but better than nothing.

In the case of access to the Font Menu, we have a bug however:

Do: 

emacs -q
<f10> o f

Result:

byte-code: Wrong type argument: listp, 102

102 is the character code for `f'.

The patch below fixes this.  Note that, in addition to fixing the bug,
it seems to point out a problem with the `x-popup-menu' docstring
which says:

  x-popup-menu is a built-in function in `C source code'.
  (x-popup-menu position menu)

  Pop up a deck-of-cards menu and return user's selection.
  position is a position specification.  This is either a mouse button event
  or a list ((XOFFSET YOFFSET) WINDOW)
  where XOFFSET and YOFFSET are positions in pixels from the top left
  corner of WINDOW's frame.  (WINDOW may be a frame object instead of a window.)
  This controls the position of the center of the first line
  in the first pane of the menu, not the top left of the menu as a whole.

But applying the patch below, which uses (0 0) for (XOFFSET YOFFSET)
seems to show that it controls the position of the top left of the
menu as a whole, no matter how clearly this is denied above.

I can install the patch if desired.

===File ~/mouse.el-diff=====================================
*** mouse.el	12 Nov 2004 19:47:19 -0600	1.257
--- mouse.el	04 Dec 2004 17:35:29 -0600	
***************
*** 2201,2207 ****
     (progn (unless (display-multi-font-p)
  	    (error "Cannot change fonts on this display"))
  	  (x-popup-menu
! 	   last-nonmenu-event
  	   ;; Append list of fontsets currently defined.
  	   (append x-fixed-font-alist (list (generate-fontset-menu))))))
    (if fonts
--- 2201,2209 ----
     (progn (unless (display-multi-font-p)
  	    (error "Cannot change fonts on this display"))
  	  (x-popup-menu
! 	   (if (listp last-nonmenu-event)
! 	       last-nonmenu-event
! 	     (list '(0 0) (selected-window)))
  	   ;; Append list of fontsets currently defined.
  	   (append x-fixed-font-alist (list (generate-fontset-menu))))))
    (if fonts
============================================================

Re: when to bind *down-mouse* vs *mouse*?

[Jan D.]

Luc Teirlinck wrote:

>The patch below fixes this.  Note that, in addition to fixing the bug,
>it seems to point out a problem with the `x-popup-menu' docstring
>which says:
>
>  x-popup-menu is a built-in function in `C source code'.
>  (x-popup-menu position menu)
>
>  Pop up a deck-of-cards menu and return user's selection.
>  position is a position specification.  This is either a mouse button event
>  or a list ((XOFFSET YOFFSET) WINDOW)
>  where XOFFSET and YOFFSET are positions in pixels from the top left
>  corner of WINDOW's frame.  (WINDOW may be a frame object instead of a window.)
>  This controls the position of the center of the first line
>  in the first pane of the menu, not the top left of the menu as a whole.
>
>But applying the patch below, which uses (0 0) for (XOFFSET YOFFSET)
>seems to show that it controls the position of the top left of the
>menu as a whole, no matter how clearly this is denied above.
>  
>

The documentation is correct for the old X menu (i.e. no 
Lesstif/Motif/Lucid/GTK) code.  But for other menus it is wrong.  I've 
changed the documentation and also changed the positioning for the old X 
menu to comply.

I've only changed for X.  As for W32, it pops up a bit to the left (half 
the menu width?) and on OSX it kind of pops up at the given coordinates, 
but not quite.  I suggest that someone who knows about those platforms 
in detail change the documentation to whatever is appropriate.  The 
current documentation is not right for those platforms.

>I can install the patch if desired.
>  
>

Looks fine to me.

    Jan D.

>===File ~/mouse.el-diff=====================================
>*** mouse.el	12 Nov 2004 19:47:19 -0600	1.257
>--- mouse.el	04 Dec 2004 17:35:29 -0600	
>***************
>*** 2201,2207 ****
>     (progn (unless (display-multi-font-p)
>  	    (error "Cannot change fonts on this display"))
>  	  (x-popup-menu
>! 	   last-nonmenu-event
>  	   ;; Append list of fontsets currently defined.
>  	   (append x-fixed-font-alist (list (generate-fontset-menu))))))
>    (if fonts
>--- 2201,2209 ----
>     (progn (unless (display-multi-font-p)
>  	    (error "Cannot change fonts on this display"))
>  	  (x-popup-menu
>! 	   (if (listp last-nonmenu-event)
>! 	       last-nonmenu-event
>! 	     (list '(0 0) (selected-window)))
>  	   ;; Append list of fontsets currently defined.
>  	   (append x-fixed-font-alist (list (generate-fontset-menu))))))
>    (if fonts
>  
>

RE: when to bind *down-mouse* vs *mouse*?

[Drew Adams]

    When the action creates a popup menu, I think we want to bind it to
    the mouse-down event.  I seem to situations where the menu would
    disappear as soon as you released the mouse.  If you released the
    mouse on a menu item, that menu item has been "chosen" by the user.

It's not clear to me what you're saying here. I think you're suggesting,
first, that binding to down-mouse lets the mouse-up event choose the menu
item, and if the menu were bound to just mouse (mouse-up), then you would
need to first click to bring up the menu, and then click again to choose the
menu item. Is that what you mean?

Are you also saying that there was (is?) a bug that caused the popup menu to
disappear on mouse-up? Was that with the menu bound to down-mouse or just
mouse (-up)?

When I look at other applications running on Windows - that's all I have
available right now -, they generally bring up a popup menu on mouse-up, not
on mouse-down. That includes most popup menus in Microsoft applications
(including Word, Outlook, Internet Explorer, Windows Explorer, Windows Media
Player, and Windows XP dialog boxes), but also WinZIP, Framemaker,
DreamWeaver, HomeSite, WS_FTP, SmartFTP, TextPad, TopStyle, and Irfanview.
(There are some exceptions, notably Netscape, Acrobat, and MS Excel.)

And these applications nevertheless let you keep the button pressed and
release it on a menu item to choose the item. And they let you,
alternatively, use separate clicks: one to bring up the menu, one to choose
each submenu (if any), and one to choose a menu item.

So, I would say that it is not clear that popup menus should be opened on
down-mouse - the reasons given so far aren't convincing. I'm not saying that
Emacs should necessarily behave like Windows apps; I'm just asking why it is
a good idea to bind popup menu opening to down-mouse, rather than mouse
(mouse-up).

The question of S-down-mouse-1 on Windows is a separate issue. On platforms
besides Windows, or if `w32-use-w32-font-dialog' is nil, a popup menu is
displayed. But on Windows with `w32-use-w32-font-dialog' non-nil (default
value), this just opens a dialog box. I see no reason to bind down-mouse
instead of mouse (-up), just to bring up a dialog box.

    Similary, when the action involves a position, we want to use
    mouse-down.  One example is yanking with the mouse.  We want to yank
    where the user clicked the mouse button (down), not where the user
    released it.

    Conversely, when the action is triggered by clicking into some
    sensitive area (eg. buttons, links), then we should use mouse-up, so
    that the user can change his mind after mouse-down and move away from
    the button or link in order to cancel.

These makes sense. Perhaps similar guidance should be in the Emacs (or
Elisp) manual - especially the second paragraph, which is less obvious than
the first. If so, the text should point out that the second criterion
overrides the first (a button or link also "involves a position").

Thanks,

  Drew

Re: when to bind *down-mouse* vs *mouse*?

[Stefan Monnier]

> available right now -, they generally bring up a popup menu on mouse-up, not
> on mouse-down.
[...]
> And these applications nevertheless let you keep the button pressed and
> release it on a menu item to choose the item. And they let you,

Hmm... think about how they reconcile those two conflicting descriptions of
the behavior and you'll see that they *do* pop up the menu *before* mouse-up
(at leas sometimes, it may be time-dependent on some toolkits).


        Stefan

Re: when to bind *down-mouse* vs *mouse*?

[Alex Schroeder]

"Drew Adams" <drew.adams@oracle.com> writes:

> And these applications nevertheless let you keep the button pressed and
> release it on a menu item to choose the item. And they let you,
> alternatively, use separate clicks: one to bring up the menu, one to choose
> each submenu (if any), and one to choose a menu item.
>
> So, I would say that it is not clear that popup menus should be opened on
> down-mouse - the reasons given so far aren't convincing. I'm not saying that
> Emacs should necessarily behave like Windows apps; I'm just asking why it is
> a good idea to bind popup menu opening to down-mouse, rather than mouse
> (mouse-up).

Assume an environment where you can press mouse-down, and a popup-menu
appears.  Keeping the mouse button pressed, move to the menu entry you
want to pick and release the mouse button.  This kind of behaviour is
possible for some systems (eg. xman for X11).  Binding a menu to
mouse-up would make this menu unusable on these systems.  The menu
won't appear unless you release the mouse, but it will disappear as
soon as you release the mouse...  That's why I think we want
mouse-down for popups.

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

RE: when to bind *down-mouse* vs *mouse*?

[Drew Adams]

    Assume an environment where you can press mouse-down, and a popup-menu
    appears.  Keeping the mouse button pressed, move to the menu entry you
    want to pick and release the mouse button.  This kind of behaviour is
    possible for some systems (eg. xman for X11).  Binding a menu to
    mouse-up would make this menu unusable on these systems.  The menu
    won't appear unless you release the mouse, but it will disappear as
    soon as you release the mouse...  That's why I think we want
    mouse-down for popups.

I guess you are saying that there are some platforms where popup menus must
be opened on down-mouse*; they don't play well with just mouse* (mouse-up).
If that is the case, then I suppose you are right that opening popup menus
should be bound to down-mouse* and not mouse* - in order to work on all
platforms.

Assuming this, we've identified these contexts so far for down-mouse* vs
mouse* binding recommendations for users:

 1. when clicking a sensitive area (button, link) to trigger an action -
bind mouse* (so the user can change his mind after mouse-down and move away
to cancel the action)

 2. when the position of the mouse action is important (and not case 1) -
bind down-mouse* (e.g. yank text where button is pressed)

 3. opening popup menus - bind down-mouse* (to work correctly on problem
platforms, as mentioned above)

Do others agree with these guidelines? Are there others?

I think that whatever guidelines we can agree on should find their way into
the Emacs doc, to promote consistency in Lisp libraries.

 - Drew

Re: when to bind *down-mouse* vs *mouse*?

[Stefan Monnier]

>  3. opening popup menus - bind down-mouse* (to work correctly on problem
> platforms, as mentioned above)

It's not "(to work correctly on problem platforms)".
It's because we actively want to support the possibility of doing

     press-button move-to-menu-entry release-button

in addition to

     click-button move-to-menu-entry click-button

AFAIK, allowing both behaviors is standard in 99% of the toolkits nowadays.


        Stefan

RE: when to bind *down-mouse* vs *mouse*?

[Drew Adams]

    >  3. opening popup menus - bind down-mouse* (to work correctly
    on problem
    > platforms, as mentioned above)

    It's not "(to work correctly on problem platforms)".
    It's because we actively want to support the possibility of doing

         press-button move-to-menu-entry release-button

    in addition to

         click-button move-to-menu-entry click-button

    AFAIK, allowing both behaviors is standard in 99% of the
    toolkits nowadays.

I take that as an endorsement of guideline #3, with an amendment to the
rationale.

What about other people? What about other guidelines? What about documenting
this for users?

  - Drew

Re: when to bind *down-mouse* vs *mouse*?

[Richard Stallman]

     1. when clicking a sensitive area (button, link) to trigger an action -
    bind mouse* (so the user can change his mind after mouse-down and move away
    to cancel the action)

     2. when the position of the mouse action is important (and not case 1) -
    bind down-mouse* (e.g. yank text where button is pressed)

This is not accurate.  Emacs does yanking on the up-event.
(I have no time to discuss whether this is right or wrong;
we're not changing it now.)

     3. opening popup menus - bind down-mouse* (to work correctly on problem
    platforms, as mentioned above)

I think this is the only occasion in which Emacs does something for a
down-event.