Re: Context menus and mouse-3

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: monnier@iro.umontreal.ca,  philipk@posteo.net,  rms@gnu.org,
>   spacibba@aol.com,  emacs-devel@gnu.org,  arthur.miller@live.com,
>   dgutov@yandex.ru,  ghe@sdf.org,  drew.adams@oracle.com
> Date: Wed, 14 Jul 2021 02:46:27 +0300
> 
> > 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.

Where in Emacs do we have context menus which include "Paste"?  I
thought we were talking about existing menus popped by mouse-2 that
you'd like to pop up with mouse-3.  If this isn't the case, then what
menus are we talking about here?  In particular, if you want to _add_
menus which currently don't exist in contexts where we currently don't
offer menus, that could be an entirely new minor mode, and then the
conflict with current bindings of mouse-3 could be resolved as part of
that mode.

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

I was thinking about something more flexible than an all-or-nothing
setting.  A delay is not really intelligent enough, since it again is
a global value.  I was thinking about something sensitive to the
context.

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

The default you suggest strikes me as inappropriate.  It is definitely
backward incompatible and confusing.

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

An opt-in behavior is by definition always backward-compatible.