Re: Context menus and mouse-3

[Juri Linkov <juri@linkov.net>]

> Can't we decide which effect is TRT based on where the user clicks?
> Context menus are available only in special places, and it would seem
> that setting the region in those places doesn't make sense, by and
> large.

Context menus are useful everywhere, not just in special places.
For example, selecting "Paste" from the context menu makes sense everywhere.

> And if sometimes we cannot dwim there, how about making the defcustom
> you introduced to allow the users to express their preferences in
> these problematic cases?

In the previous patch, the defcustom is named mouse-3-down-context-menu.
When it's customized to nil, then only the current behavior is available
with mouse-save-then-kill.  When customized to t, then the context menu
pops up immediately.

> If the above makes sense, I think it's a better solution than forcing
> this feature on everyone.  I would be surprised if holding the mouse
> button for several hundreds of milliseconds would suddenly produce an
> entirely different and unrelated effect, and I'd probably be annoyed
> by the need to hold the button when I _know_ I want the context menu.
> So it sounds like this implementation is sub-optimal from the get-go,
> and we should try looking for a better one.

We can add as many options as necessary to cater for all needs,
but the question is about the default behavior.  The proposed delay is
a middle ground before the user decides which behavior is more preferable.

> We could also consider an even more radical solution: an option to
> swap mouse-2 and mouse-3.  Because isn't it true that people who
> expect context menus to pop up when mouse-3 is pressed generally don't
> expect and don't use region-related mouse clicks at all?  (We have
> such a "swap-buttons" variable specific to MS-Windows, and I've been
> using it for eons, because clicking mouse-2 on a wheeled mouse is very
> inconvenient.)

This is not backward-compatibile change of the default behavior.