emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Changing default mouse bindings


From: Drew Adams
Subject: RE: Changing default mouse bindings
Date: Fri, 17 Nov 2017 07:31:28 -0800 (PST)

> I don't think binding this to mouse-3 by default can fly,
> because it contradicts the usual GUI meaning of that
> button related to selections, something that is honored
> by all well-behaving GUI applications in the X world.
> It would be unwise for Emacs not to comply.

There is that.  And there is the fact that in Emacs
`mouse-3' does even more than usual with the selection
(region).

IMHO, the default Emacs behavior of `mouse-3' is a
good one, even if too few Emacs users know about it
and so make use of it.  I don't see why we would
change the default behavior (and I haven't seen any
good argument here for doing that).

On the other hand, letting users and libraries easily
configure non-default behavior is a good idea.

The _first question_, I think, is whether, in
providing an easy way to do that, Emacs should at
least encourage users and libraries to respect the
existing default behavior. IOW, make it easy to
show a `mouse-3' menu _without_ preventing the
normal, default use of `mouse-3' to cut and extend
the region.

That's the approach taken in `mouse3.el'.  I
did not want to interfere at all with the normal
behavior, and yet let users get any kind of menu
they want.

An approach to allowing customization that
starts with just binding `mouse-3' to a menu
does not accommodate the existing
cut/extend-region behavior - it effectively just
abandons that behavior.  It lets you choose,
only at configuration/customization time: menu
or cut/extend-region.  It doesn't let you choose
interactively.  It's not very Emacsy, in that
respect.

It has the "advantage", I suppose, of easily
letting you _replace_ that behavior with a menu.
It has the disadvantage of _only_ replacing it.

If a user or library wants both the cut/extent
behavior and a menu, au choix interactively,
then they will need to bypass the provided
customization mechanism and come up with
their own complex code that does the job.

It's easy enough to _add_ the possibility of
replacing cut/extend behavior to something like
what `mouse3.el' does (which is to preserve it).
IOW, you can always impose a simple menu-only
customization.

But just _replacing_ with a menu should not be
all we offer, in terms of letting you get a menu.

I think the answer to this first question should
be to allow customization but make it easiest to
get a menu without interfering with the default
cut/extend-region behavior.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]