Context menus and mouse-3 [was: Changes for emacs 28]

Context menus and mouse-3 [was: Changes for emacs 28]

[Drew Adams]

Ergus> The real problem is that now the right click
Ergus> is bind to mouse-save-then-kill which I have
Ergus> never ever used, but probably others have.

and earlier:

Ergus> Sadly we have <mouse-3> bind to mouse-save-then-kill
Ergus> which I don't find useful at all, but maybe
Ergus> somebody will complain if we change it to
Ergus> C-<mouse-3> and move the panel to <mouse-3>.

I suspect that people who use a mouse but feel
that `mouse-save-then-kill' isn't useful have
never really understood what it offers.

Part of the lack of understanding may come from
not having read the manual about it.  Node `Mouse
Commands' of the Emacs manual makes the behavior
clear, and thus how useful it can be.

`mouse-3' lets you select text, delete or kill
text, and extend or reduce the selection.
That's a lot, and the actions to do those things
fit well together.

The extend-or-reduce bit works in a special way
if you've selected text by multiple clicking:
double-clicking or triple-clicking `mouse-1'.
I invite you to read the full text, if you
haven't already.  And then play with it a bit.
___

What happens if you just read the doc string?
You don't get a great idea of the richness of
`mouse-3' behavior, IMO.  It's OK, as far as a
doc string goes.  But it's unlikely to teach
someone what they can do with it.

Here's a suggestion for that doc string, and
also for the doc strings for other `mouse-*'
bindings (keys and commands): Provide a link
to that `Mouse Commands' node in the manual.
___

To me, the behavior of `mouse-save-then-kill'
is super useful.  So much so that my library
`mouse3.el' has, as a big part of its design,
to keep that behavior, while supplementing it
with `mouse-3' context menus.

You can of course optionally just get the menus.
But that's not where it's at - not the default
behavior.  The idea is to let you use the normal
behavior as many times as you like - extend,
reduce, kill, whatever - and then, if you like,
click `mouse-3' at the same place again, to pop
up a context menu.

The first part is optional, and so is the menu
popping.  Click in the same spot for the menu.
Click anywhere else for the vanilla behavior.

The other big part of the design is context
menu definition and behavior.  Those two parts
are logically independent, but it makes sense
for them to be in the same library.

There are alternative ways to define the menus,
and alternative ways to present them.  Menus can
be mode-dependent or not, dynamic (programmed)
or static.

Menus can, and generally do, differ, depending
on whether or not the region is active.  When
active, a context menu provides actions on the
region or things in it.  When inactive, it
provides actions on thing(s) located where you
click.

(There are always multiple things located at the
spot where you click.  It's up to a particular
menu to decide which things to act on.)
___

Should a context menu include _only_ items that
pertain to the region or the location clicked?
In general, no.  But you can certainly have
menus that do provide only that, if you want.

Should a context menu include global menus as
submenus, i.e., major-mode menus or menu-bar
menus?  That's up to you - an option controls
this.  If non-nil then yes: if the menu-bar is
visible then include the major-mode menus; else
include the menu-bar menus.
___

There are two alternative ways to define the
menus: (1) use keymaps and extended menu items
or (2) use the `x-poup-menu' form.  The former
is the default method.  It gives you more
control: keywords such as :visible and :enable,
for instance.  The latter is a bit simpler for
defining, perhaps.

Simple example code of using each method is
provided in `mouse3.el', with explanation.
An example of method #1 is provided for use
with Dired mode.  An example of #2 is provided
for use with Picture mode.
___

`mouse3.el' is completely compatible with the
traditional Emacs `mouse-3' behavior.  The
only place where they overlap is if you click
`mouse-3' twice at the same spot.

If you do that to delete the selected text,
then to get that effect with `mouse3.el' you
double-click instead.  Vanilla Emacs doesn't
distinguish a double-click from two clicks
separated by more than the double-click time.

(You can swap those two behaviors: slow 2-click
to delete instead of to show menu.)

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Ergus]

Hi Drew:

I have been trying to find the usefulness for the command
'mouse-save-then-kill' and so far I understand what it does but I still
don't think it is more important/useful/intuitive than a good context
panel. When I said that I have never used it I mean because of a need
not because I don't know what it does.

Actually part of it's function (the kill) could be considered as a
problem more than a feature for less expert users or accidental double
right click (ex: looking for the panel).

Usually I prefer simpler solutions rather than complex and if I have to
do a proposal respecting to this, it will be:

1- Move mouse-save-then-kill to C-mouse-3

2- Move The panel in C-mouse-3 to mouse-3

3- Improve the panel just bit as has been mentioned before: promoting
copy, paste and cut to the main panel, adding spell and flymake
corrections (maybe group those) and so on... like in a normal editor.

Indeed the options I consider the most important/useful ones are already
there BUT only when the menu-bar is disabled (which gives me the only
good reason to disable it :p ).

I already tried your package and it still feels unnatural to me; but
also the hand installation is beyond the new users capabilities and
reserved only to part of the public.

That's my opinion and I think they are very sensible; but I don't want
to come into 1000 emails again arguing about this kind of details.

Best
Ergus

On Mon, Sep 14, 2020 at 03:06:43AM +0000, Drew Adams wrote:
>Ergus> The real problem is that now the right click
>Ergus> is bind to mouse-save-then-kill which I have
>Ergus> never ever used, but probably others have.
>
>and earlier:
>
>Ergus> Sadly we have <mouse-3> bind to mouse-save-then-kill
>Ergus> which I don't find useful at all, but maybe
>Ergus> somebody will complain if we change it to
>Ergus> C-<mouse-3> and move the panel to <mouse-3>.
>
>I suspect that people who use a mouse but feel
>that `mouse-save-then-kill' isn't useful have
>never really understood what it offers.
>
>Part of the lack of understanding may come from
>not having read the manual about it.  Node `Mouse
>Commands' of the Emacs manual makes the behavior
>clear, and thus how useful it can be.
>
>`mouse-3' lets you select text, delete or kill
>text, and extend or reduce the selection.
>That's a lot, and the actions to do those things
>fit well together.
>
>The extend-or-reduce bit works in a special way
>if you've selected text by multiple clicking:
>double-clicking or triple-clicking `mouse-1'.
>I invite you to read the full text, if you
>haven't already.  And then play with it a bit.
>___
>
>What happens if you just read the doc string?
>You don't get a great idea of the richness of
>`mouse-3' behavior, IMO.  It's OK, as far as a
>doc string goes.  But it's unlikely to teach
>someone what they can do with it.
>
>Here's a suggestion for that doc string, and
>also for the doc strings for other `mouse-*'
>bindings (keys and commands): Provide a link
>to that `Mouse Commands' node in the manual.
>___
>
>To me, the behavior of `mouse-save-then-kill'
>is super useful.  So much so that my library
>`mouse3.el' has, as a big part of its design,
>to keep that behavior, while supplementing it
>with `mouse-3' context menus.
>
>You can of course optionally just get the menus.
>But that's not where it's at - not the default
>behavior.  The idea is to let you use the normal
>behavior as many times as you like - extend,
>reduce, kill, whatever - and then, if you like,
>click `mouse-3' at the same place again, to pop
>up a context menu.
>
>The first part is optional, and so is the menu
>popping.  Click in the same spot for the menu.
>Click anywhere else for the vanilla behavior.
>
>The other big part of the design is context
>menu definition and behavior.  Those two parts
>are logically independent, but it makes sense
>for them to be in the same library.
>
>There are alternative ways to define the menus,
>and alternative ways to present them.  Menus can
>be mode-dependent or not, dynamic (programmed)
>or static.
>
>Menus can, and generally do, differ, depending
>on whether or not the region is active.  When
>active, a context menu provides actions on the
>region or things in it.  When inactive, it
>provides actions on thing(s) located where you
>click.
>
>(There are always multiple things located at the
>spot where you click.  It's up to a particular
>menu to decide which things to act on.)
>___
>
>Should a context menu include _only_ items that
>pertain to the region or the location clicked?
>In general, no.  But you can certainly have
>menus that do provide only that, if you want.
>
>Should a context menu include global menus as
>submenus, i.e., major-mode menus or menu-bar
>menus?  That's up to you - an option controls
>this.  If non-nil then yes: if the menu-bar is
>visible then include the major-mode menus; else
>include the menu-bar menus.
>___
>
>There are two alternative ways to define the
>menus: (1) use keymaps and extended menu items
>or (2) use the `x-poup-menu' form.  The former
>is the default method.  It gives you more
>control: keywords such as :visible and :enable,
>for instance.  The latter is a bit simpler for
>defining, perhaps.
>
>Simple example code of using each method is
>provided in `mouse3.el', with explanation.
>An example of method #1 is provided for use
>with Dired mode.  An example of #2 is provided
>for use with Picture mode.
>___
>
>`mouse3.el' is completely compatible with the
>traditional Emacs `mouse-3' behavior.  The
>only place where they overlap is if you click
>`mouse-3' twice at the same spot.
>
>If you do that to delete the selected text,
>then to get that effect with `mouse3.el' you
>double-click instead.  Vanilla Emacs doesn't
>distinguish a double-click from two clicks
>separated by more than the double-click time.
>
>(You can swap those two behaviors: slow 2-click
>to delete instead of to show menu.)
>

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Stefan Monnier]

> I have been trying to find the usefulness for the command
> 'mouse-save-then-kill' and so far I understand what it does but I still
> don't think it is more important/useful/intuitive than a good context
> panel.

We don't need to choose, since we can get a context menu on
`down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.


        Stefan

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Ergus]

On Mon, Sep 14, 2020 at 02:28:14AM -0400, Stefan Monnier wrote:
>> I have been trying to find the usefulness for the command
>> 'mouse-save-then-kill' and so far I understand what it does but I still
>> don't think it is more important/useful/intuitive than a good context
>> panel.
>
>We don't need to choose, since we can get a context menu on
>`down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.
>
>
>        Stefan
>
down-mouse-3 means that it will need to keep the button pressed to keep
the panel visible/accessible?

If so, then that's not what the user expects in general. I have not
strong feelings about this (actually no feelings at all).

My main concern is that having a "kill" on double right click the
behavior is very error prone when trying to access the panel and could
produce accidental and unexpected behaviors very frequently.

That's why I think that protecting from an accidental kill requiring a
control presses is better while we remove the need of having "another
panel more" and we bring a more familiar/natural behavior.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

On Mon, Sep 14, 2020 at 08:48:25AM +0200, Ergus wrote:
> On Mon, Sep 14, 2020 at 02:28:14AM -0400, Stefan Monnier wrote:
> >>I have been trying to find the usefulness for the command
> >>'mouse-save-then-kill' and so far I understand what it does but I still
> >>don't think it is more important/useful/intuitive than a good context
> >>panel.
> >
> >We don't need to choose, since we can get a context menu on
> >`down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.
> >
> >
> >       Stefan
> >
> down-mouse-3 means that it will need to keep the button pressed to keep
> the panel visible/accessible?

FWIW, it's what I'd expect. Click, slide up/down along the menu,
release.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

Le lun. 14 sept. 2020 à 09:49, <tomas@tuxteam.de> a écrit :

> On Mon, Sep 14, 2020 at 08:48:25AM +0200, Ergus wrote:
> > On Mon, Sep 14, 2020 at 02:28:14AM -0400, Stefan Monnier wrote:
> > >>I have been trying to find the usefulness for the command
> > >>'mouse-save-then-kill' and so far I understand what it does but I still
> > >>don't think it is more important/useful/intuitive than a good context
> > >>panel.
> > >
> > >We don't need to choose, since we can get a context menu on
> > >`down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.
> > >
> > >
> > >       Stefan
> > >
> > down-mouse-3 means that it will need to keep the button pressed to keep
> > the panel visible/accessible?
>
> FWIW, it's what I'd expect. Click, slide up/down along the menu,
> release.
>

I never realized that most applications also support this way of using the
context menu.

I find that hold-and-slide moves are annoying to do reliably with a laptop
touch-pad, though.

[-- Attachment #2: Type: text/html, Size: 1445 bytes --]

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Göktuğ Kayaalp]

On 2020-09-14 06:06 +03, Drew Adams <drew.adams@oracle.com> wrote:
> I suspect that people who use a mouse but feel
> that `mouse-save-then-kill' isn't useful have
> never really understood what it offers.

I’d say a major contributing factor is that with most touchpads this is
a very unergonomic binding.  Pressing and holding mouse-1 and making
precise selections is a PITA with these smushy plasticy cringy things
already.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Mon, Sep 14, 2020 at 09:58:12AM +0200, Thibaut Verron wrote:
> Le lun. 14 sept. 2020 à 09:49, <tomas@tuxteam.de> a écrit :

[...]

> > FWIW, it's what I'd expect. Click, slide up/down along the menu,
> > release.
> >
> 
> I never realized that most applications also support this way of using the
> context menu.

UI is like a labyrinth full of differently trained rats inside ;-)

> I find that hold-and-slide moves are annoying to do reliably with a laptop
> touch-pad, though.

I haven't a touchpad currently (wrong: there is one, but I vastly
prefer to use the trackpoint). Some years ago I /had/ to use a
touchpad (bigcorps: the bosses know what you need better than
yourself!), but somehow I managed: click+hold was (one quick tap+
release, tap+stay and then move). This was pretty reliable.

Of course those things are so extremely variable (all the possible
combos of personal motoric predispositions, touchpad hardware and
firm/software, etc.) that you can't make a general rule.

This is why I added another point of view.

People are extremely different [1]. Hardwares are, too, but
somewhat less. Same for firmwares. Same for softwares. The
latter two are extremely buggy, at that.

When asserting things about UI "this-and-this is better", take
into account that you are biased by your prior experience. Give
other people a way to opt out of your utopia, which might well
be their distopia :-)

Cheers

[1] Bigcorps, data harvesters and economists notwithstanding
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Mon, Sep 14, 2020 at 11:15:27AM +0300, Göktuğ Kayaalp wrote:
> On 2020-09-14 06:06 +03, Drew Adams <drew.adams@oracle.com> wrote:
> > I suspect that people who use a mouse but feel
> > that `mouse-save-then-kill' isn't useful have
> > never really understood what it offers.
> 
> I’d say a major contributing factor is that with most touchpads this is
> a very unergonomic binding.  Pressing and holding mouse-1 and making
> precise selections is a PITA with these smushy plasticy cringy things
> already.

See my other response: you can teach a touchpad (gee, alliteration)
to behave for those cases. By now, I just only buy (second hand!)
notebooks with a trackpad.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]

Le lun. 14 sept. 2020 à 10:29, <tomas@tuxteam.de> a écrit :

> On Mon, Sep 14, 2020 at 09:58:12AM +0200, Thibaut Verron wrote:
> > Le lun. 14 sept. 2020 à 09:49, <tomas@tuxteam.de> a écrit :
>
> [...]
>
> > > FWIW, it's what I'd expect. Click, slide up/down along the menu,
> > > release.
> > >
> >
> > I never realized that most applications also support this way of using
> the
> > context menu.
>
> UI is like a labyrinth full of differently trained rats inside ;-)
>

Agreed.

That might be why most GUI applications transparently support both ways of
operating the context menu. Given that their labyrinth/UI designers had
more time, means and motivation to investigate mouse behaviors than we do,
taking the same direction could be a good first step.


>
> > I find that hold-and-slide moves are annoying to do reliably with a
> laptop
> > touch-pad, though.
>
> I haven't a touchpad currently (wrong: there is one, but I vastly
> prefer to use the trackpoint). Some years ago I /had/ to use a
> touchpad (bigcorps: the bosses know what you need better than
> yourself!), but somehow I managed: click+hold was (one quick tap+
> release, tap+stay and then move). This was pretty reliable.
>

I might have had bad luck or small palms, but I could never get complex tap
combos to work reliably with palm detection.

At least I'm thankful that I never had to use one of those touchpads
without click buttons...


> Of course those things are so extremely variable (all the possible
> combos of personal motoric predispositions, touchpad hardware and
> firm/software, etc.) that you can't make a general rule.
>

Agreed. Again, I believe that it supports the idea of supporting both
usages.


> When asserting things about UI "this-and-this is better", take
> into account that you are biased by your prior experience. Give
> other people a way to opt out of your utopia, which might well
> be their distopia :-)
>

Is that meant for me personally? Sorry if I came across as assertive, it
was really the opposite of my intention.

I try to make it clear when my statements represent only my opinion and my
experience. Sorry if I failed to convey that meaning at times, I will try
harder.

Best,
Thibaut

[-- Attachment #2: Type: text/html, Size: 3315 bytes --]

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Göktuğ Kayaalp]

On 2020-09-14 12:03 +03, Thibaut Verron <thibaut.verron@gmail.com> wrote:
> That might be why most GUI applications transparently support both ways of
> operating the context menu. Given that their labyrinth/UI designers had
> more time, means and motivation to investigate mouse behaviors than we do,
> taking the same direction could be a good first step.

That happens at the toolkit level, i.e. with any modern toolkit you
wouldn’t need to go out of your way to support that kind of interaction.
Same goes with e.g. pressing a button but then moving your mouse outside
of it and release in order to cancel the button press.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

On Mon, Sep 14, 2020 at 11:03:19AM +0200, Thibaut Verron wrote:
> Le lun. 14 sept. 2020 à 10:29, <tomas@tuxteam.de> a écrit :

[...]

> > [click-and-drag]

[...]

> I might have had bad luck or small palms, but I could never get complex tap
> combos to work reliably with palm detection.

All was an one-finger operation. No palms involved (I know my limitations
when challenging the Gods ;-)

[...]

> Agreed. Again, I believe that it supports the idea of supporting both
> usages.

Yes. Not always easy, but...

> > When asserting things about UI "this-and-this is better", take
> > into account that you are biased by your prior experience. Give
> > other people a way to opt out of your utopia, which might well
> > be their distopia :-)
> >
> 
> Is that meant for me personally? Sorry if I came across as assertive, it
> was really the opposite of my intention.

Oh, sorry. No, this was a "generic you". And...

> I try to make it clear when my statements represent only my opinion and my
> experience. Sorry if I failed to convey that meaning at times, I will try
> harder.

...by the way, not criticising your tone or something. You come across
as an extremely polite person.

Rather trying to raise awareness that many of the patterns we take for
granted are just the result of some training, which might be totally
different for someone else.

Of course, one might argue that we all should be trained the same way
(it happens with other things too, like language (verbal and non-verbal),
so why not with computers?). Opinions on that might differ. For me this
is dystopia, especially in the current context, where roughly ten big
corps dominate that space.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Thibaut Verron]

Le lun. 14 sept. 2020 à 13:37, <tomas@tuxteam.de> a écrit :
>
> On Mon, Sep 14, 2020 at 11:03:19AM +0200, Thibaut Verron wrote:
> > Le lun. 14 sept. 2020 à 10:29, <tomas@tuxteam.de> a écrit :
>
> [...]
>
> > > [click-and-drag]
>
> [...]
>
> > I might have had bad luck or small palms, but I could never get complex tap
> > combos to work reliably with palm detection.
>
> All was an one-finger operation. No palms involved (I know my limitations
> when challenging the Gods ;-)

Yes, sorry, I was unclear. My trouble is usually to get the palm detection to
correctly detect my palm, and not incorrectly detect my finger(s) -- right-click
is usually emulated by a two-finger tap, to make things more difficult.


> Oh, sorry. No, this was a "generic you". And...

Okay, no problem, I just wanted to be sure. :)

> Rather trying to raise awareness that many of the patterns we take for
> granted are just the result of some training, which might be totally
> different for someone else.
>
> Of course, one might argue that we all should be trained the same way
> (it happens with other things too, like language (verbal and non-verbal),
> so why not with computers?). Opinions on that might differ. For me this
> is dystopia, especially in the current context, where roughly ten big
> corps dominate that space.

I agree.

There is probably a fair middle to strike there, and a lot has happened already
in that direction. I don't know if it is something which can (let
alone should) be
forced by us or the head-of-UI at big-tech, or rather something which happens
naturally -- very much like a language, as you point out.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Eli Zaretskii]

> Date: Mon, 14 Sep 2020 08:11:11 +0200
> From: Ergus <spacibba@aol.com>
> Cc: philipk@posteo.net, Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org,
>  Arthur Miller <arthur.miller@live.com>,
>  Dmitry Gutov <dgutov@yandex.ru>, Gregory Heytings <ghe@sdf.org>
> 
> Hi Drew:

I'm not Drew.  Still...

> I have been trying to find the usefulness for the command
> 'mouse-save-then-kill' and so far I understand what it does but I still
> don't think it is more important/useful/intuitive than a good context
> panel. When I said that I have never used it I mean because of a need
> not because I don't know what it does.
> 
> Actually part of it's function (the kill) could be considered as a
> problem more than a feature for less expert users or accidental double
> right click (ex: looking for the panel).
> 
> Usually I prefer simpler solutions rather than complex and if I have to
> do a proposal respecting to this, it will be:
> 
> 1- Move mouse-save-then-kill to C-mouse-3
> 
> 2- Move The panel in C-mouse-3 to mouse-3

AFAIK, what Emacs does with mouse-3 is similar to what other X-aware
applications do.  If we change that by default, it might cause
annoyance to those who use these X-related features.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Eli Zaretskii]

> Date: Mon, 14 Sep 2020 09:49:02 +0200
> From: <tomas@tuxteam.de>
> 
> > down-mouse-3 means that it will need to keep the button pressed to keep
> > the panel visible/accessible?
> 
> FWIW, it's what I'd expect. Click, slide up/down along the menu,
> release.

I wouldn't expect that, FWIW.  I'm used to context menus that stay
open after you release the right mouse button.

RE: Context menus and mouse-3 [was: Changes for emacs 28]

[Drew Adams]

> > down-mouse-3 means that it will need to keep the button pressed to keep
> > the panel visible/accessible?
> 
> FWIW, it's what I'd expect. Click, slide up/down along the menu,
> release.

("Click" generally (at least in Emacs) means press and
release, not press and hold pressed.  I'm guessing you
meant that you expect to press and hold while sliding
along the menu?)

RE: Context menus and mouse-3 [was: Changes for emacs 28]

[Drew Adams]

> > I suspect that people who use a mouse but feel
> > that `mouse-save-then-kill' isn't useful have
> > never really understood what it offers.
> 
> I’d say a major contributing factor is that with most touchpads this is
> a very unergonomic binding.  Pressing and holding mouse-1 and making
> precise selections is a PITA with these smushy plasticy cringy things
> already.

(I hate touch pads.)

But you don't have to press-and-hold `mouse-1' (or
touch-pad equivalent), and drag it to select text.

Seriously, read `Mouse Commands' if you haven't
already, and give it a try.

Double-click (`mouse-1') on a word, then click
`mouse-3' on another word. The selection picks up
whole words, from the first through the last you
clicked.

Triple-click a line, then click `mouse-3' on
another line.  The selection picks up whole lines.

[I'd like to see the double-clicking extended, so
that if you double-click a paren in Lisp it picks
up the full sexp, and if you then `mouse-3' another
sexp it picks up full sexps in the interval.  But
this is a bit trickier.]

RE: Context menus and mouse-3 [was: Changes for emacs 28]

[Drew Adams]

> Give other people a way to opt out of your utopia,
> which might well be their d[y]stopia :-)

+1.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Göktuğ Kayaalp]

On 2020-09-14 18:10 +03, Eli Zaretskii <eliz@gnu.org> wrote:
> AFAIK, what Emacs does with mouse-3 is similar to what other X-aware
> applications do.  If we change that by default, it might cause
> annoyance to those who use these X-related features.

[ I should’ve replied to your reply to my relevant email on another
  thread so that the flow of the treads aren’t broken, but I’ll be a bit
  lazy with this one.  Hope I don’t annoy anybody... ]

I never noticed that behaviour.  But while that’s a nice feature I doubt
it’s what people expect when they hear ‘context menu’.  It’s more like
the thing I gave a broken example of on the other thread.  I’d say it’s
less powerful than this C-mouse-3 context menu, but if we’re trying to
provide people with something they’d _expect_ to see when right
clicking, that’s not it.

FWIW my example was a combination of VS Code menu and Linux Mint’s
generic text editor Xed’s menu, plus a couple emacsy additions.



@Drew: Just checked out mouse3.el, read the comments.  Seems to be a
powerful extension, but IDK how fit it is for this particular task of
making some cosmetic adjustments to make some basic features have more
contemporary frontends (tho it’s quite probable that I’m missing
something here, because I barely if ever use any of the mouse, toolbar
or the menu bar).

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Mon, Sep 14, 2020 at 03:47:35PM +0000, Drew Adams wrote:
> > > down-mouse-3 means that it will need to keep the button pressed to keep
> > > the panel visible/accessible?
> > 
> > FWIW, it's what I'd expect. Click, slide up/down along the menu,
> > release.
> 
> ("Click" generally (at least in Emacs) means press and
> release, not press and hold pressed.  I'm guessing you
> meant that you expect to press and hold while sliding
> along the menu?)

Spot on. I was somewhat sloppy.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > We don't need to choose, since we can get a context menu on
  > `down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.

Have you tried doing that?  How does it work in practice?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Stefan Monnier]

Richard Stallman [2020-09-15 00:35:58] wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > We don't need to choose, since we can get a context menu on
>   > `down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.
>
> Have you tried doing that?  How does it work in practice?

Here's the code I'm using:

    (let ((default-context-menu
            `(menu-item ,(purecopy "Menu Bar") ignore
              :filter (lambda (_)
                        (if (zerop (or (frame-parameter nil 'menu-bar-lines) 0))
                            (mouse-menu-bar-map)
                          (mouse-menu-major-mode-map))))))
      (global-set-key [C-down-mouse-3] default-context-menu)
      (global-set-key [context-menu] default-context-menu))
    
    (global-set-key [down-mouse-3] #'mouse-maybe-context-menu)
    (defun mouse-maybe-context-menu (event)
      "Bring up a context menu for a long click.
    See `mouse-long-click-time' and `mouse-context-menu-function'."
      (interactive "@e")
      (if (let ((track-mouse t)) (sit-for (/ mouse-long-click-time 1000.0)))
          (push (cons 'context-menu (cdr event)) unread-command-events)))

It's not good enough for `master` (IIRC the sit-for tends to return nil
immediately in some circumstances), but I didn't pursue this any further
given the lack of interest at the time.  I can't think of any reason why
it should be hard to fix.


        Stefan

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Juri Linkov]

> Seriously, read `Mouse Commands' if you haven't
> already, and give it a try.

Mouse support is poor in Emacs, this is the reason
why I don't use the mouse in Emacs.  More below:

> Double-click (`mouse-1') on a word, then click
> `mouse-3' on another word. The selection picks up
> whole words, from the first through the last you
> clicked.

In other apps, the same is achieved by double-click
(`mouse-1') on a word, then double-click the same
(`mouse-1') on another word while holding down the Shift key.

> Triple-click a line, then click `mouse-3' on
> another line.  The selection picks up whole lines.

In other apps, triple-click a line, then again triple-click
on another line while holding down the Shift key.

But what if you need first to select a line, then extend
the selection to a word?  In other apps, triple-click a line,
then double-click `mouse-1' on a word while holding down the Shift key.
In Emacs, this is impossible.

Also in other apps Shift+F10 opens the context menu,
but why not in Emacs?

> [I'd like to see the double-clicking extended, so
> that if you double-click a paren in Lisp it picks
> up the full sexp, and if you then `mouse-3' another
> sexp it picks up full sexps in the interval.  But
> this is a bit trickier.]

It would be easier to use this as: double-click a paren to select
a sexp, then double-click another paren to select another sexp
while holding down the Shift key.

RE: Context menus and mouse-3 [was: Changes for emacs 28]

[Drew Adams]

> > read `Mouse Commands' if you haven't
> > already, and give it a try.
> 
> Mouse support is poor in Emacs, this is the reason
> why I don't use the mouse in Emacs.

I disagree that mouse support is poor in Emacs.

I use a mouse in several other applications much
of the workday, and Emacs mouse support is superior
in every respect I'm aware of.  But I'm no expert
on the use of mice.  And perhaps the mouse support
in the apps I use is not a reference.

> > Double-click (`mouse-1') on a word, then click
> > `mouse-3' on another word. The selection picks up
> > whole words, from the first through the last you
> > clicked.
> 
> In other apps, the same is achieved by double-click
> (`mouse-1') on a word, then double-click the same
> (`mouse-1') on another word while holding down the Shift key.

And that's better why?  Having to use both the
keyboard and the mouse?

(One of the arguments made by a few people in
this discussion was that `C-mouse-3' makes you
do that to get a right-click menu.)

> > Triple-click a line, then click `mouse-3' on
> > another line.  The selection picks up whole lines.
> 
> In other apps, triple-click a line, then again triple-click
> on another line while holding down the Shift key.

Both keyboard and mouse again.  Better?  Not IMO.
 
> But what if you need first to select a line, then extend
> the selection to a word?  In other apps, triple-click a line,
> then double-click `mouse-1' on a word while holding down the Shift key.
> In Emacs, this is impossible.

Granted.  But again, both keyboard and mouse.

We could provide a keyboard + mouse combination
for such use cases if that were a common need.

> Also in other apps Shift+F10 opens the context menu,
> but why not in Emacs?

That's orthogonal.  Nothing prevents also having
a keyboard key sequence to open a context menu.
(Presumably the "location" it refers to would
be point.)

The impetus for this discussion was expectations
of new users to get a context menu on `mouse-3'.
(But newbies are not the only reason for such a
feature.)

> > [I'd like to see the double-clicking extended, so
> > that if you double-click a paren in Lisp it picks
> > up the full sexp, and if you then `mouse-3' another
> > sexp it picks up full sexps in the interval.  But
> > this is a bit trickier.]
> 
> It would be easier to use this as: double-click a paren to select
> a sexp, then double-click another paren to select another sexp
> while holding down the Shift key.

Another keyboard + mouse mix.

[What I described already works for simple cases, BTW.
E.g. double-click a paren in Lisp (open or close),
then `mouse-3' another paren, to select up the lists
and intervening sexps.]

RE: Context menus and mouse-3 [was: Changes for emacs 28]

[Ergus via Emacs development discussions.]

On September 15, 2020 10:33:51 PM GMT+02:00, Drew Adams <drew.adams@oracle.com> wrote:
>> > read `Mouse Commands' if you haven't
>> > already, and give it a try.
>> 
>> Mouse support is poor in Emacs, this is the reason
>> why I don't use the mouse in Emacs.
>
>I disagree that mouse support is poor in Emacs.
>
So you are the only one I know so far with that opinion.

>I use a mouse in several other applications much
>of the workday, and Emacs mouse support is superior
>in every respect I'm aware of.  But I'm no expert
>on the use of mice.  And perhaps the mouse support
>in the apps I use is not a reference.
>
This is the same problem than undo-redo. Maybe the features are actually better technically speaking or to whom knows all the tricks and trains himself for years; but it worth nothing if the users feel uncomfortable or don't values some of the details that justify complexity in others. (Like hiding the context panel with a control or not having a redo button or not deleting the selection) Or just don't need them.

There are some "standards" in mouse interaction determined/imposed by most of the gui programing interfaces from visual studio or java to qt5 and gtk. The developers of all the aplications have been following them for years and most of the user are used to them.

So this is the "dilema". Or we change a bit (1 binding) to ease the user experience and learning curve OR we expect that all the potential users change their expectations, trainings and don't go to any other editor but use emacs because we pretend we offer a better functionality that they are not aware of and most probably don't need or never learn/use because is complex to remember.

>> > Double-click (`mouse-1') on a word, then click
>> > `mouse-3' on another word. The selection picks up
>> > whole words, from the first through the last you
>> > clicked.
>> 
>> In other apps, the same is achieved by double-click
>> (`mouse-1') on a word, then double-click the same
>> (`mouse-1') on another word while holding down the Shift key.
>
>And that's better why?  Having to use both the
>keyboard and the mouse?
>
Usually the other hand is already in the keyboard and close to a shift. Comparing, our approach of moving the mouse to the toolbar to copy after the selection is probably less efficient than anything else or the fact that M-w and C-y dont share any key like C-c/C-v or that we need the two hand to undo instead of C-z. All these are less efficient too but we are used to them.

So the argument of holding a shift seems a bit weak for any old emacs user right?

>(One of the arguments made by a few people in
>this discussion was that `C-mouse-3' makes you
>do that to get a right-click menu.)
>
No, the argument is also that many applications intercept that C-mouse action, in terminal doesn't work AND the user don't expect it to be there because probably we are one of the few (or the only) hiding the panel there after a control.


>> > Triple-click a line, then click `mouse-3' on
>> > another line.  The selection picks up whole lines.
>> 
>> In other apps, triple-click a line, then again triple-click
>> on another line while holding down the Shift key.
>
>Both keyboard and mouse again.  Better?  Not IMO.
> 
But just the same button-1 so yes, probably simpler to remember and intuitive for any office (or other modern editor) user.

>> But what if you need first to select a line, then extend
>> the selection to a word?  In other apps, triple-click a line,
>> then double-click `mouse-1' on a word while holding down the Shift
>key.
>> In Emacs, this is impossible.
>
>Granted.  But again, both keyboard and mouse.
>
And again, they are the same, mouse-1 and shift, so exactly the sames... This is a pattern. Select with mouse-1 actions in panel in mouse-3 move with the wheel.

Simple is better than complex.
Complex is better than complicated.

The emacs approach with mouse is indeed complicated.

>We could provide a keyboard + mouse combination
>for such use cases if that were a common need.
>
>> Also in other apps Shift+F10 opens the context menu,
>> but why not in Emacs?
>
>That's orthogonal.  Nothing prevents also having
>a keyboard key sequence to open a context menu.
>(Presumably the "location" it refers to would
>be point.)
>
There is the <print> key which many applications use to show the panel from keyboard too.

>The impetus for this discussion was expectations
>of new users to get a context menu on `mouse-3'.
>(But newbies are not the only reason for such a
>feature.)
>
>> > [I'd like to see the double-clicking extended, so
>> > that if you double-click a paren in Lisp it picks
>> > up the full sexp, and if you then `mouse-3' another
>> > sexp it picks up full sexps in the interval.  But
>> > this is a bit trickier.]
>> 
>> It would be easier to use this as: double-click a paren to select
>> a sexp, then double-click another paren to select another sexp
>> while holding down the Shift key.
>
>Another keyboard + mouse mix.
>
>[What I described already works for simple cases, BTW.
>E.g. double-click a paren in Lisp (open or close),
>then `mouse-3' another paren, to select up the lists
>and intervening sexps.]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Corwin Brust]

Hi.

On Tue, Sep 15, 2020 at 6:06 PM Ergus via Emacs development
discussions. <emacs-devel@gnu.org> wrote:
> On September 15, 2020 10:33:51 PM GMT+02:00, Drew Adams <drew.adams@oracle.com> wrote:
> >> > read `Mouse Commands' if you haven't
> >> > already, and give it a try.
> >>
> >> Mouse support is poor in Emacs, this is the reason
> >> why I don't use the mouse in Emacs.
> >
> >I disagree that mouse support is poor in Emacs.
> >
> So you are the only one I know so far with that opinion.
>
> >I use a mouse in several other applications much
> >of the workday, and Emacs mouse support is superior
> >in every respect I'm aware of.  But I'm no expert
> >on the use of mice.  And perhaps the mouse support
> >in the apps I use is not a reference.
> >
> This is the same problem than undo-redo. Maybe the features are actually better technically speaking or to whom knows all the tricks and trains himself for years; but it worth nothing if the users feel uncomfortable or don't values some of the details that justify complexity in others. (Like hiding the context panel with a control or not having a redo button or not deleting the selection) Or just don't need them.

Technically better is a pretty big deal.  Especially when the specific
technical advancement is massive-overkill levels of user-facing
configuration and even more when the subject at hand is how best to
get said technology to users.  (And, to wit, those users' needs are
varied so as to drive us to this type of sophistication/complexity.)

> There are some "standards" in mouse interaction determined/imposed by most of the gui programing interfaces from visual studio or java to qt5 and gtk. The developers of all the aplications have been following them for years and most of the user are used to them.

This isn't really different from veteran coders who have troubled to
become familiar with lots of Emacs bindings, or really any system
expert.  I acknowledge the utility of having Emacs' default bindings
be simple and obvious to new users.   I think that should be weighed
carefully when pitted directly thoughtful existing
practice/behaviours/defaults.  Echoing what Drew said, above: What we
already have may be superior to other more common practices.

> So this is the "dilema". Or we change a bit (1 binding) to ease the user experience and learning curve OR we expect that all the potential users change their expectations, trainings and don't go to any other editor but use emacs because we pretend we offer a better functionality that they are not aware of and most probably don't need or never learn/use because is complex to remember.

I think the "learning curve" is core to the value proposition of
Emacs:  if we invest the time, we are told, Emacs will overall reduce
the efforts associated to our labors.  There is a balance to be struck
here: new users need to under enough of the machine to begin
configuring it.  Meanwhile, complexities hidden for ease of newcomers
need to remain accessible to users who may be Emacs veterans but not
elisp coders.

Neither new nor old Emacs users will thank us for saving them a
learning curve that costs efficiencies in our work-flows and I think
most of us will learn (and relearn) as needed when the carrot is
general efficiencies when writing, etc.   I think it's the "trainings"
you mention that are the biggest opportunity.

> >> > Double-click (`mouse-1') on a word, then click
> >> > `mouse-3' on another word. The selection picks up
> >> > whole words, from the first through the last you
> >> > clicked.
> >>
> >> In other apps, the same is achieved by double-click
> >> (`mouse-1') on a word, then double-click the same
> >> (`mouse-1') on another word while holding down the Shift key.
> >
> >And that's better why?  Having to use both the
> >keyboard and the mouse?
> >
> Usually the other hand is already in the keyboard and close to a shift. Comparing, our approach of moving the mouse to the toolbar to copy after the selection is probably less efficient than anything else or the fact that M-w and C-y dont share any key like C-c/C-v or that we need the two hand to undo instead of C-z. All these are less efficient too but we are used to them.

I've been thinking about this.  Those who play lots of computer games
may know of an alternate position for the left hand   (Ring finger
slides left onto "A", pinky slides down over the "modern" location of
Control, etc.)  For those who know this position, our left-hands are
pretty comfortable sliding around while we're mousing.  It's almost
another sort of touch-typing - I can stretch over and without looking
hit the Eight key on the number-row with my left index finger pretty
consistently.    In any case, my point is that the diversity of
use-cases continues to multiply however the value proposition Emacs is
only strengthened:  An editor I can configure, based on my own ever
more unique behaviors, to access functionality representing decades of
programers' workflows.

> >> > Triple-click a line, then click `mouse-3' on
> >> > another line.  The selection picks up whole lines.
> >>
> >> In other apps, triple-click a line, then again triple-click
> >> on another line while holding down the Shift key.
> >
> >Both keyboard and mouse again.  Better?  Not IMO.
> >
> But just the same button-1 so yes, probably simpler to remember and intuitive for any office (or other modern editor) user.

> Simple is better than complex.
> Complex is better than complicated.

I think I don't understand: I would say a simple solution I can
remember beats a better solution I've forgotten because it is too
unfamiliar or complex.  But only until I understand how to get "on the
fly help".  The better solution is better for me given only that I
understand and actually do use it.

> The emacs approach with mouse is indeed complicated.

Then it needs better training!  A seperate tutorial?  RMS mentioned a
key-binding memorization game awhile back- maybe a "mouse-trainer"
something like?

In any case, thank you (all) for the work you are doing to help make
Emacs more accessible to new users.  I turn a lot of people on to
Emacs and I'm looking forward to the help I expect this will be for
them.

> >We could provide a keyboard + mouse combination
> >for such use cases if that were a common need.
> >
> >> Also in other apps Shift+F10 opens the context menu,
> >> but why not in Emacs?
> >
> >That's orthogonal.  Nothing prevents also having
> >a keyboard key sequence to open a context menu.
> >(Presumably the "location" it refers to would
> >be point.)
> >
> There is the <print> key which many applications use to show the panel from keyboard too.

There is also <apps> (right of the "right-Flag" key, for me).   In OS
context this opens a context window considering the active selection
if any.

According to ~~C-h k~~ it is unbound:

 | user-error: No command is bound to <apps>

I think people come to Emacs expecting (bracing themselves) to learn.
 We need to do a better job of capitalizing on that by welcoming
people with accessible bite-sized introductory material at least as
much as we need to make the "factory defaults" for Emacs sufficient
for people to make it though such materials.  (I'm referencing
on-going topics such as the first-run configuration wizard,
minor-mode/theme, etc. discussed on other threads.  Apart from the
"mouse trainer" I not sure what else to suggest, specifically.)

> >The impetus for this discussion was expectations
> >of new users to get a context menu on `mouse-3'.
> >(But newbies are not the only reason for such a
> >feature.)
> >
> >> > [I'd like to see the double-clicking extended, so
> >> > that if you double-click a paren in Lisp it picks
> >> > up the full sexp, and if you then `mouse-3' another
> >> > sexp it picks up full sexps in the interval.  But
> >> > this is a bit trickier.]
> >>
> >> It would be easier to use this as: double-click a paren to select
> >> a sexp, then double-click another paren to select another sexp
> >> while holding down the Shift key.
> >
> >Another keyboard + mouse mix.
> >
> >[What I described already works for simple cases, BTW.
> >E.g. double-click a paren in Lisp (open or close),
> >then `mouse-3' another paren, to select up the lists
> >and intervening sexps.]

The first message in this thread (Mouse Commands, plugging the manual,
etc.) has meaningfully changed my workflow.  In fact, I was playing
with the feature described above last night.   Double click the
closing paren of a defun.  Now Mouse-3 after the following defun.
Finally, mouse-3 a second time in the same place (that is, right after
the second defun).

*Yoink*

This seems great for refactoring, ie. making little ones out of big
ones.  Took me very little getting used to.

> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

PS, can we rename "yank" to "yoink"?  No?  Okay.

Regards,
Corwin

RE: Context menus and mouse-3 [was: Changes for emacs 28]

[Drew Adams]

You're all over the map, Ergus, arguing abstractly, not
to the point - bringing in undo-redo; newbie-vs-better
behavior; hiding the context menu behind C-mouse-3,
which also doesn't work in a terminal (mouse3.el uses
mouse-3); "moving the mouse to the toolbar to copy after
the selection" (huh? what's that about?); "M-w and C-y
dont share any key like C-c/C-v"; "we need the two hand
to undo instead of C-z" (two hands to undo?);...

Again:

>> The impetus for this discussion was expectations
>> of new users to get a context menu on `mouse-3'.
>> (But newbies are not the only reason for such a
>> feature.)

A context menu is useful for discoverability, including
by seasoned Emacs users (we are all discovering some
parts of Emacs).  It should be easily configurable by
program and by users, adaptable for any mode or other
context.  `mouse-3' is a good place for it, and not
only because that's where newbies expect it.

Emacs mouse selection, including extension & deletion,
are also useful.  Both this and a `mouse-3' menu are
possible, with no sacrifice.

RE: Context menus and mouse-3 [was: Changes for emacs 28]

[Drew Adams]

> The first message in this thread (Mouse Commands, plugging the manual,
> etc.) has meaningfully changed my workflow.  In fact, I was playing
> with the feature described above last night.   Double click the
> closing paren of a defun.  Now Mouse-3 after the following defun.
> Finally, mouse-3 a second time in the same place (that is, right after
> the second defun).
> 
> *Yoink*

<selection is killed>

And with mouse3.el, by default you'd double-click there,
instead of a slower-than-double-click second click there.

Or the reverse (not the default), if that's what you prefer.

Either way, the other (slow-2nd by default, or double by
option) shows you a context menu.  (And the menu includes
`Kill' and `Delete', if your double-vs-second fu misses.)

> This seems great for refactoring, ie. making little ones out of big
> ones.  Took me very little getting used to.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 15 Sep 2020 22:17:24 +0300
> Cc: philipk@posteo.net, Richard Stallman <rms@gnu.org>,
>  Ergus <spacibba@aol.com>, emacs-devel@gnu.org, Gregory Heytings <ghe@sdf.org>,
>  Arthur Miller <arthur.miller@live.com>, Dmitry Gutov <dgutov@yandex.ru>,
>  Göktuğ Kayaalp <self@gkayaalp.com>
> 
> Mouse support is poor in Emacs, this is the reason
> why I don't use the mouse in Emacs.  More below:

"Poor"? the below just says that other applications (which ones?) do
it slightly differently, that's all.  I don't see how what you say
justifies the "poor" part.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Ergus]

On Wed, Sep 16, 2020 at 01:25:35AM +0000, Drew Adams wrote:
>You're all over the map, Ergus, arguing abstractly, not
>to the point - bringing in undo-redo;

This was just an examples of discussions that have been for years in
this mailing list and changes that the legacy users have opposed and
vetoed with the argument of the "Emacs way is better" (like
delete-selection-mode, transient-mark-mode and so on).

>newbie-vs-better
>behavior; hiding the context menu behind C-mouse-3,
>which also doesn't work in a terminal 

This is so far the point of the discussion.

>(mouse3.el uses mouse-3);

It is not there and not easy to install for newcomers, normal users, or
toggle enabled when we open with emacs -Q, or working in another
machine.

Emacs is supposed to be an editor, not a box from IKEA to assemble your
own one by hand because people go to IKEA because they consider is
cheaper not because they think it is better. If other companies offer
the same furniture than IKEA, assembled and bring them to home at the
same price then IKEA will probably close in a couple of years.

>"moving the mouse to the toolbar to copy after
>the selection" (huh? what's that about?);

That's the only alternative we give to the mouse users for coping/paste:
select with the mouse mixing clicks go to the [tool,menu]bar and click
copy then go to the place, click, toolbar->paste instead of
select, right-click->copy, go, right-click->paste.

>"M-w and C-y
>dont share any key like C-c/C-v"; "we need the two hand
>to undo instead of C-z" ;...
>
Your previous argument was that pressing \click and shift+click\ for
selecting was worst than \3 clicks + right mouse click\. So I just showed
that there are worst inconsistencies/in-ergonomic/complicated bindings
for other common and frequent actions and nobody (including me) cares.

Here is another: do you think that killing is more frequent (to have it
ready in double right click) than copy?


>(two hands to undo?)

Yes: C-/ and M-_ requires two hands while C-x u is a bit long to repeat.

>Again:
>
>>> The impetus for this discussion was expectations
>>> of new users to get a context menu on `mouse-3'.
>>> (But newbies are not the only reason for such a
>>> feature.)
>
>A context menu is useful for discoverability, including
>by seasoned Emacs users (we are all discovering some
>parts of Emacs).  It should be easily configurable by
>program and by users, adaptable for any mode or other
>context.  `mouse-3' is a good place for it, and not
>only because that's where newbies expect it.
>
Agree

>Emacs mouse selection, including extension & deletion,
>are also useful.  Both this and a `mouse-3' menu are
>possible, with no sacrifice.

Not sure there is a consistent way for this.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Eli Zaretskii]

> Date: Wed, 16 Sep 2020 00:47:38 +0200
> CC: philipk@posteo.net, Richard Stallman <rms@gnu.org>,
>  Göktuğ Kayaalp <self@gkayaalp.com>,
>  Arthur Miller <arthur.miller@live.com>, Dmitry Gutov <dgutov@yandex.ru>,
>  Gregory Heytings <ghe@sdf.org>
> From: Ergus via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> On September 15, 2020 10:33:51 PM GMT+02:00, Drew Adams <drew.adams@oracle.com> wrote:
> >> > read `Mouse Commands' if you haven't
> >> > already, and give it a try.
> >> 
> >> Mouse support is poor in Emacs, this is the reason
> >> why I don't use the mouse in Emacs.
> >
> >I disagree that mouse support is poor in Emacs.
> >
> So you are the only one I know so far with that opinion.

He's not the only one.

> This is the same problem than undo-redo. Maybe the features are actually better technically speaking or to whom knows all the tricks and trains himself for years; but it worth nothing if the users feel uncomfortable or don't values some of the details that justify complexity in others. (Like hiding the context panel with a control or not having a redo button or not deleting the selection) Or just don't need them.
> 
> There are some "standards" in mouse interaction determined/imposed by most of the gui programing interfaces from visual studio or java to qt5 and gtk. The developers of all the aplications have been following them for years and most of the user are used to them.

Emacs didn't invent the effect of the mouse gestures we have now, they
closely follow what X applications do, or at least did at the time.
Perhaps nowadays those applications and users who are used to those
effects are a minority (what with all the "modern" desktops so busy
copycat'ing MS-Windows' look and feel), but we still have many users
who have these gestures burnt into their muscle memories.  Wed cannot
just abandon them, even if they are a minority (which is not at all
certain).

What we _can_ do is to have 2 modes of operation, one each for every
one of these two groups of users.  This is easy to do technically, all
we need is "just" to have someone who'd sit down and design the
"other" mode of mouse gestures in some reasonable and logical way.

> So this is the "dilema". Or we change a bit (1 binding) to ease the user experience and learning curve OR we expect that all the potential users change their expectations, trainings and don't go to any other editor but use emacs because we pretend we offer a better functionality that they are not aware of and most probably don't need or never learn/use because is complex to remember.

There's no dilemma, we can have both modes.

> Simple is better than complex.
> Complex is better than complicated.

And the one you are used to is the best of them all.

> The emacs approach with mouse is indeed complicated.

I disagree that it's complicated.  But we don't have to agree, see
above.

RE: Context menus and mouse-3 [was: Changes for emacs 28]

[Drew Adams]

> > (mouse3.el uses mouse-3);
> 
> It is not there and not easy to install for newcomers, normal users, or
> toggle enabled when we open with emacs -Q, or working in another
> machine.

I propose that it be added to Emacs, that the
behavior it offers be included, and even made
the default behavior.  It doesn't conflict with
the current behavior - it supplements it.

Which context menus are provided out of the box
can be discussed.  `mouse3.el' gives users and
libraries easy ways to get the menus they want,
but what menus Emacs should provide by default
is an open question.

> Emacs is supposed to be an editor, not a box from IKEA to assemble your
> own one by hand because people go to IKEA because they consider is
> cheaper not because they think it is better. If other companies offer
> the same furniture than IKEA, assembled and bring them to home at the
> same price then IKEA will probably close in a couple of years.

Emacs is very much a toolkit, and much more.
Emacs Lisp is its core (and some say its
raison d'etre).

Emacs is NOT just an out-of-the-box experience.
It does provide an out-of-the-box experience.
No one _need_ customize it.  But many (most?)
people do.  Openness to customization is a core
feature of Emacs.

You've missed the boat, if you don't think Emacs
is _at least_ a toolkit.

> >"moving the mouse to the toolbar to copy after
> >the selection" (huh? what's that about?);
> 
> That's the only alternative we give to the mouse users for coping/paste:
> select with the mouse mixing clicks go to the [tool,menu]bar and click
> copy then go to the place, click, toolbar->paste instead of
> select, right-click->copy, go, right-click->paste.

No.  `mouse3.el' (this thread is about context
menus and `mouse-3') offers all of that with a
right-click.

> Here is another: do you think that killing is more frequent (to have it
> ready in double right click) than copy?

`mouse-drag-copy-region'

(IMO, the default value should be t, not nil.)

> >Emacs mouse selection, including extension & deletion,
> >are also useful.  Both this and a `mouse-3' menu are
> >possible, with no sacrifice.
> 
> Not sure there is a consistent way for this.

`mouse3.el' offers exactly that.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Juri Linkov]

>> Mouse support is poor in Emacs, this is the reason
>> why I don't use the mouse in Emacs.  More below:
>
> "Poor"? the below just says that other applications (which ones?) do
> it slightly differently, that's all.  I don't see how what you say
> justifies the "poor" part.

Yes, this is subjective, but while I use the mouse in other apps,
every time I try to use the mouse in Emacs, I can't make any sense of
default mouse bindings mess, so have to resort to the keyboard (where
Emacs keybindings are far superior to other apps).

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Juri Linkov]

>> In other apps, the same is achieved by double-click
>> (`mouse-1') on a word, then double-click the same
>> (`mouse-1') on another word while holding down the Shift key.
>
> And that's better why?  Having to use both the
> keyboard and the mouse?

So what?  There are many mouse commands in Emacs
that require pressing a modifier key.

>> But what if you need first to select a line, then extend
>> the selection to a word?  In other apps, triple-click a line,
>> then double-click `mouse-1' on a word while holding down the Shift key.
>> In Emacs, this is impossible.
>
> Granted.  But again, both keyboard and mouse.
>
> We could provide a keyboard + mouse combination
> for such use cases if that were a common need.

Isn't this already a common need?  For example,
when a user selects a word by double-clicking it,
and then needs to extend the selection to the middle
of another word.  Currently impossible in Emacs with mouse-3.

>> Also in other apps Shift+F10 opens the context menu,
>> but why not in Emacs?
>
> That's orthogonal.  Nothing prevents also having
> a keyboard key sequence to open a context menu.
> (Presumably the "location" it refers to would
> be point.)

This is still related: since there is no context menu on mouse-3,
there is a need for a keyboard equivalent compatible with other apps.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Dmitry Gutov]

On 16.09.2020 22:35, Juri Linkov wrote:
>>> Mouse support is poor in Emacs, this is the reason
>>> why I don't use the mouse in Emacs.  More below:
>> "Poor"? the below just says that other applications (which ones?) do
>> it slightly differently, that's all.  I don't see how what you say
>> justifies the "poor" part.
> Yes, this is subjective, but while I use the mouse in other apps,
> every time I try to use the mouse in Emacs, I can't make any sense of
> default mouse bindings mess, so have to resort to the keyboard (where
> Emacs keybindings are far superior to other apps).

Likewise.

I wonder how much of the "we only use keyboard" echos comes from the 
mouse bindings not being useful.

Like, if you want the context menu, you have to press Ctrl on the 
keyboard anyway. Might as well invoke the command from the keyboard 
entirely.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > You're all over the map, Ergus, arguing abstractly, not
  > to the point

The second part of that sentences criticizes his arguments.  That's a
reasonable way to criticize.  But the first part is unkind, because it
criticizes Ergus rather than his arguments.
-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This was just an examples of discussions that have been for years in
  > this mailing list and changes that the legacy users have opposed and
  > vetoed

Please do not call us "legacy users".  That is a harsh thing to say of
anyone.  It implies that Emacs inherited us and is stuck with us.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > "Poor"? the below just says that other applications (which ones?) do
  > > it slightly differently, that's all.  I don't see how what you say
  > > justifies the "poor" part.

  > Yes, this is subjective,

The worst problem is, it is not concrete enough to be constructive.
If someone says your program is "poor", what could you usefully do?

Please be more specific when you criticize.

  >  but while I use the mouse in other apps,
  > every time I try to use the mouse in Emacs, I can't make any sense of
  > default mouse bindings mess,

Which bindings do you find confusing?

If you say that, we might get an idea for an improvement.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Juri Linkov]

>   > > "Poor"? the below just says that other applications (which ones?) do
>   > > it slightly differently, that's all.  I don't see how what you say
>   > > justifies the "poor" part.
>
>   > Yes, this is subjective,
>
> The worst problem is, it is not concrete enough to be constructive.
> If someone says your program is "poor", what could you usefully do?
>
> Please be more specific when you criticize.

Constructively, I propose to include in Emacs a new mode
(with a name like 'modern-mouse-mode') where

- down-mouse-3 and mouse-3 pop up the context menu
  containing at least the items "Cut", "Copy", "Paste", "Undo", "Redo"
  (and only "Copy" when the buffer is in read-only mode);
- holding down the Shift key while using mouse-1 adjusts
  the already active region;
- dragging the active region moves it to the place
  where the mouse-1 was released;
- dragging the active region copies it to another place
  while holding down the Control key;
- holding down the Shift key while scrolling with mouse wheel
  scrolls the buffer horizontally;

>   >  but while I use the mouse in other apps,
>   > every time I try to use the mouse in Emacs, I can't make any sense of
>   > default mouse bindings mess,
>
> Which bindings do you find confusing?

This is just incompatibility between the currently active old mode
that follows what X applications do, and more modern mouse bindings
used nowadays in other applications.  So two separate modes are needed.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Ergus]

On Wed, Sep 16, 2020 at 11:57:37PM -0400, Richard Stallman wrote:
>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>[[[ whether defending the US Constitution against all enemies,     ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>  > This was just an examples of discussions that have been for years in
>  > this mailing list and changes that the legacy users have opposed and
>  > vetoed
>
>Please do not call us "legacy users".  That is a harsh thing to say of
>anyone.  It implies that Emacs inherited us and is stuck with us.
>
Sorry. That was the expression I found to describe users used to emacs
as is (including me) but that oppose to many changes (so not like me).

I usually describe features and changes I see in other editors that
indeed are not beneficial for me at all because I already spent a lot of
time learning the "emacs way". So in that sense I am also a legacy
user. Most of the changes I propose are indeed very simple; just details
and bindings that for external users are important and need constantly
and are included in emacs since many years.

But after all I understood that it is very hard to convince anyone
(students, colleges, projects managers) to invest so much time and
reading to learn how to do something simple they already know how to do
everywhere else. We can't even sale the idea that it is faster,
available everywhere, or more ergonomic like vim does.

Changing some of these will probably force me to re-learn many things;
but I am fine with that if that implies that the editor becomes more
attractive for more users. Otherwise we are just dying slowly with every
time less and less people in a world with exponentially more and more
programmers (with need to use an editor; the knowledge to become
maintainers and fresh ideas).

>-- 
>Dr Richard Stallman
>Chief GNUisance of the GNU Project (https://gnu.org)
>Founder, Free Software Foundation (https://fsf.org)
>Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Ergus]

On Thu, Sep 17, 2020 at 10:48:11AM +0300, Juri Linkov wrote:
>>   > > "Poor"? the below just says that other applications (which ones?) do
>>   > > it slightly differently, that's all.  I don't see how what you say
>>   > > justifies the "poor" part.
>>
>>   > Yes, this is subjective,
>>
>> The worst problem is, it is not concrete enough to be constructive.
>> If someone says your program is "poor", what could you usefully do?
>>
>> Please be more specific when you criticize.
>
>Constructively, I propose to include in Emacs a new mode
>(with a name like 'modern-mouse-mode') where
>
>- down-mouse-3 and mouse-3 pop up the context menu
>  containing at least the items "Cut", "Copy", "Paste", "Undo", "Redo"
>  (and only "Copy" when the buffer is in read-only mode);
>- holding down the Shift key while using mouse-1 adjusts
>  the already active region;
>- dragging the active region moves it to the place
>  where the mouse-1 was released;
>- dragging the active region copies it to another place
>  while holding down the Control key;
>- holding down the Shift key while scrolling with mouse wheel
>  scrolls the buffer horizontally;
>
>>   >  but while I use the mouse in other apps,
>>   > every time I try to use the mouse in Emacs, I can't make any sense of
>>   > default mouse bindings mess,
>>
>> Which bindings do you find confusing?
>
>This is just incompatibility between the currently active old mode
>that follows what X applications do, and more modern mouse bindings
>used nowadays in other applications.  So two separate modes are needed.

I haven't follow this but it seems very interesting, do you think it
makes sense that this becomes part of CUA-mode or are you thinking to
keep it apart?

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Philip K.]

Ergus <spacibba@aol.com> writes:

> But after all I understood that it is very hard to convince anyone
> (students, colleges, projects managers) to invest so much time and
> reading to learn how to do something simple they already know how to do
> everywhere else.

I sometimes feel this aspect is overstated. Yes, you might be a bit
confused at first, but learning the basics of *using* Emacs isn't a
intellectual endeavour. Arrow keys work, "Home", "End", "Delete"
too. "Copy-Pasting" is probably the first big hurdle, but that's just a
1:1 mapping at first. Buffer and window management are 3-4 keybindings
each. Working with files really only requires understating how to open
files and how to save them. With these few keybindings, you already know
the basics. I've seen people stick to vim just because it's cool knowing
less about the editor.

Sure, if someone's in a hurry to edit a file, they don't want to learn
how to use a proper Editor first, but I don't think that Emacs should be
geared towards that demographic either. If you want to open a file via
the GUI, change a few words and forget about it, Gedit/Kwrite/Mousepad
is probably a better choice (with better DE integration).

-- 
	Philip K.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Juri Linkov]

> I haven't follow this but it seems very interesting, do you think it
> makes sense that this becomes part of CUA-mode or are you thinking to
> keep it apart?

This is a separate mode with a name like 'modern-mouse-mode'
that also should enable another sub-mode 'context-menu-mode'.

Should this mode also be activated by CUA-mode?  Maybe.
But this is a separate question.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> Constructively, I propose to include in Emacs a new mode
> (with a name like 'modern-mouse-mode') where
>
> - down-mouse-3 and mouse-3 pop up the context menu
>   containing at least the items "Cut", "Copy", "Paste", "Undo", "Redo"
>   (and only "Copy" when the buffer is in read-only mode);
> - holding down the Shift key while using mouse-1 adjusts
>   the already active region;
> - dragging the active region moves it to the place
>   where the mouse-1 was released;
> - dragging the active region copies it to another place
>   while holding down the Control key;
> - holding down the Shift key while scrolling with mouse wheel
>   scrolls the buffer horizontally;

I agree with all of this.

But why not make this the default?  It's a low hanging fruit where there
is no reason not to make Emacs like other editors (well, except for
hysterical raisins).

Presumably none of it would cause any major problems for existing power
users.  Most discussions here seem to indicate they are more inclined to
use they keyboard than the mouse.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Constructively, I propose to include in Emacs a new mode
  > > (with a name like 'modern-mouse-mode') where

Sure, why not?

  > But why not make this the default?

Changing the default is a serious matter.  It requires agreement that
the new default is better.  By contrast, introducing a new optional
mode does not require much discussion.

Once we release Emacs with this new mode, we can ask users to try it
and we can find out whether people like it.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Tak Kunihiro]

To have pop up menu after long click sounds very useful.

- https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00267.html
- https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01277.html

I want to bind context menus to down-mouse-1 instead of down-mouse-3.

Re: Context menus and mouse-3 [was: Changes for emacs 28]

[Tak Kunihiro]

I think framework of context menu should be provided by Emacs,
as suggested three years ago by Stefan.

https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00416.html

I propose a system something like below.

A list for menu candidates is defined in advance.  After first one is
evaluated, then it returns menu or nil.  When it is menu, we pop menu
up.  When it is nil, the second one is evaluated.  The last one should
always return menu.

(defvar mouse-context-menu-functions
  '(mouse-help-menu             ; HELP menu
    mouse-info-menu             ; INFO menu
    mouse-file-menu             ; FILE menu
    mouse-dir-menu              ; DIR menu
    mouse-word-menu             ; WORD menu
    mouse-url-menu              ; URL menu
    menu-bar-edit-menu          ; EDIT menu (default))
  "Function that builds the context-menu.
Takes one argument (the EVENT that requests the menu) and should return
a list of menu items or nil")

Re: Context menus and mouse-3

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

>>   > We don't need to choose, since we can get a context menu on
>>   > `down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.
>
>     (defun mouse-maybe-context-menu (event)
>       "Bring up a context menu for a long click.
>     See `mouse-long-click-time' and `mouse-context-menu-function'."
>       (interactive "@e")
>       (if (let ((track-mouse t)) (sit-for (/ mouse-long-click-time 1000.0)))
>           (push (cons 'context-menu (cdr event)) unread-command-events)))
>
> It's not good enough for `master` (IIRC the sit-for tends to return nil
> immediately in some circumstances), but I didn't pursue this any further
> given the lack of interest at the time.  I can't think of any reason why
> it should be hard to fix.

This is a much needed feature and it would nice to finish it one way or another.
I tried to use timers, and the result works well in all test cases:

1. Modes that already bind down-mouse-3 continue working without problems,
   so e.g. smerge-popup-context-menu works fine.  BTW, while testing it
   by clicking down-mouse-3 in non-selected windows, I found a problem,
   so a fix for this very rare problem is also included in the patch.

   For the same reason 'popup-menu' needs to be called explicitly
   to be able to select the right window, as the patch does,
   for the case when the mouse is dragged and down-mouse-3
   is released in another window.

2. flyspell.el doesn't need to be changed.  ibuffer.el works too.

3. cua-rect.el helped to fix one problem and now is supported too.

The new user option mouse-3-down-context-menu is based on mouse-1-click-follows-link.
Currently mouse-context-menu-map shows just the Edit menu - filling the content
of the context menu with e.g. mouse-context-menu-function is a separate task.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mouse-3-down-context-menu.patch --]
[-- Type: text/x-diff, Size: 4670 bytes --]

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 89e5d7c48a..febda78212 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -156,6 +156,82 @@ key-translation-map
 (define-key key-translation-map [double-mouse-1]
   #'mouse--click-1-maybe-follows-link)
 
+\f
+(defcustom mouse-3-down-context-menu 450
+  "Non-nil means that holding down Mouse-3 shows context menu.
+
+With the default setting, holding down the Mouse-3 button
+for more than 450 milliseconds performs the same action as S-Down-Mouse-3
+\(which shows the menu), while an ordinary Mouse-3 click performs the
+original Mouse-3 binding (which typically sets the region where you
+click the mouse).
+
+If value is an integer, the time elapsed between pressing and
+releasing the mouse button determines whether to show the menu
+or perform the normal Mouse-3 action (typically set the region).
+The absolute numeric value specifies the maximum duration of a
+\"short click\" in milliseconds.  A positive value means that a
+short click shows the menu, and a longer click performs the
+normal action.
+
+Otherwise, a single Mouse-3 click unconditionally shows the menu."
+  :version "28.1"
+  :type '(choice (const :tag "Disabled" nil)
+                 (number :tag "Single click time limit" :value 450)
+                 (other :tag "Single click" t)))
+
+(defvar mouse--down-3-timer nil)
+
+(defun mouse-maybe-context-menu (event)
+  (interactive "@e")
+  (cond
+   ;; Delay context menu display.
+   ((numberp mouse-3-down-context-menu)
+    (when (timerp mouse--down-3-timer)
+      (cancel-timer mouse--down-3-timer))
+    (setq mouse--down-3-timer
+          (run-with-timer
+           (/ (abs mouse-3-down-context-menu) 1000.0) nil
+           (lambda ()
+             (setq mouse--down-3-timer t)
+             (unless (eq (posn-window (event-end event)) (selected-window))
+               (select-window (posn-window (event-end event))))
+             (mouse-context-menu event))))
+    nil)
+   ;; Immediately pop up context menu.
+   (mouse-3-down-context-menu
+    (unless (eq (posn-window (event-end event)) (selected-window))
+      (select-window (posn-window (event-end event))))
+    (mouse-context-menu event))))
+
+(defun mouse--click-3-maybe-context-menu (&optional _prompt)
+  (cond
+   ((numberp mouse-3-down-context-menu)
+    (cond
+     ((timerp mouse--down-3-timer)
+      ;; Don't wait for context menu and fall back to mouse-save-then-kill.
+      (cancel-timer mouse--down-3-timer)
+      (setq mouse--down-3-timer nil)
+      nil)
+     (mouse--down-3-timer
+      ;; Context menu was displayed after delay.
+      (setq mouse--down-3-timer nil)
+      [])))
+   ;; Context menu was displayed immediately.
+   (mouse-3-down-context-menu
+    [])))
+
+(define-key key-translation-map [mouse-3]
+  #'mouse--click-3-maybe-context-menu)
+
+(defun mouse-context-menu-map ()
+  (cddr (assq 'edit (lookup-key global-map [menu-bar]))))
+
+(defun mouse-context-menu (event)
+  "Show a context menu for the current buffer."
+  (interactive "@e")
+  (popup-menu (mouse-context-menu-map) event))
+
 \f
 ;; Provide a mode-specific menu on a mouse button.
 
@@ -1672,7 +1748,7 @@ mouse-save-then-kill
      ((not (numberp click-pt)) nil)
      ;; If the user clicked without moving point, kill the region.
      ;; This also resets `mouse-selection-click-count'.
-     ((and (eq last-command 'mouse-save-then-kill)
+     ((and (memq last-command '(mouse-save-then-kill mouse-maybe-context-menu))
 	   (eq click-pt mouse-save-then-kill-posn)
 	   (eq window (selected-window)))
       (if mouse-drag-copy-region
@@ -2899,6 +2975,8 @@ function-key-map
 ;; Allow yanking also when the corresponding cursor is "in the fringe".
 (define-key function-key-map [right-fringe mouse-2] 'mouse--strip-first-event)
 (define-key function-key-map [left-fringe mouse-2] 'mouse--strip-first-event)
+
+(global-set-key [down-mouse-3]	'mouse-maybe-context-menu)
 (global-set-key [mouse-3]	'mouse-save-then-kill)
 (define-key function-key-map [right-fringe mouse-3] 'mouse--strip-first-event)
 (define-key function-key-map [left-fringe mouse-3] 'mouse--strip-first-event)
diff --git a/lisp/vc/smerge-mode.el b/lisp/vc/smerge-mode.el
index 694d4529b9..3aa7399dd5 100644
--- a/lisp/vc/smerge-mode.el
+++ b/lisp/vc/smerge-mode.el
@@ -385,6 +385,8 @@ smerge-remove-props
 (defun smerge-popup-context-menu (event)
   "Pop up the Smerge mode context menu under mouse."
   (interactive "e")
+  (unless (eq (posn-window (event-end event)) (selected-window))
+    (select-window (posn-window (event-end event))))
   (if (and smerge-mode
 	   (save-excursion (posn-set-point (event-end event)) (smerge-check 1)))
       (progn

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

[Drew Adams]

> This is a much needed feature and it would nice to
> finish it one way or another.

I still propose that library `mouse3.el' be added
to Emacs.  From a year ago:

  I propose that it be added to Emacs, that the
  behavior it offers be included, and even made
  the default behavior.  It doesn't conflict with
  the current behavior - it supplements it.

  Which context menus are provided out of the box
  can be discussed.  `mouse3.el' gives users and
  libraries easy ways to get the menus they want,
  but what menus Emacs should provide by default
  is an open question.

Description:

https://www.emacswiki.org/emacs/Mouse3

Code:

https://www.emacswiki.org/emacs/download/mouse3.el

Re: Context menus and mouse-3

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 12 Jul 2021 02:38:19 +0300
> Cc: philipk@posteo.net, Richard Stallman <rms@gnu.org>, spacibba@aol.com,
>  emacs-devel@gnu.org, arthur.miller@live.com, dgutov@yandex.ru, ghe@sdf.org,
>  drew.adams@oracle.com
> 
> >>   > We don't need to choose, since we can get a context menu on
> >>   > `down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.
> >
> >     (defun mouse-maybe-context-menu (event)
> >       "Bring up a context menu for a long click.
> >     See `mouse-long-click-time' and `mouse-context-menu-function'."
> >       (interactive "@e")
> >       (if (let ((track-mouse t)) (sit-for (/ mouse-long-click-time 1000.0)))
> >           (push (cons 'context-menu (cdr event)) unread-command-events)))
> >
> > It's not good enough for `master` (IIRC the sit-for tends to return nil
> > immediately in some circumstances), but I didn't pursue this any further
> > given the lack of interest at the time.  I can't think of any reason why
> > it should be hard to fix.
> 
> This is a much needed feature and it would nice to finish it one way or another.
> I tried to use timers, and the result works well in all test cases:

Could you please remind us the problem you are trying to solve here?

Thanks.

Re: Context menus and mouse-3

[Juri Linkov]

>> >>   > We don't need to choose, since we can get a context menu on
>> >>   > `down-mouse-3` and 'mouse-save-then-kill' on `mouse-3`.
>> >
>> >     (defun mouse-maybe-context-menu (event)
>> >       "Bring up a context menu for a long click.
>> >     See `mouse-long-click-time' and `mouse-context-menu-function'."
>> >       (interactive "@e")
>> >       (if (let ((track-mouse t)) (sit-for (/ mouse-long-click-time 1000.0)))
>> >           (push (cons 'context-menu (cdr event)) unread-command-events)))
>> >
>> > It's not good enough for `master` (IIRC the sit-for tends to return nil
>> > immediately in some circumstances), but I didn't pursue this any further
>> > given the lack of interest at the time.  I can't think of any reason why
>> > it should be hard to fix.
>>
>> This is a much needed feature and it would nice to finish it one way or another.
>> I tried to use timers, and the result works well in all test cases:
>
> Could you please remind us the problem you are trying to solve here?

Nowadays every other app uses down-mouse-3 to pop up a context menu,
but in Emacs mouse-3 operates on the region.  So the solution is
similar to mouse-1-click-follows-link: to pop up a context menu
after a delay, otherwise the immediate click operates on the region.

The only thing I don't understand why couldn't the context-menu
implementation be the same as the menu-bar implementation?

The global binding of [menu-bar] is defined in menu-bar.el,
so the same way [context-menu] could be defined globally
with the standard bindings such as all other apps have:
"Cut", "Copy", "Paste", "Select All", "Undo", "Redo".
Then the users will be able to customize the global
[context-menu] applicable to all buffers.

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

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.

Re: Context menus and mouse-3

[Stefan Monnier]

Juri Linkov [2021-07-12 02:38:19] wrote:
> This is a much needed feature and it would nice to finish it one way or another.
> I tried to use timers, and the result works well in all test cases:
[...]
> +    (setq mouse--down-3-timer
> +          (run-with-timer
> +           (/ (abs mouse-3-down-context-menu) 1000.0) nil
> +           (lambda ()
> +             (setq mouse--down-3-timer t)
> +             (unless (eq (posn-window (event-end event)) (selected-window))
> +               (select-window (posn-window (event-end event))))
> +             (mouse-context-menu event))))
[...]
> (defun mouse-context-menu (event)
>   "Show a context menu for the current buffer."
>   (interactive "@e")
>   (popup-menu (mouse-context-menu-map) event))

I'm a bit busy with other things these days, but just looking at the
above code, one thing I see as a potential problem with this code is
that the context menu commands won't be run "the normal way": the
undo-boundary won't be applied as usual, post/pre-command-hook won't be
run as usual, etc...

> The global binding of [menu-bar] is defined in menu-bar.el,
> so the same way [context-menu] could be defined globally

Agreed, and I think it would address the above problem.
I.e. do something like

    (defun mouse-context-menu (event)
      (push `(context-menu . ,(cdr event)) unread-command-events))

BTW, the other worry with your code is that if you use an input device
which can fail to pair the down/up mouse-3 events, you might end up
failing to cancel the timer code (that can also happen when the users
set a binding for `drag-mouse-3`, I think), so maybe you should arrange
for the down event to register a `pre-command-hook` that cancels
the timer.

In terms of aesthetics, it would be good to arrange the code such that
`mouse--click-3-maybe-context-menu` doesn't need to duplicate/mimic the
tests performed in `mouse-maybe-context-menu`.  Maybe have
`mouse-maybe-context-menu` set some var telling
`mouse--click-3-maybe-context-menu` when the next `mouse-3` should
be dropped?


        Stefan


PS: FWIW, the "proof of concept" code I have in my local Emacs is:

    (global-set-key [down-mouse-3] #'mouse-maybe-context-menu)
    (defun mouse-maybe-context-menu (event)
      "Bring up a context menu for a long click."
      (interactive "@e")
      (if (let* ((track-mouse t)
                 (time (/ mouse-long-click-time 1000.0))
                 (result (sit-for time)))
            (message "Maybe-context-menu: %S %S" time result)
            result)
          (push (cons 'context-menu (cdr event)) unread-command-events)))

I think `sit-for` can be made to work OK, but my proof-of-concept
isn't good enough.  I think the main issue is that it doesn't
swallow the mouse-3 click, but I haven't really looked into it.

Re: Context menus and mouse-3

[Juri Linkov]

>> The global binding of [menu-bar] is defined in menu-bar.el,
>> so the same way [context-menu] could be defined globally
>
> Agreed, and I think it would address the above problem.
> I.e. do something like
>
>     (defun mouse-context-menu (event)
>       (push `(context-menu . ,(cdr event)) unread-command-events))

OT1H, this avoids an explicit call to 'popup-menu'.  But OTOH,
this precludes constructing the context-menu with a user-defined
function mouse-context-menu-function.

I tried to override the global [context-menu] with e.g. menu-bar-custom-menu
(that later could be replaced with the value returned from mouse-context-menu-function):

    (let ((map (make-sparse-keymap)))
      (define-key map [context-menu] menu-bar-custom-menu)
      (set-transient-map map))
    (push (cons 'context-menu (cdr event)) unread-command-events)

However, it doesn't override the global [context-menu], but prepends
the transient [context-menu] before the global one.

> PS: FWIW, the "proof of concept" code I have in my local Emacs is:
[...]
> I think `sit-for` can be made to work OK, but my proof-of-concept
> isn't good enough.  I think the main issue is that it doesn't
> swallow the mouse-3 click, but I haven't really looked into it.

At least, now we have two implementations, and both could be improved
before selecting the one that works better.  Meanwhile, I'd continue
trying to combine [context-menu] with mouse-context-menu-function.

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

Re: Context menus and mouse-3

[Stefan Monnier]

>>> The global binding of [menu-bar] is defined in menu-bar.el,
>>> so the same way [context-menu] could be defined globally
>> Agreed, and I think it would address the above problem.
>> I.e. do something like
>>
>>     (defun mouse-context-menu (event)
>>       (push `(context-menu . ,(cdr event)) unread-command-events))
>
> OT1H, this avoids an explicit call to 'popup-menu'.

Calling `popup-menu` is not a problem, but not doing the dance usually
done by the command loop is more problematic.

> But OTOH, this precludes constructing the context-menu with
> a user-defined function mouse-context-menu-function.

Actually it doesn't.
You can bind `context-menu` to a command that uses that function and
then passes the result to `popup-menu`, or you can bind it to something like

        `(menu-item "Context menu" ignore
          :filter (lambda (_)
                    ..call mouse-context-menu-function..))

> I tried to override the global [context-menu] with e.g. menu-bar-custom-menu
> (that later could be replaced with the value returned from mouse-context-menu-function):
>
>     (let ((map (make-sparse-keymap)))
>       (define-key map [context-menu] menu-bar-custom-menu)
>       (set-transient-map map))
>     (push (cons 'context-menu (cdr event)) unread-command-events)
>
> However, it doesn't override the global [context-menu], but prepends
> the transient [context-menu] before the global one.

Yes, if the key is bound in various keymaps and all the bindings are to
a keymap, then those keymaps get merged, as usual for prefix keymaps.

Two ways to solve that:
- use `mouse-context-menu-function` instead of adding a new local
  key binding for `context-menu`.
- don't bind `context-menu` to a keymap but to a command (that
  presumably then uses `popup-menu` internally).

>> PS: FWIW, the "proof of concept" code I have in my local Emacs is:
> [...]
>> I think `sit-for` can be made to work OK, but my proof-of-concept
>> isn't good enough.  I think the main issue is that it doesn't
>> swallow the mouse-3 click, but I haven't really looked into it.
>
> At least, now we have two implementations, and both could be improved
> before selecting the one that works better.

FWIW I think yours holds more promise, so I don't intend to try and
improve mine.


        Stefan

Re: Context menus and mouse-3

[Eli Zaretskii]

> 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: Mon, 12 Jul 2021 23:56:39 +0300
> 
> Nowadays every other app uses down-mouse-3 to pop up a context menu,
> but in Emacs mouse-3 operates on the region.  So the solution is
> similar to mouse-1-click-follows-link: to pop up a context menu
> after a delay, otherwise the immediate click operates on the region.

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.

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?

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

Thanks.

Re: Context menus and mouse-3

[Juri Linkov]

>> I tried to override the global [context-menu] with e.g. menu-bar-custom-menu
>> (that later could be replaced with the value returned from mouse-context-menu-function):
>>
>>     (let ((map (make-sparse-keymap)))
>>       (define-key map [context-menu] menu-bar-custom-menu)
>>       (set-transient-map map))
>>     (push (cons 'context-menu (cdr event)) unread-command-events)
>>
>> However, it doesn't override the global [context-menu], but prepends
>> the transient [context-menu] before the global one.
>
> Yes, if the key is bound in various keymaps and all the bindings are to
> a keymap, then those keymaps get merged, as usual for prefix keymaps.
>
> Two ways to solve that:
> - use `mouse-context-menu-function` instead of adding a new local
>   key binding for `context-menu`.
> - don't bind `context-menu` to a keymap but to a command (that
>   presumably then uses `popup-menu` internally).

`popup-menu` has the same problems: it doesn't run post/pre-command-hook, etc.
because it uses `call-interactively`.  So any code that is based on `popup-menu`
such as `org-mouse-show-context-menu` has the same problems, and any code
that uses `call-interactively` such as `tmm-prompt`.

But it's possible to replace `call-interactively` with something like:

    (let ((command (car (x-popup-menu event menu-bar-custom-menu)))
          (map (make-sparse-keymap)))
      (define-key map [next-command] command)
      (set-transient-map map t))
    (push (cons 'next-command (cdr event)) unread-command-events)

It works surprisingly well, and I really see no problems with this.

Re: Context menus and mouse-3

[Juri Linkov]

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

Re: Context menus and mouse-3

[Stefan Monnier]

>>> I tried to override the global [context-menu] with e.g. menu-bar-custom-menu
>>> (that later could be replaced with the value returned from mouse-context-menu-function):
>>>
>>>     (let ((map (make-sparse-keymap)))
>>>       (define-key map [context-menu] menu-bar-custom-menu)
>>>       (set-transient-map map))
>>>     (push (cons 'context-menu (cdr event)) unread-command-events)
>>>
>>> However, it doesn't override the global [context-menu], but prepends
>>> the transient [context-menu] before the global one.
>>
>> Yes, if the key is bound in various keymaps and all the bindings are to
>> a keymap, then those keymaps get merged, as usual for prefix keymaps.
>>
>> Two ways to solve that:
>> - use `mouse-context-menu-function` instead of adding a new local
>>   key binding for `context-menu`.
>> - don't bind `context-menu` to a keymap but to a command (that
>>   presumably then uses `popup-menu` internally).
>
> `popup-menu` has the same problems: it doesn't run post/pre-command-hook, etc.

That doesn't matter: the command loop does that for us before/after calling
the command bound to `context-menu`, so the command bound to
`context-menu` doesn't need to do it.  The problem with your original
call is not the use of `popup-menu` but the fact that it runs it from
from a timer.


        Stefan

Re: Context menus and mouse-3

[Eli Zaretskii]

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

Re: Context menus and mouse-3

[Juri Linkov]

> The problem with your original call is not the use of `popup-menu`
> but the fact that it runs it from from a timer.

So when the user wants the context menu to pop up after a delay then

  (push (cons 'context-menu (cdr event)) unread-command-events)

is a less problematic way to do this.  But for another case
to pop up the context menu immediately, customizing
mouse-3-down-context-menu to nil and still using the same
translation functions like mouse--click-3-maybe-context-menu
is not the most optimal way.

To pop up it immediately, I see no better way than currently
is implemented for C-down-mouse-3 because then C-h k C-down-mouse-3
works smoothly as well as Undo selected from the menu keeps undoing
on consequent calls, etc.

This means there is a need to create a new mode that when enabled
will bind the context menu directly to the key down-mouse-3
and unbind mouse-3 from mouse-save-then-kill
when the user wants to pop up it immediately.

Re: Context menus and mouse-3

[Juri Linkov]

>> 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"?

When the menu-bar is disabled, then C-down-mouse-3 pops up the global
menu where "Edit" contains "Paste".  When the menu-bar is enabled,
then some modes include "Paste" (e.g. calculator-paste) in a buffer-local menu.
And some modes like org-mode, flyspell-mode, etc. already redefine
down-mouse-3 to pop up context menus.

> I thought we were talking about existing menus popped by mouse-2 that

I suppose you meant C-down-mouse-3?

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

It seems a new minor mode is unavoidable because when the user wants
down-mouse-3 to pop up the context menu immediately, then
for the best effect down-mouse-3 should be bound directly
to the context-map, instead of sending the [context-menu] event.

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

The users who currently use mouse-3 to operate on the region
might want to continue using it even on context-sensitive regions.

For example, like in all browsers, down-mouse-3 in e.g. Info browser or eww,
will show the menu with such items as "Backward" and "Forward".
But when down-mouse-3 will be clicked on a link, it will display
the context sensitive menu with "Follow" and "Open in New Window".

Re: Context menus and mouse-3

[Stefan Monnier]

Juri Linkov [2021-07-15 02:32:14] wrote:
>> The problem with your original call is not the use of `popup-menu`
>> but the fact that it runs it from from a timer.
>
> So when the user wants the context menu to pop up after a delay then
>
>   (push (cons 'context-menu (cdr event)) unread-command-events)

Yup.

> To pop up it immediately, I see no better way than currently
> is implemented for C-down-mouse-3 because then C-h k C-down-mouse-3
> works smoothly as well as Undo selected from the menu keeps undoing
> on consequent calls, etc.

Indeed.  Maybe we can bring them together by (when
`mouse-3-down-context-menu` is t) using a remapping from `down-mouse-3`
to `context-menu`.  It seems pretty intrusive, tho :-(

Maybe a better option is to make it so the `context-menu` event is kept
internal (give it a less attractive name), i.e. just an implementation
detail for the case where the menu pops up after a delay.


        Stefan

Re: Context menus and mouse-3

[Eli Zaretskii]

> 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: Thu, 15 Jul 2021 02:37:11 +0300
> 
> >> 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"?
> 
> When the menu-bar is disabled, then C-down-mouse-3 pops up the global
> menu where "Edit" contains "Paste".  When the menu-bar is enabled,
> then some modes include "Paste" (e.g. calculator-paste) in a buffer-local menu.

So you want to have the same menus on mouse-3, including when the menu
bar is not disabled?

> And some modes like org-mode, flyspell-mode, etc. already redefine
> down-mouse-3 to pop up context menus.

But those modes define those context menus on special parts of
display, where pasting etc. makes less sense, no?

> > I thought we were talking about existing menus popped by mouse-2 that
> 
> I suppose you meant C-down-mouse-3?

Both, I guess.

> > 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.
> 
> It seems a new minor mode is unavoidable because when the user wants
> down-mouse-3 to pop up the context menu immediately, then
> for the best effect down-mouse-3 should be bound directly
> to the context-map, instead of sending the [context-menu] event.

I'm okay with adding a minor mode for this.  Based on its popularity,
we could later discuss whether it should be turned on by default.

> The users who currently use mouse-3 to operate on the region
> might want to continue using it even on context-sensitive regions.
> 
> For example, like in all browsers, down-mouse-3 in e.g. Info browser or eww,
> will show the menu with such items as "Backward" and "Forward".
> But when down-mouse-3 will be clicked on a link, it will display
> the context sensitive menu with "Follow" and "Open in New Window".

If this kind of "dwim-ish" heuristic solves the issue, we should use
it.  In situations where such heuristic doesn't give good results,
perhaps this new minor mode we are talking about can also decide which
alternative to prefer when it isn't clear-cut.

Re: Context menus and mouse-3

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 15 Jul 2021 02:32:14 +0300
> Cc: philipk@posteo.net, Richard Stallman <rms@gnu.org>, spacibba@aol.com,
>  emacs-devel@gnu.org, arthur.miller@live.com, dgutov@yandex.ru, ghe@sdf.org,
>  drew.adams@oracle.com
> 
> This means there is a need to create a new mode that when enabled
> will bind the context menu directly to the key down-mouse-3
> and unbind mouse-3 from mouse-save-then-kill
> when the user wants to pop up it immediately.

Instead of unbinding mouse-save-then-kill, this new mode could rebind
it to C-down-mouse-3, so that users could still invoke the command.

Re: Context menus and mouse-3

[Juri Linkov]

>> When the menu-bar is disabled, then C-down-mouse-3 pops up the global
>> menu where "Edit" contains "Paste".  When the menu-bar is enabled,
>> then some modes include "Paste" (e.g. calculator-paste) in a buffer-local menu.
>
> So you want to have the same menus on mouse-3, including when the menu
> bar is not disabled?

Exactly.

>> And some modes like org-mode, flyspell-mode, etc. already redefine
>> down-mouse-3 to pop up context menus.
>
> But those modes define those context menus on special parts of
> display, where pasting etc. makes less sense, no?

When the buffer is not read-only, I see no reason to disallow
pasting text because e.g. in flyspell-mode it makes sense
to paste a correction to a misspelled word, etc.

Re: Context menus and mouse-3

[Juri Linkov]

>> This means there is a need to create a new mode that when enabled
>> will bind the context menu directly to the key down-mouse-3
>> and unbind mouse-3 from mouse-save-then-kill
>> when the user wants to pop up it immediately.
>
> Instead of unbinding mouse-save-then-kill, this new mode could rebind
> it to C-down-mouse-3, so that users could still invoke the command.

Swapping mouse-3 and C-down-mouse-3 would be a good thing.  Another
necessary change to emulate the behavior of modern apps is to rebind
mouse-save-then-kill to S-mouse-1.

Maybe it's possible to add a delay so that the current binding [S-down-mouse-1]
could pop up mouse-appearance-menu only after a delay, e.g. 450ms.
But on releasing S-mouse-1 immediately, it could use mouse-save-then-kill
as modern apps do.

Re: Context menus and mouse-3

[Juri Linkov]

>> To pop up it immediately, I see no better way than currently
>> is implemented for C-down-mouse-3 because then C-h k C-down-mouse-3
>> works smoothly as well as Undo selected from the menu keeps undoing
>> on consequent calls, etc.
>
> Indeed.  Maybe we can bring them together by (when
> `mouse-3-down-context-menu` is t) using a remapping from `down-mouse-3`
> to `context-menu`.  It seems pretty intrusive, tho :-(

I don't know what I did wrong but this does nothing:

  (global-set-key [down-mouse-3] [context-menu])
  (global-set-key [context-menu]
    `(menu-item ,(purecopy "Context Menu") ignore
      :filter (lambda (_) (mouse-context-menu-map))))

whereas this works fine:

  (global-set-key [down-mouse-3]
    `(menu-item ,(purecopy "Context Menu") ignore
      :filter (lambda (_) (mouse-context-menu-map))))

> Maybe a better option is to make it so the `context-menu` event is kept
> internal (give it a less attractive name), i.e. just an implementation
> detail for the case where the menu pops up after a delay.

A minor mode will also need to remove this binding

  (define-key key-translation-map [mouse-3]
    #'mouse--click-3-maybe-context-menu)

when `mouse-3-down-context-menu` is t, and to unbind
[mouse-3] from 'mouse-save-then-kill' because sometimes
'mouse-save-then-kill' still gets called, I haven't investigated why.

Re: Context menus and mouse-3

[Eli Zaretskii]

> 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: Fri, 16 Jul 2021 01:23:09 +0300
> 
> >> And some modes like org-mode, flyspell-mode, etc. already redefine
> >> down-mouse-3 to pop up context menus.
> >
> > But those modes define those context menus on special parts of
> > display, where pasting etc. makes less sense, no?
> 
> When the buffer is not read-only, I see no reason to disallow
> pasting text because e.g. in flyspell-mode it makes sense
> to paste a correction to a misspelled word, etc.

IMO, when mouse-3 is clocked on a misspelled word, it makes much more
sense to assume the user wants to fix that word than that the user
wants to paste.

But here's an idea: how about merging the two menus into one in these
cases?  We could add a top-level menu with the two alternatives, each
one would then drop down one of the two possible menus.
Alternatively, just make a long menu by concatenating the contents of
the two original ones.

WDYT?

Re: Context menus and mouse-3

[Eli Zaretskii]

> 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: Fri, 16 Jul 2021 01:28:30 +0300
> 
> Another necessary change to emulate the behavior of modern apps is
> to rebind mouse-save-then-kill to S-mouse-1.
> 
> Maybe it's possible to add a delay so that the current binding [S-down-mouse-1]
> could pop up mouse-appearance-menu only after a delay, e.g. 450ms.
> But on releasing S-mouse-1 immediately, it could use mouse-save-then-kill
> as modern apps do.

Once again, I think lumping such different commands on the same mouse
gesture controlled by some more-or-less arbitrary timeout is not a
good UI.  We should avoid that as much as we possible can.

Re: Context menus and mouse-3

[Stefan Monnier]

>> Indeed.  Maybe we can bring them together by (when
>> `mouse-3-down-context-menu` is t) using a remapping from `down-mouse-3`
>> to `context-menu`.  It seems pretty intrusive, tho :-(
> I don't know what I did wrong but this does nothing:
>   (global-set-key [down-mouse-3] [context-menu])

This is a keyboard macro and the "extra info" (the `posn`) associated
with the `down-mouse-3` will not be passed on to the `context-menu`
event, so that's probably why it "does nothing".

Maybe something like

    (global-set-key [down-mouse-3]
      (lambda (event)
        (interactive "e")
        (execute-kbd-macro (vector `(context-menu . ,(cdr event))))))

??


        Stefan

Re: Context menus and mouse-3

[Juri Linkov]

>> I don't know what I did wrong but this does nothing:
>>   (global-set-key [down-mouse-3] [context-menu])
>
> This is a keyboard macro and the "extra info" (the `posn`) associated
> with the `down-mouse-3` will not be passed on to the `context-menu`
> event, so that's probably why it "does nothing".
>
> Maybe something like
>
>     (global-set-key [down-mouse-3]
>       (lambda (event)
>         (interactive "e")
>         (execute-kbd-macro (vector `(context-menu . ,(cdr event))))))
>
> ??

Nope, this doesn't fly.  Then for debugging tried:

  (global-set-key [context-menu]
    (lambda (&rest args) (interactive) (message "=> %S" args)))

  (global-set-key [down-mouse-3]
        (lambda (event)
          (interactive "e")
          (execute-kbd-macro (vector `(context-menu . ,(cdr event))))))

but it prints => nil

Re: Context menus and mouse-3

[Juri Linkov]

>> Another necessary change to emulate the behavior of modern apps is
>> to rebind mouse-save-then-kill to S-mouse-1.
>>
>> Maybe it's possible to add a delay so that the current binding [S-down-mouse-1]
>> could pop up mouse-appearance-menu only after a delay, e.g. 450ms.
>> But on releasing S-mouse-1 immediately, it could use mouse-save-then-kill
>> as modern apps do.
>
> Once again, I think lumping such different commands on the same mouse
> gesture controlled by some more-or-less arbitrary timeout is not a
> good UI.  We should avoid that as much as we possible can.

Then maybe it could be enabled by the same mode e.g. 'modern-mouse-mode'.

Re: Context menus and mouse-3

[Juri Linkov]

>> >> And some modes like org-mode, flyspell-mode, etc. already redefine
>> >> down-mouse-3 to pop up context menus.
>> >
>> > But those modes define those context menus on special parts of
>> > display, where pasting etc. makes less sense, no?
>> 
>> When the buffer is not read-only, I see no reason to disallow
>> pasting text because e.g. in flyspell-mode it makes sense
>> to paste a correction to a misspelled word, etc.
>
> IMO, when mouse-3 is clocked on a misspelled word, it makes much more
> sense to assume the user wants to fix that word than that the user
> wants to paste.
>
> But here's an idea: how about merging the two menus into one in these
> cases?  We could add a top-level menu with the two alternatives, each
> one would then drop down one of the two possible menus.
> Alternatively, just make a long menu by concatenating the contents of
> the two original ones.
>
> WDYT?

Tak Kunihiro had a very good idea of using a hook-like variable
that contains a list of functions that return parts of the whole
context-menu, then these parts will be collected into the final menu.

Re: Context menus and mouse-3

[Stefan Monnier]

>>     (global-set-key [down-mouse-3]
>>       (lambda (event)
>>         (interactive "e")
>>         (execute-kbd-macro (vector `(context-menu . ,(cdr event))))))
>>
>> ??
>
> Nope, this doesn't fly.  Then for debugging tried:
>
>   (global-set-key [context-menu]
>     (lambda (&rest args) (interactive) (message "=> %S" args)))
>
>   (global-set-key [down-mouse-3]
>         (lambda (event)
>           (interactive "e")
>           (execute-kbd-macro (vector `(context-menu . ,(cdr event))))))

Then I guess the only way that will work is if the rewrite from `down-mouse-3`
to `context-menu` is performed directly via
`input-decode-map/function-key-map/key-translation-map`.

Of course, you can also forgo rewriting to `context-menu` and
have the `down-mouse-3` event directly bring up the menu.


        Stefan

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

[Drew Adams]

> >> >> And some modes like org-mode, flyspell-mode, etc. already redefine
> >> >> down-mouse-3 to pop up context menus.
> >> >
> >> > But those modes define those context menus on special parts of
> >> > display, where pasting etc. makes less sense, no?
> >>
> >> When the buffer is not read-only, I see no reason to disallow
> >> pasting text because e.g. in flyspell-mode it makes sense
> >> to paste a correction to a misspelled word, etc.
> >
> > IMO, when mouse-3 is clocked on a misspelled word, it makes much more
> > sense to assume the user wants to fix that word than that the user
> > wants to paste.
> >
> > But here's an idea: how about merging the two menus into one in these
> > cases?  We could add a top-level menu with the two alternatives, each
> > one would then drop down one of the two possible menus.
> > Alternatively, just make a long menu by concatenating the contents of
> > the two original ones.
> >
> > WDYT?
> 
> Tak Kunihiro had a very good idea of using a hook-like variable
> that contains a list of functions that return parts of the whole
> context-menu, then these parts will be collected into the final menu.

FWIW -

`mouse3.el' has these variables:

`mouse3-region-popup-entries'
`mouse3-noregion-popup-entries'

`mouse3-region-popup-x-popup-panes'
`mouse3-noregion-popup-x-popup-panes'

Whether the first two or the second two are used is
controlled by option `mouse3-popup-x-popup-panes-flag'.

The difference corresponds to the two possibilities
offered by `x-popup-menu'.  The default is nil, so you
can use keymaps and extended menu items to define the
`mouse-3' menu.  The alternative is easy to use but
offers fewer possibilities.

The 2 `region' vars are used when the region is active.
The 2 `noregion' vars are used otherwise.
___

As for the choice of whether global menus should
be included in a `mouse-3' menu: Why decide that
at design time, hard-coding the behavior?
`mouse3.el' lets users decide, with option
`mouse3-popup-include-global-menus-flag'.
If non-nil then:

If the menu bar is visible then the major-mode menu
is the global menu to include on the `mouse-3' menu.
If the menu-bar is not shown then the menu-bar menus
are the menus to include on the `mouse-3' menu.
___

By default, the `mouse-3' menu has predefined submenus.
Users and code can modify the contents, of course.
(If the alternative panes approach is used, then the
operations are available in the single-level menu.)

These are the predefined submenus.  All except the
first are for when the region is active and nonempty.

`mouse3-noregion-popup-misc-submenu'
  Miscellaneous operations on a thing at mouse pointer:
    Email, open, visit, Dired, find, describe, highlight etc.

`mouse3-region-popup-change-text-submenu'
  Change the selected text:
    Fill, indent, transpose regions, upcase, etc.

`mouse3-region-popup-check-convert-submenu'
  Check, correct, or convert the selected text.

`mouse3-region-popup-copy-submenu'
  Copy selected text: text props, kill, to register etc.

`mouse3-region-popup-highlight-submenu'
  Highlight, unhighlight, copy/yank text props.

`mouse3-region-popup-misc-submenu'
  Miscellaneous operations on selected text:
    Count, narrow, eval, shell, write to file, etc.

`mouse3-region-popup-print-submenu'
  Print, PostScript print, BNF PostScript operations.

`mouse3-region-popup-rectangle-submenu'
  Selected rectangle: kill, delete, open, yank, clear, etc.

`mouse3-region-popup-register-submenu'
  Selected text to register: copy to, delete to, etc.

`mouse3-region-popup-remove/replace-items'
  Remove/replace selected text: kill, delete, yank.

`mouse3-region-popup-remove/replace-rect-submenu'
  Remove/replace selected rectangle:
    Clear, replace from last killed, string, register.

`mouse3-region-popup-search/replace-submenu'
  Isearch, query replace etc.

Re: Context menus and mouse-3

[Stefan Kangas]

Juri Linkov <juri@linkov.net> writes:

> Then maybe it could be enabled by the same mode e.g. 'modern-mouse-mode'.

But why make this conditional on a timeout?  I would have assumed the
"modern" way would be to just show the context menu unconditionally on
mouse-3, and ask for a modifier if you want to manipulate the region.

Re: Context menus and mouse-3

[Eli Zaretskii]

> 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: Fri, 16 Jul 2021 21:56:56 +0300
> 
> > Once again, I think lumping such different commands on the same mouse
> > gesture controlled by some more-or-less arbitrary timeout is not a
> > good UI.  We should avoid that as much as we possible can.
> 
> Then maybe it could be enabled by the same mode e.g. 'modern-mouse-mode'.

IMO, it's not a good idea to use "modern" in variable names.

Something like mouse-friendly-mode or alt-mouse-mode, maybe?

Re: Context menus and mouse-3

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 17 Jul 2021 01:13:45 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, "Philip K." <philipk@posteo.net>, Richard Stallman <rms@gnu.org>, 
> 	Ergus <spacibba@aol.com>, Emacs developers <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Arthur Miller <arthur.miller@live.com>, 
> 	Dmitry Gutov <dgutov@yandex.ru>, Gregory Heytings <ghe@sdf.org>, Drew Adams <drew.adams@oracle.com>
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> > Then maybe it could be enabled by the same mode e.g. 'modern-mouse-mode'.
> 
> But why make this conditional on a timeout?  I would have assumed the
> "modern" way would be to just show the context menu unconditionally on
> mouse-3, and ask for a modifier if you want to manipulate the region.

AFAIU, the suggestion is to use the minor mode to _replace_ the
timeout.

Re: Context menus and mouse-3

[Juri Linkov]

>> > Then maybe it could be enabled by the same mode e.g. 'modern-mouse-mode'.
>> 
>> But why make this conditional on a timeout?  I would have assumed the
>> "modern" way would be to just show the context menu unconditionally on
>> mouse-3, and ask for a modifier if you want to manipulate the region.
>
> AFAIU, the suggestion is to use the minor mode to _replace_ the
> timeout.

Indeed.  And maybe the same mode could still provide an option to
use the timeout if enabling the timeout by default is not an option.

Re: Context menus and mouse-3

[Tak Kunihiro]

>> IMO, when mouse-3 is clocked on a misspelled word, it makes much more
>> sense to assume the user wants to fix that word than that the user
>> wants to paste.
>>
>> But here's an idea: how about merging the two menus into one in these
>> cases?  We could add a top-level menu with the two alternatives, each
>> one would then drop down one of the two possible menus.
>> Alternatively, just make a long menu by concatenating the contents of
>> the two original ones.
>>
>> WDYT?
>
> Tak Kunihiro had a very good idea of using a hook-like variable
> that contains a list of functions that return parts of the whole
> context-menu, then these parts will be collected into the final menu.

The idea is to define a variable (something like below;
poplife-menu-candidates) with list of functions that returns nil or
keymap (something like below; poplife-mouse-word-menu).  A function
(something like below; poplife-context-menu) will test each of them
until it gets keymap.

In this way, to revise context menu is easy.

(defvar poplife-menu-candidates
  '(poplife-mouse-help-menu             ; HELP menu
    poplife-mouse-info-menu             ; INFO menu
    poplife-mouse-file-menu             ; FILE menu
    poplife-mouse-dir-menu              ; DIR menu
    poplife-mouse-word-menu             ; WORD menu
    poplife-mouse-url-menu              ; URL menu
    ;; menu-bar-edit-menu    ; EDIT menu (default)
    poplife-mouse-edit-menu)            ; EDIT menu
  "List of candidates for context menu.
Candidates are function or keymap.  They will be evaluated in the
order of the list.  A function should accept mouse EVENT, and
return keymap or nil.  The last candidate should return valid
keymap.")

(defun poplife-mouse-word-menu (event)
  "Return 'flyspell-correct-word when word under mouse cursor on EVENT is incorrect."
  (and
   (not (region-active-p))
   ;; Check face by (what-cursor-position t) or C-u C-x =.
   (let ((faces-at-point (mapcar (lambda (xxx) (overlay-get xxx 'face))
                                 (overlays-at (posn-point (event-start event))))))
     (when (or (member 'flyspell-incorrect faces-at-point)
               (member 'flyspell-duplicate faces-at-point))
       #'flyspell-correct-word))))

(defun poplife-context-menu (event)
  "Return key's definition depending on thing under mouse click EVENT.
Items in `poplife-menu-candidates' are examined sequentially.
See `define-key' for the key's definition"
  ;; ~/.emacs.d/init.el ~/.emacs.d/ https://www.gnu.org/software/emacs/
  (when (fboundp 'secondary-selection-to-region) ; 26.1
    (secondary-selection-to-region)) ; When there is only secondary, turn it to region.
  (let ((candidates poplife-menu-candidates)
        context-menu)
    (while (not context-menu)
      (let ((item (car candidates)))
        (setq candidates (cdr candidates))
        ;; See how dired-guess-shell-alist-user is used in dired-guess-default.
        (setq context-menu (cond ((fboundp item)
                                  (funcall item event))
                                 ((and (symbolp item)
                                       (keymapp (symbol-value item)))
                                  (symbol-value item))
                                 (t     ; else
                                  nil)))))
    context-menu))

Re: Context menus and mouse-3

[Stefan Monnier]

> The idea is to define a variable (something like below;
> poplife-menu-candidates) with list of functions that returns nil or
> keymap (something like below; poplife-mouse-word-menu).  A function
> (something like below; poplife-context-menu) will test each of them
> until it gets keymap.

Note: such a variable should have a name that ends in `-hook` or
`-functions` and should be manipulated with the usual hook functions,
e.g. `run-hook-wrapped`.

Note also that the `context-menu-function` already mentioned offers the
same kind of functionality (except you need to use `add-function`
instead of `add-hook` and it offers a bit more flexibility at the cost
of extra work).


        Stefan

Re: Context menus and mouse-3

[Juri Linkov]

>> The idea is to define a variable (something like below;
>> poplife-menu-candidates) with list of functions that returns nil or
>> keymap (something like below; poplife-mouse-word-menu).  A function
>> (something like below; poplife-context-menu) will test each of them
>> until it gets keymap.
>
> Note: such a variable should have a name that ends in `-hook` or
> `-functions` and should be manipulated with the usual hook functions,
> e.g. `run-hook-wrapped`.
>
> Note also that the `context-menu-function` already mentioned offers the
> same kind of functionality (except you need to use `add-function`
> instead of `add-hook` and it offers a bit more flexibility at the cost
> of extra work).

For easier customization, 'context-menu-functions' could be more hook-like,
so e.g. when the default value will be defined as

  (defcustom context-menu-functions '(context-menu-region)

then users could easily customize the default value.
More minor modes could add own functions to the global value, e.g.

  (add-hook 'context-menu-functions 'bug-reference-context-menu -5)
  (add-hook 'context-menu-functions 'goto-address-context-menu -10)

Major modes could modify buffer-local values:

  (add-hook 'context-menu-functions 'dired-context-menu nil t)
  (add-hook 'context-menu-functions 'info-context-menu -5 t)
  (add-hook 'context-menu-functions 'dictionary-context-menu -10 t)

Then the user could have the final say by using another option, e.g.

  (defcustom context-menu-filter nil

where a user-defined function (that can be extended using `add-function`)
will accept a menu constructed by context-menu-functions
and return the modified menu with reordered/removed/added items
to user's liking.

Re: Context menus and mouse-3

[Stefan Monnier]

> For easier customization, 'context-menu-functions' could be more hook-like,

FWIW, I originally thought of using a `-function` because I expect there
are situations where you'll want to override the normal menu with a more
specific one (rather than adding entries only), or move the normal
menu to a submenu.


        Stefan

Re: Context menus and mouse-3

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:
> IMO, it's not a good idea to use "modern" in variable names.
>
> Something like mouse-friendly-mode or alt-mouse-mode, maybe?

Sure, any of those would work.

I personally don't mind the word "modern" too much, as it signals
something along the lines of: "avoid this mostly if you are a veteran
user and are too used to the old way".  But I'm all in favour of
finding a better word than "modern" to describe the grab-bag of
features that some of us would like to see under the general umbrella
"making Emacs more similar to contemporary software [unless there is
good reason to be different]".

Re: Context menus and mouse-3

[Stefan Monnier]

Stefan Kangas [2021-07-19 19:48:21] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> IMO, it's not a good idea to use "modern" in variable names.
>> Something like mouse-friendly-mode or alt-mouse-mode, maybe?
> Sure, any of those would work.

To me none of them are any good, because the only useful word there is
`mouse` and it's still pretty vague.

AFAIK the first and most important element is to introduce the concept
of a "context menu" (via `content-menu-function` or something like that)
which modes can use to add there own entries.

Then as a second step comes the choice of how to give access to this
menu, and I wouldn't call that a "mode" because I can't see any reason
why it should be a binary choice.  This menu should be available by
default, the only user-config question is which key-binding(s) to use
for it (some of the choices being to override `down-mouse-3` (and hence
`mouse-3`), or to use `down-mouse-3` with a delay, ...).


        Stefan

Re: Context menus and mouse-3

[Ergus via Emacs development discussions.]

[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]

Hi Juri:

is there anything to test, a scratch o feature branch? I am very interested in this feature.

On July 19, 2021 5:55:57 PM GMT+02:00, Juri Linkov <juri@linkov.net> wrote:
>>> The idea is to define a variable (something like below;
>>> poplife-menu-candidates) with list of functions that returns nil or
>>> keymap (something like below; poplife-mouse-word-menu).  A function
>>> (something like below; poplife-context-menu) will test each of them
>>> until it gets keymap.
>>
>> Note: such a variable should have a name that ends in `-hook` or
>> `-functions` and should be manipulated with the usual hook functions,
>> e.g. `run-hook-wrapped`.
>>
>> Note also that the `context-menu-function` already mentioned offers
>the
>> same kind of functionality (except you need to use `add-function`
>> instead of `add-hook` and it offers a bit more flexibility at the
>cost
>> of extra work).
>
>For easier customization, 'context-menu-functions' could be more
>hook-like,
>so e.g. when the default value will be defined as
>
>  (defcustom context-menu-functions '(context-menu-region)
>
>then users could easily customize the default value.
>More minor modes could add own functions to the global value, e.g.
>
>  (add-hook 'context-menu-functions 'bug-reference-context-menu -5)
>  (add-hook 'context-menu-functions 'goto-address-context-menu -10)
>
>Major modes could modify buffer-local values:
>
>  (add-hook 'context-menu-functions 'dired-context-menu nil t)
>  (add-hook 'context-menu-functions 'info-context-menu -5 t)
>  (add-hook 'context-menu-functions 'dictionary-context-menu -10 t)
>
>Then the user could have the final say by using another option, e.g.
>
>  (defcustom context-menu-filter nil
>
>where a user-defined function (that can be extended using
>`add-function`)
>will accept a menu constructed by context-menu-functions
>and return the modified menu with reordered/removed/added items
>to user's liking.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 2585 bytes --]

Re: Context menus and mouse-3

[Juri Linkov]

> is there anything to test, a scratch o feature branch? I am very interested
> in this feature.

Now there is a new branch 'feature/context-menu'.
It provides a new mode 'context-menu-mode'
that binds the Context menu to [down-mouse-3].

For testing, it adds the Context menu to the major mode
Info-mode, so clicking anywhere in the Info buffer
pops up the navigation menu, and clicking on links
adds a menu item to open a link.

Also is adds the Context menu to one minor mode
goto-address-mode where clicking on an address
pops up a menu with an item to open that address.

Re: Context menus and mouse-3

[Juri Linkov]

>> For easier customization, 'context-menu-functions' could be more hook-like,
>
> FWIW, I originally thought of using a `-function` because I expect there
> are situations where you'll want to override the normal menu with a more
> specific one (rather than adding entries only), or move the normal
> menu to a submenu.

The new branch 'feature/context-menu' now includes also the variable
'context-menu-overriding-function' that can override the normal menu.

But I have no idea on which mode to test it.  It makes sense to
override the normal menu in modes that produce too long menus,
such as a long list of candidates in flyspell-mode.  But flyspell-mode
already overrides the menu with own [down-mouse-3], and rewriting it to
use context-menu-overriding-function might cause backward-incompatibility bugs.

Re: Context menus and mouse-3

[Stefan Monnier]

> such as a long list of candidates in flyspell-mode.  But flyspell-mode
> already overrides the menu with own [down-mouse-3], and rewriting it to
> use context-menu-overriding-function might cause backward-incompatibility bugs.

Yet, it is definitely one of the packages which should use context-menu.


        Stefan

Re: Context menus and mouse-3

[Juri Linkov]

>> such as a long list of candidates in flyspell-mode.  But flyspell-mode
>> already overrides the menu with own [down-mouse-3], and rewriting it to
>> use context-menu-overriding-function might cause backward-incompatibility bugs.
>
> Yet, it is definitely one of the packages which should use context-menu.

I realized now that context-menu-overriding-function is not needed
since it's possible just to reverse the priorities, so the
functions at the end of the list in context-menu-functions
will have higher priority.  Then for example, flyspell-context-menu
called as the last function can remove all items added by earlier calls
and return a new menu with only own items.

Re: Context menus and mouse-3

[Tak Kunihiro]

I think most of the time, a thing under mouse cursor matters for
context-menu instead of mode.

For example, when a thing under mouse cursor is with face
'flyspell-incorrect, it is nice to have 'flyspell-correct-word as shown
below.

(defun poplife-mouse-word-menu (event)
  "Return 'flyspell-correct-word when word under mouse cursor on EVENT is incorrect."
  (and
   (not (region-active-p))
   (let ((faces-at-point (mapcar (lambda (xxx) (overlay-get xxx 'face))
                                 (overlays-at (posn-point (event-start event))))))
     (when (or (member 'flyspell-incorrect faces-at-point)
               (member 'flyspell-duplicate faces-at-point))
       #'flyspell-correct-word))))

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

[Drew Adams]

> I think most of the time, a thing under mouse
> cursor matters for context-menu instead of mode.

Yes, I agree.  A mode can certainly do particular
things, i.e., have menu items specific to it.
But it should generally be possible to act on a
thing that's under the pointer.

(BTW, it's called the mouse "pointer", as opposed
to the text "cursor" - e.g. in the docs.)

That's why `mouse3.el' has this available in the
`mouse-3' menu by default when the region is not
active (when it's active you get a menu for acting
on the region).

There are several kinds of action, for several
kinds of thing, that you can choose from the menu.

By default there's a `Thing at Point' submenu
with items such as these (a given item is enabled
when there's a relevant thing under the pointer):

 _______________________________
 Open URL in Browser
 Visit File
 Visit File in Other Window
 Dired
 Dired in Other Window
 _______________________________
 Describe File
 Describe Function
 Show Code Defining Function
 Describe Variable
 Show Code Defining Variable
 Describe Face
 Describe Package
 Describe Text Properties
 _______________________________
 Highlight Symbol
 Unhighlight Symbol
 Hi-Lock Symbol
 Un-Hi-Lock Symbol
 _______________________________
 Look Up Symbol in Manual
 Search for Symbol
 Eval & Pretty-Print Lisp Sexp
 _______________________________

But of course this is just the default behavior.
A mode can define its own approach to the menu,
as can a user (by customizing).

If flyspell is available and turned on then you
could have an item for using it on the word under
the pointer, i.e., when the pointer is in fact
over a word.  (I didn't include that by default.)

Re: Context menus and mouse-3

[Stefan Monnier]

Tak Kunihiro [2021-07-21 13:39:30] wrote:
> I think most of the time, a thing under mouse cursor matters for
> context-menu instead of mode.

Obviously, but note that the code that decides what "thing under the
cursor" is relevant, and which menu entries should be shown for it is
most likely going to be provided by a mode.

So I guess what I'm saying is that I disagree with "instead of".


        Stefan

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

[Drew Adams]

> > I think most of the time, a thing under mouse cursor matters for
> > context-menu instead of mode.
> 
> Obviously, but note that the code that decides what "thing under the
> cursor" is relevant, and which menu entries should be shown for it is
> most likely going to be provided by a mode.
> 
> So I guess what I'm saying is that I disagree with "instead of".

Yes, fair enough.  Several things can be relevant to
determining what's in a "context" menu - including
modes, buffer text under the pointer, and properties
(text, overlay) under the pointer.

Anything having to do with current Emacs "state",
of any kind, can be considered behavioral "context".
Of course, context that is closely related to the
mouse-pointer state is particularly relevant.

It's not just modes.  It's not just text under the
mouse pointer.  It's not "instead of".  Right.
It's anything you (a user or code) want the menu
to be.

Re: Context menus and mouse-3

[Tak Kunihiro]

>>> I think most of the time, a thing under mouse cursor matters for
>>> context-menu instead of mode.
>> 
>> Obviously, but note that the code that decides what "thing under the
>> cursor" is relevant, and which menu entries should be shown for it is
>> most likely going to be provided by a mode.
>> 
>> So I guess what I'm saying is that I disagree with "instead of".
> 
> It's not just modes.  It's not just text under the
> mouse pointer.  It's not "instead of".  Right.
> It's anything you (a user or code) want the menu
> to be.

I think operation double click on icon in file browser is a good
analogue to operation via context menu.

Double click opens an icon.
I think by default, context menu should provide a way to open a
thing under mouse pointer.

What is appropriate open, isn’t obvious.

| thing     | open          |
|-----------+---------------|
| file      | file-file     |
| directory | dired         |
| url       | browse-url    |
| function  | describe-help |

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

[Drew Adams]

> I think operation double click on icon in file browser is a good
> analogue to operation via context menu.
> 
> Double click opens an icon.
> I think by default, context menu should provide a way to open a
> thing under mouse pointer.
> 
> What is appropriate open, isn’t obvious.
> 
> | thing     | open          |
> |-----------+---------------|
> | file      | file-file     |
> | directory | dired         |
> | url       | browse-url    |
> | function  | describe-help |

Not just "open", however that operation might be
defined for a given kind of thing under the mouse
pointer.  That is, there need not be just one
appropriate action for a given thing.

A double-click is associated with only a _single_
action (unless combined with modifier keys).

Here we're talking about a _menu_, which means a
number of choices.  Including possibly multiple
choices for the same type of thing.

I gave several examples from the `mouse3.el' menu.
E.g. 4 actions for a symbol pointed to, 2 actions
each for a function or variable name pointed to.

The possibilities are endless.  Which is another
reason to allow both programmatic and user control
over the menu in any given context.