RE: [External] : Re: Context menus and mouse-3

[Drew Adams]

> Nowadays every other app...

Nowadays every other app is still not Emacs.
Emacs is not just an app like every other app.

> uses down-mouse-3 to pop up a context menu,
> but in Emacs mouse-3 operates on the region.

By default, yes, Emacs does.  And that's good.
Emacs selection-extension or deletion with a
right-click is a good feature.

> So the solution is...

No.  So there are many "solutions" possible.

But solutions to what?  The "problem" that Emacs
isn't like "every other app"?

No.  Solutions (ways) to provide users with a
right-click context menu.

And the best of those solutions give users:

1. A way to get either the longstanding Emacs
   default behavior or a context menu - au choix,
   when they right-click.  That means decide at
   the moment you click.

2. A way to choose only context menus, foregoing
   Emacs selection-extension/deletion behavior.

Library `mouse3.el' offers those user choices.

Wrt #1: By default you don't get a context menu
with a single right-click - you get the Emacs
selection-extension/deletion behavior.  A second
click gives you the menu.  So you can get either,
with the menu access costing you just a second
click at the same place.

Wrt #2: A user option lets you get the menu with
a single right-click.  In that case, you lose the
usual selection-extension/deletion behavior (but
Emacs gives you other ways to extend/delete a
selection).
___

There's no use of a delay (which is the bane of
Emacs CUA fiddling) - except this: whatever delay
you've already defined for your mouse as defining
a double-click.

* If within that delay then Emacs (as always)
  gives you a double-click behavior, which by
  default is the same as the longstanding Emacs
  behavior: kill/delete the (extended) selection,
  according to `mouse-drag-copy-region'.

* If more than the double-click delay then you
  get the menu.

(If you opt for a right-click to always give you
the menu immediately, then there's no second
click behavior and no double-click behavior.)

> similar to mouse-1-click-follows-link: to pop up a context menu
> after a delay, otherwise the immediate click operates on the region.

See above.  I think the mouse3.el approach is
saner and better fits both Emacs itself and
users used to, and still preferring, only a
context menu.

> Every mode can define own [context-menu] in their mode-maps,
> then users will be able to customize mode's [context-menu]
> using mode hooks.  Even text-properties could define
> the [context-menu] in their local bindings that will be used
> by '(current-local-map)' or better '(current-active-maps)'.

With mouse3.el there's no need for any of that -
no hooks, and no need for a special [context-menu]
pseudo-function key binding.  It's simple to
define context menus for modes (or for anything).

> To be able to override the [context-menu], local bindings could use
> text-property maps with another binding named [overriding-context-menu]
> that will replace the whole composite [context-menu], so e.g.
> flyspell-mode could put it on misspelled words, etc.

And no need for any of that - overriding with
text-property maps, additional pseudo-function
bindings, etc.  Instead, just bind variable
`mouse3-save-then-kill-command' to the behavior
you want - in any context or from any bit of code.
It can do anything you like, including provide
another menu (minor mode behavior or whatever).