New Context Menu

New Context Menu

[Ergus]

Hi:

I just tested the new context menu... It is very nice!! thanks Juri!!

I have a couple of small issues that maybe you could help to face. When
using emacs on xterm the interaction with the menu is a bit
uncomfortable (like in X11... I know we xterm users don't use the mouse
too much, but if it is not too complex maybe it may worth to add it at
least as an option).

The current implementation follows the X11 menu interaction pattern:
Hold mouse-3 to keep the menu active and release mouse-3 to select an
entry.

Could we add an option to avoid this and have the same interaction
behavior than in gui please?: mouse-3 activates the menu, a click over
an option selects it and a click outside the menu hides the menu

I know this may be something external to emacs itself; maybe it is how
xterm menu behaves, but probably there is a way to go around this
without excessive complexity.

Maybe this is ask for too much, but I am wondering that once the context
menu will be released with emacs 28, then a lot of packages will try to
implement such a functionality in a hacky way with advises/hooks and so
on and they won't get properly maintained.

The other "issue" is maybe more a question:

In case the user wants to bind the context menu without using the mouse
how can be done? Will the context-menu appear in the current cursor
(point) or in the current mouse arrow position?

I know the context menu without mouse is a bit pointless; but for new
users it may be very useful to not feel lost when starting (like exiting
vim ;p)

Thanks in advance,
Ergus.

Re: New Context Menu

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 14:08:34 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Juri Linkov <juri@linkov.net>
> 
> The current implementation follows the X11 menu interaction pattern:
> Hold mouse-3 to keep the menu active and release mouse-3 to select an
> entry.
> 
> Could we add an option to avoid this and have the same interaction
> behavior than in gui please?: mouse-3 activates the menu, a click over
> an option selects it and a click outside the menu hides the menu
> 
> I know this may be something external to emacs itself; maybe it is how
> xterm menu behaves, but probably there is a way to go around this
> without excessive complexity.

I'm quite sure it's how the mouse support behaves, and has nothing to
do with what Juri did.  You should see the same behavior in any menu
on that display.

It works for me as you expect on the w32 console.

> Maybe this is ask for too much, but I am wondering that once the context
> menu will be released with emacs 28, then a lot of packages will try to
> implement such a functionality in a hacky way with advises/hooks and so
> on and they won't get properly maintained.

I don't see how this can be worked around in a hook, because TTY menus
are implemented entirely in C.

> In case the user wants to bind the context menu without using the mouse
> how can be done? Will the context-menu appear in the current cursor
> (point) or in the current mouse arrow position?

We could do something similar to what we do when the user presses F10
on a TTY frame.

> I know the context menu without mouse is a bit pointless

Why pointless? menus work on TTY frames without a mouse just fine, you
can move and select using the keyboard.

Re: New Context Menu

[Ergus]

On Wed, Aug 18, 2021 at 03:26:51PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 18 Aug 2021 14:08:34 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Juri Linkov <juri@linkov.net>
>>
>> The current implementation follows the X11 menu interaction pattern:
>> Hold mouse-3 to keep the menu active and release mouse-3 to select an
>> entry.
>>
>> Could we add an option to avoid this and have the same interaction
>> behavior than in gui please?: mouse-3 activates the menu, a click over
>> an option selects it and a click outside the menu hides the menu
>>
>> I know this may be something external to emacs itself; maybe it is how
>> xterm menu behaves, but probably there is a way to go around this
>> without excessive complexity.
>
>I'm quite sure it's how the mouse support behaves, and has nothing to
>do with what Juri did.  You should see the same behavior in any menu
>on that display.
>
>It works for me as you expect on the w32 console.
>
:( I supposed that. It will be hard to have such a functionality in
xterm then. And no other terminal works completely fine with emacs for
me.

>> Maybe this is ask for too much, but I am wondering that once the context
>> menu will be released with emacs 28, then a lot of packages will try to
>> implement such a functionality in a hacky way with advises/hooks and so
>> on and they won't get properly maintained.
>
>I don't see how this can be worked around in a hook, because TTY menus
>are implemented entirely in C.
>
Users and external developers may try their best it this annoys them
enough.

>> In case the user wants to bind the context menu without using the mouse
>> how can be done? Will the context-menu appear in the current cursor
>> (point) or in the current mouse arrow position?
>
>We could do something similar to what we do when the user presses F10
>on a TTY frame.
>
On tty the F10 menu opens in the minibuffer. It would be better if we
can just show the same menu than with the mouse instead, because it
appears in place, closer to where the user is editing. And the
experience is a bit more consistent IMHO.

>> I know the context menu without mouse is a bit pointless
>
>Why pointless? menus work on TTY frames without a mouse just fine, you
>can move and select using the keyboard.
>
But context menu it more mouse-oriented in general because it is a need
specially for more mouse oriented users. Why to do something like F10 +
arrow + arrow + Enter: when you can do just M-w? Or why to use arrows if
just used the mouse to activate the menu?

Re: New Context Menu

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 14:43:09 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> >> Maybe this is ask for too much, but I am wondering that once the context
> >> menu will be released with emacs 28, then a lot of packages will try to
> >> implement such a functionality in a hacky way with advises/hooks and so
> >> on and they won't get properly maintained.
> >
> >I don't see how this can be worked around in a hook, because TTY menus
> >are implemented entirely in C.
> >
> Users and external developers may try their best it this annoys them
> enough.

Yes, but there are limits to that.  Like the speed of light, for
example.

> >> In case the user wants to bind the context menu without using the mouse
> >> how can be done? Will the context-menu appear in the current cursor
> >> (point) or in the current mouse arrow position?
> >
> >We could do something similar to what we do when the user presses F10
> >on a TTY frame.
> >
> On tty the F10 menu opens in the minibuffer.

??? It does not!  I just tried.  Are you trying in "emacs -Q"?

> It would be better if we can just show the same menu than with the
> mouse instead

That's what F10 is supposed to do.

> because it appears in place, closer to where the user is editing.

If you want the menu to be dropped close to point, you need to tell
the menu code where that is, it by default expects to get that from
the event which triggered it, and that only works with mouse clicks,
not with keyboard keys.  In the implementation of F10, we use some
trick to do something similar, but since that opens the menu-bar menu,
the location of point is not very relevant, so we use something else.

> >> I know the context menu without mouse is a bit pointless
> >
> >Why pointless? menus work on TTY frames without a mouse just fine, you
> >can move and select using the keyboard.
> >
> But context menu it more mouse-oriented in general because it is a need
> specially for more mouse oriented users. Why to do something like F10 +
> arrow + arrow + Enter: when you can do just M-w?

Because menus are self-explanatory, whereas M-w requires that you
remember it?

> Or why to use arrows if just used the mouse to activate the menu?

Because you don't have a mouse to begin with? or because you don't
want to move your fingers from the keyboard?  The usual reasons, IOW.

Re: New Context Menu

[Ergus]

On Wed, Aug 18, 2021 at 04:30:37PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 18 Aug 2021 14:43:09 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> >> Maybe this is ask for too much, but I am wondering that once the context
>> >> menu will be released with emacs 28, then a lot of packages will try to
>> >> implement such a functionality in a hacky way with advises/hooks and so
>> >> on and they won't get properly maintained.
>> >
>> >I don't see how this can be worked around in a hook, because TTY menus
>> >are implemented entirely in C.
>> >
>> Users and external developers may try their best it this annoys them
>> enough.
>
>Yes, but there are limits to that.  Like the speed of light, for
>example.
>
>> >> In case the user wants to bind the context menu without using the mouse
>> >> how can be done? Will the context-menu appear in the current cursor
>> >> (point) or in the current mouse arrow position?
>> >
>> >We could do something similar to what we do when the user presses F10
>> >on a TTY frame.
>> >
>> On tty the F10 menu opens in the minibuffer.
>
>??? It does not!  I just tried.  Are you trying in "emacs -Q"?
>
>> It would be better if we can just show the same menu than with the
>> mouse instead
>
>That's what F10 is supposed to do.

Ahh sorry, I tried that from a real TTY ;). Now I get your point. Yes,
that's what I want.
>
>> because it appears in place, closer to where the user is editing.
>
>If you want the menu to be dropped close to point, you need to tell
>the menu code where that is, it by default expects to get that from
>the event which triggered it, and that only works with mouse clicks,
>not with keyboard keys.  In the implementation of F10, we use some
>trick to do something similar, but since that opens the menu-bar menu,
>the location of point is not very relevant, so we use something else.
>

Passing the point location shouldn't be too hard; maybe it only requires
an extra condition when the "event" is not a "mouse event" use the point
location. On tty some time ago that was an issue because the menu used
to open always in the middle... but now it is fixed.

>> >> I know the context menu without mouse is a bit pointless
>> >
>> >Why pointless? menus work on TTY frames without a mouse just fine, you
>> >can move and select using the keyboard.
>> >
>> But context menu it more mouse-oriented in general because it is a need
>> specially for more mouse oriented users. Why to do something like F10 +
>> arrow + arrow + Enter: when you can do just M-w?
>
>Because menus are self-explanatory, whereas M-w requires that you
>remember it?
>
>> Or why to use arrows if just used the mouse to activate the menu?
>
>Because you don't have a mouse to begin with? or because you don't
>want to move your fingers from the keyboard?  The usual reasons, IOW.
>

Re: New Context Menu

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 19:17:53 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org, juri@linkov.net
> 
> >> On tty the F10 menu opens in the minibuffer.
> >
> >??? It does not!  I just tried.  Are you trying in "emacs -Q"?
> >
> >> It would be better if we can just show the same menu than with the
> >> mouse instead
> >
> >That's what F10 is supposed to do.
> 
> Ahh sorry, I tried that from a real TTY ;). Now I get your point. Yes,
> that's what I want.

Not sure what you mean by "real TTY".  F10 should work on any TTY,
whether real or emulated.

Re: New Context Menu

[Ergus]

On Wed, Aug 18, 2021 at 08:21:25PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 18 Aug 2021 19:17:53 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org, juri@linkov.net
>>
>> >> On tty the F10 menu opens in the minibuffer.
>> >
>> >??? It does not!  I just tried.  Are you trying in "emacs -Q"?
>> >
>> >> It would be better if we can just show the same menu than with the
>> >> mouse instead
>> >
>> >That's what F10 is supposed to do.
>>
>> Ahh sorry, I tried that from a real TTY ;). Now I get your point. Yes,
>> that's what I want.
>
>Not sure what you mean by "real TTY".  F10 should work on any TTY,
>whether real or emulated.

My bad, sorry. I had the menu bar disabled.

Re: New Context Menu

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 14:43:09 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> >> Could we add an option to avoid this and have the same interaction
> >> behavior than in gui please?: mouse-3 activates the menu, a click over
> >> an option selects it and a click outside the menu hides the menu
> >>
> >> I know this may be something external to emacs itself; maybe it is how
> >> xterm menu behaves, but probably there is a way to go around this
> >> without excessive complexity.
> >
> >I'm quite sure it's how the mouse support behaves, and has nothing to
> >do with what Juri did.  You should see the same behavior in any menu
> >on that display.
> >
> >It works for me as you expect on the w32 console.
> >
> :( I supposed that. It will be hard to have such a functionality in
> xterm then. And no other terminal works completely fine with emacs for
> me.

Actually, I take that back.  The reason for what you see is that the
menu is popped by down-mouse-3, not by mouse-3.  So if we can arrange
for optionally doing this with mouse-3 (why isn't that the default,
btw?), or if you could do that in your customizations, you should be
able to have the behavior you want.

Re: New Context Menu

[Ergus]

On Wed, Aug 18, 2021 at 07:50:42PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 18 Aug 2021 14:43:09 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> >> Could we add an option to avoid this and have the same interaction
>> >> behavior than in gui please?: mouse-3 activates the menu, a click over
>> >> an option selects it and a click outside the menu hides the menu
>> >>
>> >> I know this may be something external to emacs itself; maybe it is how
>> >> xterm menu behaves, but probably there is a way to go around this
>> >> without excessive complexity.
>> >
>> >I'm quite sure it's how the mouse support behaves, and has nothing to
>> >do with what Juri did.  You should see the same behavior in any menu
>> >on that display.
>> >
>> >It works for me as you expect on the w32 console.
>> >
>> :( I supposed that. It will be hard to have such a functionality in
>> xterm then. And no other terminal works completely fine with emacs for
>> me.
>
>Actually, I take that back.  The reason for what you see is that the
>menu is popped by down-mouse-3, not by mouse-3.  So if we can arrange
>for optionally doing this with mouse-3 (why isn't that the default,
>btw?), or if you could do that in your customizations, you should be
>able to have the behavior you want.
>
Indeed, I tried that and it works!

Something as simple as:

(global-unset-key [down-mouse-3])
(global-set-key [mouse-3] context-menu-entry)

seems to work; but maybe Juri made the other one the default for some
reason.

Any way I agree that this behavior is more comfortable and probably
should be the default. But at least this needs a custom or to be
documented for new users.

I would do something more or less like:

(defcustom context-menu-mode-binding [down-mouse-3]
            "BLABLA")

(...)
(context-menu-mode
     (setq context-menu--old-mouse-3 (global-key-binding [mouse-3]))
     (setq context-menu--old-down-mouse-3 (global-key-binding [down-mouse-3]))
     (global-unset-key [mouse-3])
     (global-unset-key [down-mouse-3])
     (global-set-key context-menu-mode-binding context-menu-entry))

Apart from that, there is another issue with the "Paste" command in tty.

Paste calls mouse-yank-primary, but in tty this commands calls
gui-get-primary-selection and there is no selection because it tries to
get the one on the primary selection not the one in the system
(secoundary or clipboard) not the emacs kill-ring either.

So I get: error("No selection is available")

Re: New Context Menu

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 20:10:52 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org, juri@linkov.net
> 
> >Actually, I take that back.  The reason for what you see is that the
> >menu is popped by down-mouse-3, not by mouse-3.  So if we can arrange
> >for optionally doing this with mouse-3 (why isn't that the default,
> >btw?), or if you could do that in your customizations, you should be
> >able to have the behavior you want.
> >
> Indeed, I tried that and it works!
> 
> Something as simple as:
> 
> (global-unset-key [down-mouse-3])
> (global-set-key [mouse-3] context-menu-entry)
> 
> seems to work; but maybe Juri made the other one the default for some
> reason.

Juri?

> Apart from that, there is another issue with the "Paste" command in tty.
> 
> Paste calls mouse-yank-primary, but in tty this commands calls
> gui-get-primary-selection and there is no selection because it tries to
> get the one on the primary selection not the one in the system
> (secoundary or clipboard) not the emacs kill-ring either.
> 
> So I get: error("No selection is available")

Which is the correct response.  If you run on an xterm that supports
pasting, you will get the result as on GUI frames.  Why is this a
problem?

And how do you get "Paste" in the context menu, btw?

Re: New Context Menu

[Ergus]

On Wed, Aug 18, 2021 at 09:17:04PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 18 Aug 2021 20:10:52 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org, juri@linkov.net
>>
>> >Actually, I take that back.  The reason for what you see is that the
>> >menu is popped by down-mouse-3, not by mouse-3.  So if we can arrange
>> >for optionally doing this with mouse-3 (why isn't that the default,
>> >btw?), or if you could do that in your customizations, you should be
>> >able to have the behavior you want.
>> >
>> Indeed, I tried that and it works!
>>
>> Something as simple as:
>>
>> (global-unset-key [down-mouse-3])
>> (global-set-key [mouse-3] context-menu-entry)
>>
>> seems to work; but maybe Juri made the other one the default for some
>> reason.
>
>Juri?
>
>> Apart from that, there is another issue with the "Paste" command in tty.
>>
>> Paste calls mouse-yank-primary, but in tty this commands calls
>> gui-get-primary-selection and there is no selection because it tries to
>> get the one on the primary selection not the one in the system
>> (secoundary or clipboard) not the emacs kill-ring either.
>>
>> So I get: error("No selection is available")
>
>Which is the correct response.  If you run on an xterm that supports
>pasting, you will get the result as on GUI frames.  Why is this a
>problem?
>
If within Emacs I "Copy" throw context-menu, then I expect I could paste
the copied thing in the same way. I expect C-y not <mouse-2> action.

And if I copy from the browser, the context's menu paste must do the
same and take it from the clipboard right? That's what a normal "Paste"
do.

In my case I use the xclip.el package from Stefan, so, everything could
go throw Yank in my case. But that's a different beast.

>And how do you get "Paste" in the context menu, btw?

It is just there... what do you mean?

Re: New Context Menu

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 21:23:18 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org, juri@linkov.net
> 
> >And how do you get "Paste" in the context menu, btw?
> 
> It is just there... what do you mean?

That means your configuration should support pasting.  Or maybe
there's a bug in the condition, see mouse.el around line 400.  I don't
see "Paste" in the menu when I start a -nw session.

Re: New Context Menu

[Ergus]

On Wed, Aug 18, 2021 at 10:28:53PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 18 Aug 2021 21:23:18 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org, juri@linkov.net
>>
>> >And how do you get "Paste" in the context menu, btw?
>>
>> It is just there... what do you mean?
>
>That means your configuration should support pasting.  Or maybe
>there's a bug in the condition, see mouse.el around line 400.  I don't
>see "Paste" in the menu when I start a -nw session.

Once you Copy (or kill) at least once (Either with the menu or with
M-w); then the "Paste" appears in the menu automatically the next time
you press mouse-3...

The problem is that such "Paste" does not Paste but returns the error I
mentioned.

I am with emacs -Q -nw.

Re: New Context Menu

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 21:53:53 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org, juri@linkov.net
> 
> Once you Copy (or kill) at least once (Either with the menu or with
> M-w); then the "Paste" appears in the menu automatically the next time
> you press mouse-3...

Yes.  And that's what I was missing (you said "it's just there", which
it isn't immediately after entering Emacs).

> The problem is that such "Paste" does not Paste but returns the error I
> mentioned.

More accurately, the "Paste" menu item appears as soon as there's
something on the kill-ring, but "Paste" doesn't yank that something,
instead signaling an error because there's no selection.

Juri, could you please look into this?

Re: New Context Menu

[Juri Linkov]

>> Once you Copy (or kill) at least once (Either with the menu or with
>> M-w); then the "Paste" appears in the menu automatically the next time
>> you press mouse-3...
>
> Yes.  And that's what I was missing (you said "it's just there", which
> it isn't immediately after entering Emacs).
>
>> The problem is that such "Paste" does not Paste but returns the error I
>> mentioned.
>
> More accurately, the "Paste" menu item appears as soon as there's
> something on the kill-ring, but "Paste" doesn't yank that something,
> instead signaling an error because there's no selection.

Probably it should be replaced with:

diff --git a/lisp/mouse.el b/lisp/mouse.el
index d2a5200d8d..c071fdefac 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -396,7 +396,7 @@ context-menu-region
                            "\\[ns-copy-including-secondary]"
                          "\\[kill-ring-save]")))
   (define-key-after menu [paste]
-    `(menu-item "Paste" mouse-yank-primary
+    `(menu-item "Paste" mouse-yank-at-click
                 :visible (funcall
                           ',(lambda ()
                               (and (or

Re: New Context Menu

[Eli Zaretskii]

> Date: Wed, 18 Aug 2021 21:23:18 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org, juri@linkov.net
> 
> >> Paste calls mouse-yank-primary, but in tty this commands calls
> >> gui-get-primary-selection and there is no selection because it tries to
> >> get the one on the primary selection not the one in the system
> >> (secoundary or clipboard) not the emacs kill-ring either.
> >>
> >> So I get: error("No selection is available")
> >
> >Which is the correct response.  If you run on an xterm that supports
> >pasting, you will get the result as on GUI frames.  Why is this a
> >problem?
> >
> If within Emacs I "Copy" throw context-menu, then I expect I could paste
> the copied thing in the same way. I expect C-y not <mouse-2> action.
> 
> And if I copy from the browser, the context's menu paste must do the
> same and take it from the clipboard right? That's what a normal "Paste"
> do.
> 
> In my case I use the xclip.el package from Stefan, so, everything could
> go throw Yank in my case. But that's a different beast.
> 
> >And how do you get "Paste" in the context menu, btw?
> 
> It is just there... what do you mean?

Ahh, I see now.  Yes, it's wrong to call mouse-yank-primary here, as
that doesn't work on TTY frames.  We should have a wrapper function
that calls yank if the selection doesn't exist.

Re: New Context Menu

[Juri Linkov]

>> :( I supposed that. It will be hard to have such a functionality in
>> xterm then. And no other terminal works completely fine with emacs for
>> me.
>
> Actually, I take that back.  The reason for what you see is that the
> menu is popped by down-mouse-3, not by mouse-3.  So if we can arrange
> for optionally doing this with mouse-3 (why isn't that the default,
> btw?), or if you could do that in your customizations, you should be
> able to have the behavior you want.

down-mouse-3 is used for convenience - you need only one click
to select a menu item, not two.  And removing the menu title has
the advantage of reducing distraction.

Re: New Context Menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Ergus <spacibba@aol.com>,  emacs-devel@gnu.org
> Date: Wed, 18 Aug 2021 21:58:09 +0300
> 
> > Actually, I take that back.  The reason for what you see is that the
> > menu is popped by down-mouse-3, not by mouse-3.  So if we can arrange
> > for optionally doing this with mouse-3 (why isn't that the default,
> > btw?), or if you could do that in your customizations, you should be
> > able to have the behavior you want.
> 
> down-mouse-3 is used for convenience - you need only one click
> to select a menu item, not two.

But that's different from other popup menus, for example C-mouse-3 and
mouse-1 or mouse-3 on the mode-line's major/minor mode parts.

> And removing the menu title has the advantage of reducing
> distraction.

Is this related to the douwn-mouse-3 vs mouse-3 issue?

Re: New Context Menu

[Juri Linkov]

>> down-mouse-3 is used for convenience - you need only one click
>> to select a menu item, not two.
>
> But that's different from other popup menus, for example C-mouse-3 and
> mouse-1 or mouse-3 on the mode-line's major/minor mode parts.

All menus were always bound to down-events
C-down-mouse-1, S-down-mouse-1, C-down-mouse-2, C-down-mouse-3:

  (global-set-key [C-down-mouse-1] 'mouse-buffer-menu)
  (if (not (eq system-type 'ms-dos))
      (global-set-key [S-down-mouse-1] 'mouse-appearance-menu))
  ;; C-down-mouse-2 is bound in facemenu.el.
  (global-set-key [C-down-mouse-3]
    `(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)))))

Re: New Context Menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Thu, 19 Aug 2021 10:05:12 +0300
> 
> >> down-mouse-3 is used for convenience - you need only one click
> >> to select a menu item, not two.
> >
> > But that's different from other popup menus, for example C-mouse-3 and
> > mouse-1 or mouse-3 on the mode-line's major/minor mode parts.
> 
> All menus were always bound to down-events
> C-down-mouse-1, S-down-mouse-1, C-down-mouse-2, C-down-mouse-3:

I'm talking about the _behavior_, not about the bindings.  The
behavior in the other cases is that releasing the mouse button doesn't
pop down the menu in the other cases; with context menus, it does.
That is sub-optimal UI, as users who don't expect that will see the
menu flash momentarily and disappear, at least on TTY frames.  We
should fix this so the context menus behave like the other drop-down
menus we have.

Re: New Context Menu

[Juri Linkov]

>> All menus were always bound to down-events
>> C-down-mouse-1, S-down-mouse-1, C-down-mouse-2, C-down-mouse-3:
>
> I'm talking about the _behavior_, not about the bindings.  The
> behavior in the other cases is that releasing the mouse button doesn't
> pop down the menu in the other cases; with context menus, it does.
> That is sub-optimal UI, as users who don't expect that will see the
> menu flash momentarily and disappear, at least on TTY frames.  We
> should fix this so the context menus behave like the other drop-down
> menus we have.

I don't understand how the behavior of the context menu could be
different from the behavior of the old binding [C-down-mouse-3]
when both have the same implementation.  Does it pop down for you
if you click [C-down-mouse-3] that displays the local/global menu?

Re: New Context Menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Fri, 20 Aug 2021 10:13:59 +0300
> 
> > I'm talking about the _behavior_, not about the bindings.  The
> > behavior in the other cases is that releasing the mouse button doesn't
> > pop down the menu in the other cases; with context menus, it does.
> > That is sub-optimal UI, as users who don't expect that will see the
> > menu flash momentarily and disappear, at least on TTY frames.  We
> > should fix this so the context menus behave like the other drop-down
> > menus we have.
> 
> I don't understand how the behavior of the context menu could be
> different from the behavior of the old binding [C-down-mouse-3]
> when both have the same implementation.

I cannot say I understand that in detail, either, but the fact is it
does.  Maybe it's translation from C-down-mouse-3 to C-mouse-3?

> Does it pop down for you if you click [C-down-mouse-3] that displays
> the local/global menu?

No.  When I release the mouse button after clicking C-mouse-3, the
menu stays displayed until I select a menu item (or dismiss the menu
with the likes of C-g).

Re: New Context Menu

[Eli Zaretskii]

> Date: Fri, 20 Aug 2021 14:26:08 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: spacibba@aol.com, emacs-devel@gnu.org
> 
> > Does it pop down for you if you click [C-down-mouse-3] that displays
> > the local/global menu?
> 
> No.  When I release the mouse button after clicking C-mouse-3, the
> menu stays displayed until I select a menu item (or dismiss the menu
> with the likes of C-g).

Btw, something's changed in this regard since Emacs 27.2.  In Emacs
27, mouse-1 and mouse-3 on the mode-line's major and minor mode names
pop up a menu that stays displayed when I release the mouse button.
In Emacs 28, these two menus pop down when the button is released.  By
contrast, C-mouse-3 in *scratch* pops up a menu that doesn't pop down
when I release the button even in Emacs 28.

I guess this has something to do with the bindings of down-mouse-N vs
mouse-N, and the fact that Emacs ignores the down- events when they
are not bound?

Re: New Context Menu

[Juri Linkov]

>> > Does it pop down for you if you click [C-down-mouse-3] that displays
>> > the local/global menu?
>> 
>> No.  When I release the mouse button after clicking C-mouse-3, the
>> menu stays displayed until I select a menu item (or dismiss the menu
>> with the likes of C-g).
>
> Btw, something's changed in this regard since Emacs 27.2.  In Emacs
> 27, mouse-1 and mouse-3 on the mode-line's major and minor mode names
> pop up a menu that stays displayed when I release the mouse button.
> In Emacs 28, these two menus pop down when the button is released.  By
> contrast, C-mouse-3 in *scratch* pops up a menu that doesn't pop down
> when I release the button even in Emacs 28.
>
> I guess this has something to do with the bindings of down-mouse-N vs
> mouse-N, and the fact that Emacs ignores the down- events when they
> are not bound?

There is a bug in xterm handling code, but I don't know exactly where.

Re: New Context Menu

[Ergus]

On Fri, Aug 20, 2021 at 02:26:08PM +0300, Eli Zaretskii wrote:
>> From: Juri Linkov <juri@linkov.net>
>> Cc: spacibba@aol.com,  emacs-devel@gnu.org
>> Date: Fri, 20 Aug 2021 10:13:59 +0300
>>
>> > I'm talking about the _behavior_, not about the bindings.  The
>> > behavior in the other cases is that releasing the mouse button doesn't
>> > pop down the menu in the other cases; with context menus, it does.
>> > That is sub-optimal UI, as users who don't expect that will see the
>> > menu flash momentarily and disappear, at least on TTY frames.  We
>> > should fix this so the context menus behave like the other drop-down
>> > menus we have.
>>
>> I don't understand how the behavior of the context menu could be
>> different from the behavior of the old binding [C-down-mouse-3]
>> when both have the same implementation.
>
>I cannot say I understand that in detail, either, but the fact is it
>does.  Maybe it's translation from C-down-mouse-3 to C-mouse-3?
>
No. C-down-mouse-3 is a modified mouse event; emacs gets it but not the
equivalent up events (C-up-mouse-3 for example) but it gets somehow the
up-mouse-3 event.

For example:

Try C-down-mouse-3 then Release Control and after that release the mouse
button. You will see a similar issue.

>> Does it pop down for you if you click [C-down-mouse-3] that displays
>> the local/global menu?
>
>No.  When I release the mouse button after clicking C-mouse-3, the
>menu stays displayed until I select a menu item (or dismiss the menu
>with the likes of C-g).

Re: New Context Menu

[Eli Zaretskii]

> Date: Fri, 20 Aug 2021 14:26:05 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Juri Linkov <juri@linkov.net>, emacs-devel@gnu.org
> 
> >> I don't understand how the behavior of the context menu could be
> >> different from the behavior of the old binding [C-down-mouse-3]
> >> when both have the same implementation.
> >
> >I cannot say I understand that in detail, either, but the fact is it
> >does.  Maybe it's translation from C-down-mouse-3 to C-mouse-3?
> >
> No. C-down-mouse-3 is a modified mouse event; emacs gets it but not the
> equivalent up events (C-up-mouse-3 for example) but it gets somehow the
> up-mouse-3 event.

There's no up-mouse-N events in Emacs, AFAIK.  There's only
down-mouse-N events and mouse-N events; the latter are generated when
Emacs internally sees the Nth button pressed and released.

> For example:
> 
> Try C-down-mouse-3 then Release Control and after that release the mouse
> button. You will see a similar issue.

What issue is that?

When you do what you describe, Emacs doesn't generate the C-mouse-3
event because it never sees the button released with the Ctrl
modifier.  This is expected and documented.

Re: New Context Menu

[Ergus]

On Fri, Aug 20, 2021 at 03:36:33PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 20 Aug 2021 14:26:05 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Juri Linkov <juri@linkov.net>, emacs-devel@gnu.org
>>
>> >> I don't understand how the behavior of the context menu could be
>> >> different from the behavior of the old binding [C-down-mouse-3]
>> >> when both have the same implementation.
>> >
>> >I cannot say I understand that in detail, either, but the fact is it
>> >does.  Maybe it's translation from C-down-mouse-3 to C-mouse-3?
>> >
>> No. C-down-mouse-3 is a modified mouse event; emacs gets it but not the
>> equivalent up events (C-up-mouse-3 for example) but it gets somehow the
>> up-mouse-3 event.
>
>There's no up-mouse-N events in Emacs, AFAIK.  There's only
>down-mouse-N events and mouse-N events; the latter are generated when
>Emacs internally sees the Nth button pressed and released.
>
>> For example:
>>
>> Try C-down-mouse-3 then Release Control and after that release the mouse
>> button. You will see a similar issue.
>
>What issue is that?
>
>When you do what you describe, Emacs doesn't generate the C-mouse-3
>event because it never sees the button released with the Ctrl
>modifier.  This is expected and documented.

I know. But this is actually why menus behaves as Juri says with
C-down-mouse-3 but not with down-mouse-3.

Releasing the mouse button with Control hold seems not to generate any
event. While releasing it without holding control generates an event.

You can also see that in the menu, if you release the mouse button while
control is hold, the current item is not selected. But with context menu
when we release the mouse button the current item is actually selected
because control is not hold.

Re: New Context Menu

[Ergus]

On Fri, Aug 20, 2021 at 03:36:33PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 20 Aug 2021 14:26:05 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Juri Linkov <juri@linkov.net>, emacs-devel@gnu.org
>>
>> >> I don't understand how the behavior of the context menu could be
>> >> different from the behavior of the old binding [C-down-mouse-3]
>> >> when both have the same implementation.
>> >
>> >I cannot say I understand that in detail, either, but the fact is it
>> >does.  Maybe it's translation from C-down-mouse-3 to C-mouse-3?
>> >
>> No. C-down-mouse-3 is a modified mouse event; emacs gets it but not the
>> equivalent up events (C-up-mouse-3 for example) but it gets somehow the
>> up-mouse-3 event.
>
>There's no up-mouse-N events in Emacs, AFAIK.  There's only
>down-mouse-N events and mouse-N events; the latter are generated when
>Emacs internally sees the Nth button pressed and released.
>
Maybe the problem is that mouse-N events are generated when we release
the mouse-N key. But no C-mouse-N event is generated when Control is
hold and mouse-N key released.

If this is intended, then it is the reason why the context-menu behavior
is different than other menus bound to modified mouse events.

>> For example:
>>
>> Try C-down-mouse-3 then Release Control and after that release the mouse
>> button. You will see a similar issue.
>
>What issue is that?
>
>When you do what you describe, Emacs doesn't generate the C-mouse-3
>event because it never sees the button released with the Ctrl
>modifier.  This is expected and documented.
>

Re: New Context Menu

[Eli Zaretskii]

> Date: Fri, 20 Aug 2021 15:03:04 +0200
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org, juri@linkov.net
> 
> Maybe the problem is that mouse-N events are generated when we release
> the mouse-N key. But no C-mouse-N event is generated when Control is
> hold and mouse-N key released.

I don't think this is true.

> If this is intended, then it is the reason why the context-menu behavior
> is different than other menus bound to modified mouse events.

Are the bindings near the end of menu-bar.el relevant to this?

Re: New Context Menu

[Ergus]

On Fri, Aug 20, 2021 at 04:34:08PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 20 Aug 2021 15:03:04 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org, juri@linkov.net
>>
>> Maybe the problem is that mouse-N events are generated when we release
>> the mouse-N key. But no C-mouse-N event is generated when Control is
>> hold and mouse-N key released.
>
>I don't think this is true.
>
If I do:

C-h k and press mouse-1

It shows 2 events:

There were several key-sequences:

   <down-mouse-1> at that spot runs the command mouse-drag-region
   <mouse-1> at that spot runs the command mouse-set-point


But:

C-h k and press Control + mouse1

I only get:

C-<down-mouse-1> at that spot runs the command mouse-buffer-menu
(found in global-map), which is an interactive native compiled Lisp
function in ‘mouse.el’.

It is bound to C-<down-mouse-1>.

(mouse-buffer-menu EVENT)

There is not such event like C-<mouse-1>

So this is actually the issue.

>> If this is intended, then it is the reason why the context-menu behavior
>> is different than other menus bound to modified mouse events.
>
>Are the bindings near the end of menu-bar.el relevant to this?
>

Maybe.

There are mouse-X down-mouse-X S-mouse-X S-drag-mouse-X and
C-down-mouse-X. But not any C-mouse-X

So maybe this explains what I described above.

Re: New Context Menu

[Eli Zaretskii]

> Date: Fri, 20 Aug 2021 19:36:37 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> >> Maybe the problem is that mouse-N events are generated when we release
> >> the mouse-N key. But no C-mouse-N event is generated when Control is
> >> hold and mouse-N key released.
> >
> >I don't think this is true.
> >
> If I do:
> 
> C-h k and press mouse-1

With what toolkit? or was this on a TTY frame?  The exact behavior
depends on the internal details of how mouse clicks in menus are
handled by the toolkit.  It is not something that is the same across
all Emacs configurations.

Re: New Context Menu

[Ergus]

On Fri, Aug 20, 2021 at 09:05:38PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 20 Aug 2021 19:36:37 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> >> Maybe the problem is that mouse-N events are generated when we release
>> >> the mouse-N key. But no C-mouse-N event is generated when Control is
>> >> hold and mouse-N key released.
>> >
>> >I don't think this is true.
>> >
>> If I do:
>>
>> C-h k and press mouse-1
>
>With what toolkit? or was this on a TTY frame?

xterm, All the issues are with xterm. gui works fine for me.

>The exact behavior
>depends on the internal details of how mouse clicks in menus are
>handled by the toolkit.  It is not something that is the same across
>all Emacs configurations.

Re: New Context Menu

[Eli Zaretskii]

> Date: Fri, 20 Aug 2021 20:08:05 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> >> C-h k and press mouse-1
> >
> >With what toolkit? or was this on a TTY frame?
> 
> xterm, All the issues are with xterm. gui works fine for me.

Then I don't understand the issue you are describing.  I get the same
response on GUI frames as you report for xterm, and I think the reason
is clear: there's no binding for C-mouse-1, so Emacs shows only the
(existing) binding for C-down-mouse-1.

Re: New Context Menu

[Ergus]

On Fri, Aug 20, 2021 at 10:07:25PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 20 Aug 2021 20:08:05 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> >> C-h k and press mouse-1
>> >
>> >With what toolkit? or was this on a TTY frame?
>>
>> xterm, All the issues are with xterm. gui works fine for me.
>
>Then I don't understand the issue you are describing.  I get the same
>response on GUI frames as you report for xterm, and I think the reason
>is clear: there's no binding for C-mouse-1, so Emacs shows only the
>(existing) binding for C-down-mouse-1.

I will try to explain myself:

1) In a gui clicking (fast) mouse-X produces 2 events <down-mouse-X> +
<mouse-X> and emacs translates them to <down-mouse-X> + <mouse-X> ->
<mouse-X> when they are fast enough.

2) In a gui, holding mouse-X produces 1 event <down-mouse-X> and after a
small delay emacs processes the event, so releasing the button after
that delay is seen as an independent event <mouse-X>. In this case there
are two events and they are not merged as in 1.

3) In xterm, clicking (fast) mouse-X produces 2 events as well
<down-mouse-X> + <mouse-X> but emacs does not translate them; that means
that <down-mouse-X> is processed (shows the menu) and then <mouse-X> is
also processes (hides the menu and selects).

4) In xterm, holding mouse-X and the releasing after a while is exactly
the same as 3).

So as I said before, in xterm emacs does not use such a delay on tui, it
needs to be added or somehow provide a criteria to translate
<down-mouse-X> + <mouse-X> into <mouse-X> when it is done fast enough.

Re: New Context Menu

[Eli Zaretskii]

> Date: Sat, 21 Aug 2021 08:20:47 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, emacs-devel@gnu.org
> 
> 1) In a gui clicking (fast) mouse-X produces 2 events <down-mouse-X> +
> <mouse-X> and emacs translates them to <down-mouse-X> + <mouse-X> ->
> <mouse-X> when they are fast enough.
> 
> 2) In a gui, holding mouse-X produces 1 event <down-mouse-X> and after a
> small delay emacs processes the event, so releasing the button after
> that delay is seen as an independent event <mouse-X>. In this case there
> are two events and they are not merged as in 1.
> 
> 3) In xterm, clicking (fast) mouse-X produces 2 events as well
> <down-mouse-X> + <mouse-X> but emacs does not translate them; that means
> that <down-mouse-X> is processed (shows the menu) and then <mouse-X> is
> also processes (hides the menu and selects).
> 
> 4) In xterm, holding mouse-X and the releasing after a while is exactly
> the same as 3).
> 
> So as I said before, in xterm emacs does not use such a delay on tui, it
> needs to be added or somehow provide a criteria to translate
> <down-mouse-X> + <mouse-X> into <mouse-X> when it is done fast enough.

And why are these differences a problem?

You may be unaware of the terrible complexity and the hoops we jump
through to display menus on TTY frames, and to process mouse events on
such frames in general, but I can assure you those complexities are
real.  It is a small surprise that given that, there are differences
in how these are presented to Emacs.

Re: New Context Menu

[Ergus]

On Sat, Aug 21, 2021 at 09:53:17AM +0300, Eli Zaretskii wrote:
>> Date: Sat, 21 Aug 2021 08:20:47 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> 1) In a gui clicking (fast) mouse-X produces 2 events <down-mouse-X> +
>> <mouse-X> and emacs translates them to <down-mouse-X> + <mouse-X> ->
>> <mouse-X> when they are fast enough.
>>
>> 2) In a gui, holding mouse-X produces 1 event <down-mouse-X> and after a
>> small delay emacs processes the event, so releasing the button after
>> that delay is seen as an independent event <mouse-X>. In this case there
>> are two events and they are not merged as in 1.
>>
>> 3) In xterm, clicking (fast) mouse-X produces 2 events as well
>> <down-mouse-X> + <mouse-X> but emacs does not translate them; that means
>> that <down-mouse-X> is processed (shows the menu) and then <mouse-X> is
>> also processes (hides the menu and selects).
>>
>> 4) In xterm, holding mouse-X and the releasing after a while is exactly
>> the same as 3).
>>
>> So as I said before, in xterm emacs does not use such a delay on tui, it
>> needs to be added or somehow provide a criteria to translate
>> <down-mouse-X> + <mouse-X> into <mouse-X> when it is done fast enough.
>
>And why are these differences a problem?
>
This is why the menu disappears in tty but stays in gui with a
click. That's it.

>You may be unaware of the terrible complexity and the hoops we jump
>through to display menus on TTY frames, and to process mouse events on
>such frames in general, but I can assure you those complexities are
>real.  It is a small surprise that given that, there are differences
>in how these are presented to Emacs.
>
I am aware about how xterm events are passed to the application; but not
about the complexity emacs adds to it. Juri used down-mouse-X events
because in gui right click provided both behaviors out of the box
depending on the delay between the events. But on tty we have only the
"old" X11 one because it ignores the delay.

I don't know if such delay is something emacs handles internally or
relies in some external gtx/gui feature? In ncurses there is the
"mouseinterval" function; but probably emacs uses something like select right?

xterm emits 2 events (what I used to call down/up events some emails ago
there is not something like "click" or "mouse" event AFAIK), but is not
aware of delays between them. But emacs follows more the X11 set of
events: "down-mouse" and "mouse" (where a "mouse" event is actually a
down+up events within a delay)

Then the problem may be that emacs assumes the "up-mouse" event as
mouse-event which should work fine in most of the cases, but not when
both ("down-mouse" and "mouse" events) perform actions because it will
be impossible to emit a "mouse" event without a previous "down-mouse"

So there are two options here:

1) A proper fix for this: make xterm events behave as gui. So add a
delay to translate the two events into one; if emacs handles this
internally it may be possible... probably it does because it also
recognizes double-clicks....

2) Do a workaround: add a custom to bind context-menu to down-mouse-3 or
mouse-3 so the xterm user will have one experience or the other (but not
both as Juri liked.).

Re: New Context Menu

[Ergus]

On Fri, Aug 20, 2021 at 09:05:38PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 20 Aug 2021 19:36:37 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>
>> >> Maybe the problem is that mouse-N events are generated when we release
>> >> the mouse-N key. But no C-mouse-N event is generated when Control is
>> >> hold and mouse-N key released.
>> >
>> >I don't think this is true.
>> >
>> If I do:
>>
>> C-h k and press mouse-1
>
>With what toolkit? or was this on a TTY frame? 

I just tried on a gui and it has the same behavior. two events on one
case and one on the other.

But in gui there is some timing involved because releasing fast the
button has a different behavior than when doing it slowly. Something
that somehow does not happen in xterm.

>The exact behavior
>depends on the internal details of how mouse clicks in menus are
>handled by the toolkit.  It is not something that is the same across
>all Emacs configurations.
>

Re: New Context Menu

[Michael Welsh Duggan]

Ergus <spacibba@aol.com> writes:

> On Fri, Aug 20, 2021 at 09:05:38PM +0300, Eli Zaretskii wrote:
>>> Date: Fri, 20 Aug 2021 19:36:37 +0200
>>> From: Ergus <spacibba@aol.com>
>>> Cc: juri@linkov.net, emacs-devel@gnu.org
>>>
>>> >> Maybe the problem is that mouse-N events are generated when we release
>>> >> the mouse-N key. But no C-mouse-N event is generated when Control is
>>> >> hold and mouse-N key released.
>>> >
>>> >I don't think this is true.
>>> >
>>> If I do:
>>>
>>> C-h k and press mouse-1
>>
>> With what toolkit? or was this on a TTY frame? 
>
> I just tried on a gui and it has the same behavior. two events on one
> case and one on the other.

But C-<mouse-1> does appear in the lossage report (C-h l).

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: New Context Menu

[Jean-Christophe Helary]

> On Aug 18, 2021, at 21:08, Ergus <spacibba@aol.com> wrote:
> 
> Hi:
> 
> I just tested the new context menu... It is very nice!! thanks Juri!!

How is that context menu enabled ?
My (macos) right click is only a buffer list and F10 has not changed.
(working on a recent master build)


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: New Context Menu

[Iñigo Serna]

Hi Jean-Christophe,

On 18 August 2021 at 16:04 +02, Jean-Christophe Helary 
<lists@traduction-libre.org> wrote:

> How is that context menu enabled ?
> My (macos) right click is only a buffer list and F10 has not 
> changed.
> (working on a recent master build)

It's the new minor mode `context-menu-mode', that is disabled by 
default.


From the NEWS file:

*** New minor mode 'context-menu-mode' for context menus popped by 
    'mouse-3'.
When this mode is enabled, clicking 'down-mouse-3' anywhere in the 
buffer
pops up a menu whose contents depends on surrounding context near 
the
mouse click.  You can customize the order of the default sub-menus 
in
the context menu by customizing the user option
'context-menu-functions'.                       

Best regards,
-- 
Iñigo Serna

Re: New Context Menu

[Jean-Christophe Helary]

> On Aug 19, 2021, at 1:38, Iñigo Serna <inigoserna@gmx.com> wrote:
> 
> Hi Jean-Christophe,
> 
> On 18 August 2021 at 16:04 +02, Jean-Christophe Helary <lists@traduction-libre.org> wrote:
> 
>> How is that context menu enabled ?
>> My (macos) right click is only a buffer list and F10 has not changed.
>> (working on a recent master build)
> 
> It's the new minor mode `context-menu-mode', that is disabled by default.

Thank you Iñigo

I realize that my "master" build was maybe a few days late. It's here now.

> From the NEWS file:
> 
> *** New minor mode 'context-menu-mode' for context menus popped by    'mouse-3'.
> When this mode is enabled, clicking 'down-mouse-3' anywhere in the buffer
> pops up a menu whose contents depends on surrounding context near the
> mouse click.

Right now, in an org file, I only have a nicely ordered buffer list grouped by buffer types. It's better looking than the previous "right-click". Is that what's expected ?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: New Context Menu

[Juri Linkov]

> Right now, in an org file, I only have a nicely ordered buffer list
> grouped by buffer types. It's better looking than the previous
> "right-click". Is that what's expected ?

I suppose you are using org-mouse.el?  It overrides mouse-3
with own context menu.

Re: New Context Menu

[Jean-Christophe Helary]

> On Aug 19, 2021, at 16:08, Juri Linkov <juri@linkov.net> wrote:
> 
>> Right now, in an org file, I only have a nicely ordered buffer list
>> grouped by buffer types. It's better looking than the previous
>> "right-click". Is that what's expected ?
> 
> I suppose you are using org-mouse.el?  It overrides mouse-3
> with own context menu.

For some reason it works now. Thank you for your work !

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: New Context Menu

[Juri Linkov]

> The current implementation follows the X11 menu interaction pattern:
> Hold mouse-3 to keep the menu active and release mouse-3 to select an
> entry.
>
> Could we add an option to avoid this and have the same interaction
> behavior than in gui please?: mouse-3 activates the menu, a click over
> an option selects it and a click outside the menu hides the menu

When you press down-mouse-1 and immediately release the mouse button,
it has the same effect as if you clicked mouse-1: it displays the menu
without selecting a menu item.  So with the current win-win situation
both scenarios are supported:

1. one click: down-mouse-1, select a menu item, release mouse-1;
2. two clicks: click mouse-1, select a menu item by clicking mouse-1 again.

Both ways work on xterm as well - you can easily select a menu item with
one click on xterm too.

> In case the user wants to bind the context menu without using the mouse
> how can be done? Will the context-menu appear in the current cursor
> (point) or in the current mouse arrow position?

This is possible, but the menu appears at the left top corner,
as for example it appears on typing 'C-<f10>' that runs the command
buffer-menu-open.  Here is its implementation:

  (defun buffer-menu-open ()
    "Start key navigation of the buffer menu.
  This is the keyboard interface to \\[mouse-buffer-menu]."
    (interactive)
    (popup-menu (mouse-buffer-menu-keymap)
                (posn-at-x-y 0 0 nil t)))

We could do the same with:

    (popup-menu (context-menu-map)
                (posn-at-x-y 0 0 nil t))

Or do it much better:

    (popup-menu (context-menu-map)
                (point))

What would a good key to bind such command?  Maybe 'S-<f10>'?

But please note that currently when you select a menu item
using the keyboard, many commands will fail with

  (error "Command must be bound to an event with parameters")

Re: New Context Menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 19 Aug 2021 10:01:10 +0300
> Cc: emacs-devel@gnu.org
> 
> What would a good key to bind such command?  Maybe 'S-<f10>'?

Probably.  Or C-M-<f10>.

> But please note that currently when you select a menu item
> using the keyboard, many commands will fail with
> 
>   (error "Command must be bound to an event with parameters")

Those commands should ideally be fixed to not signal such errors,
because that's not good UI on TTY frames.  Commands that cannot be
fixed shouldn't appear in the context menus popped on TTY frames to
begin with.

Re: New Context Menu

[Ergus]

On Thu, Aug 19, 2021 at 11:03:01AM +0300, Eli Zaretskii wrote:
>> From: Juri Linkov <juri@linkov.net>
>> Date: Thu, 19 Aug 2021 10:01:10 +0300
>> Cc: emacs-devel@gnu.org
>>
>> What would a good key to bind such command?  Maybe 'S-<f10>'?
>
>Probably.  Or C-M-<f10>.
>
Hi Eli:

There is the [menu] button. It is unused at least in xterm because
it is not bound properly (I sent a message on yesterday).

By default [menu] is bound to the same than M-x, so it is a good trade
of to rebind it in the context-menu map, so by default the current
behavior is not affected. But also, because it will provide the same
behavior than other user interfaces around.

In other terminals (urxvt) such button sends S-<f6>, that is not bound
to anything either. And some others (gnome-terminal) intercept the
binding before reaching emacs... so, I think is a good trade off with
minimal impact.

>> But please note that currently when you select a menu item
>> using the keyboard, many commands will fail with
>>
>>   (error "Command must be bound to an event with parameters")
>
>Those commands should ideally be fixed to not signal such errors,
>because that's not good UI on TTY frames.  Commands that cannot be
>fixed shouldn't appear in the context menus popped on TTY frames to
>begin with.

Re: New Context Menu

[Eli Zaretskii]

> Date: Thu, 19 Aug 2021 16:11:23 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Juri Linkov <juri@linkov.net>, emacs-devel@gnu.org
> 
> >> What would a good key to bind such command?  Maybe 'S-<f10>'?
> >
> >Probably.  Or C-M-<f10>.
> >
> Hi Eli:
> 
> There is the [menu] button. It is unused at least in xterm because
> it is not bound properly (I sent a message on yesterday).
> 
> By default [menu] is bound to the same than M-x, so it is a good trade
> of to rebind it in the context-menu map, so by default the current
> behavior is not affected. But also, because it will provide the same
> behavior than other user interfaces around.
> 
> In other terminals (urxvt) such button sends S-<f6>, that is not bound
> to anything either. And some others (gnome-terminal) intercept the
> binding before reaching emacs... so, I think is a good trade off with
> minimal impact.

It's okay to bind the <menu> key where it's available.  But many
terminals don't have it, so we should _also_ bind it to some common
enough key to make it available to everyone.

Re: New Context Menu

[Yuri Khan]

On Thu, 19 Aug 2021 at 22:49, Eli Zaretskii <eliz@gnu.org> wrote:

> It's okay to bind the <menu> key where it's available.  But many
> terminals don't have it, so we should _also_ bind it to some common
> enough key to make it available to everyone.

The canonical answer to “some keyboards do not have <menu>” in the
context of context menus has been Shift+F10 since 1995. But, of
course, Some Terminals™ do not have even that.

Re: New Context Menu

[Juri Linkov]

>> But please note that currently when you select a menu item
>> using the keyboard, many commands will fail with
>>
>>   (error "Command must be bound to an event with parameters")
>
> Those commands should ideally be fixed to not signal such errors,
> because that's not good UI on TTY frames.  Commands that cannot be
> fixed shouldn't appear in the context menus popped on TTY frames to
> begin with.

What would be the best strategy for fixing these commands?  This error
is signaled for all commands that have (interactive "e").  Then such
interactive spec should be removed from all commands used in the menu?

Re: New Context Menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Fri, 20 Aug 2021 10:14:54 +0300
> 
> >> But please note that currently when you select a menu item
> >> using the keyboard, many commands will fail with
> >>
> >>   (error "Command must be bound to an event with parameters")
> >
> > Those commands should ideally be fixed to not signal such errors,
> > because that's not good UI on TTY frames.  Commands that cannot be
> > fixed shouldn't appear in the context menus popped on TTY frames to
> > begin with.
> 
> What would be the best strategy for fixing these commands?  This error
> is signaled for all commands that have (interactive "e").  Then such
> interactive spec should be removed from all commands used in the menu?

I guess so.  Why does it make sense for commands invoked from the
menus to have the "e" interactive spec?

Re: New Context Menu

[Juri Linkov]

>> >> But please note that currently when you select a menu item
>> >> using the keyboard, many commands will fail with
>> >>
>> >>   (error "Command must be bound to an event with parameters")
>> >
>> > Those commands should ideally be fixed to not signal such errors,
>> > because that's not good UI on TTY frames.  Commands that cannot be
>> > fixed shouldn't appear in the context menus popped on TTY frames to
>> > begin with.
>> 
>> What would be the best strategy for fixing these commands?  This error
>> is signaled for all commands that have (interactive "e").  Then such
>> interactive spec should be removed from all commands used in the menu?
>
> I guess so.  Why does it make sense for commands invoked from the
> menus to have the "e" interactive spec?

There are too many commands that have the "e" interactive spec.
It would be much simpler not to signal an error for them, but produce
a fake event where the clicked position is set to the position of point.

Re: New Context Menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Fri, 20 Aug 2021 19:49:03 +0300
> 
> >> What would be the best strategy for fixing these commands?  This error
> >> is signaled for all commands that have (interactive "e").  Then such
> >> interactive spec should be removed from all commands used in the menu?
> >
> > I guess so.  Why does it make sense for commands invoked from the
> > menus to have the "e" interactive spec?
> 
> There are too many commands that have the "e" interactive spec.
> It would be much simpler not to signal an error for them, but produce
> a fake event where the clicked position is set to the position of point.

Feel free to work on that (I guess that needs changes on the C
level?).

Re: New Context Menu

[Juri Linkov]

>> >> What would be the best strategy for fixing these commands?  This error
>> >> is signaled for all commands that have (interactive "e").  Then such
>> >> interactive spec should be removed from all commands used in the menu?
>> >
>> > I guess so.  Why does it make sense for commands invoked from the
>> > menus to have the "e" interactive spec?
>>
>> There are too many commands that have the "e" interactive spec.
>> It would be much simpler not to signal an error for them, but produce
>> a fake event where the clicked position is set to the position of point.
>
> Feel free to work on that (I guess that needs changes on the C
> level?).

Actually, I found out that no work is needed.  When this restriction
is removed from `call-interactively':

 	  if (next_event >= key_count)
 	    error ("%s must be bound to an event with parameters",
 		   (SYMBOLP (function)
 		    ? SSDATA (SYMBOL_NAME (function))
 		    : "command"));

then everything works fine thanks to the old decision to accept
non-mouse events in event-start, event-end, event-click-count:

  (defun event-start (event)
    (if (consp event) (nth 1 event)
      (or (posn-at-point)
          (list (selected-window) (point) '(0 . 0) 0)))

Re: New Context Menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Mon, 23 Aug 2021 10:33:32 +0300
> 
> >> There are too many commands that have the "e" interactive spec.
> >> It would be much simpler not to signal an error for them, but produce
> >> a fake event where the clicked position is set to the position of point.
> >
> > Feel free to work on that (I guess that needs changes on the C
> > level?).
> 
> Actually, I found out that no work is needed.  When this restriction
> is removed from `call-interactively':
> 
>  	  if (next_event >= key_count)
>  	    error ("%s must be bound to an event with parameters",
>  		   (SYMBOLP (function)
>  		    ? SSDATA (SYMBOL_NAME (function))
>  		    : "command"));
> 
> then everything works fine thanks to the old decision to accept
> non-mouse events in event-start, event-end, event-click-count:
> 
>   (defun event-start (event)
>     (if (consp event) (nth 1 event)
>       (or (posn-at-point)
>           (list (selected-window) (point) '(0 . 0) 0)))

The question is: do we want to remove this unconditionally for all the
commands that say (interactive "e") ?  That sounds a
backward-incompatible change to me.

Should we perhaps condition that by some variable, which menu commands
could bind when they want?

Re: New Context Menu

[Juri Linkov]

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

> The question is: do we want to remove this unconditionally for all the
> commands that say (interactive "e") ?  That sounds a
> backward-incompatible change to me.
>
> Should we perhaps condition that by some variable, which menu commands
> could bind when they want?

So here is a new variable:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: inhibit-event-check.patch --]
[-- Type: text/x-diff, Size: 1091 bytes --]

diff --git a/src/callint.c b/src/callint.c
index 6f8a7f13f6..381a3443d2 100644
--- a/src/callint.c
+++ b/src/callint.c
@@ -606,7 +606,7 @@ DEFUN ("call-interactively", Fcall_interactively, Scall_interactively, 1, 3, 0,
 	  break;
 
 	case 'e':		/* The invoking event.  */
-	  if (next_event >= key_count)
+	  if (!inhibit_event_check && next_event >= key_count)
 	    error ("%s must be bound to an event with parameters",
 		   (SYMBOLP (function)
 		    ? SSDATA (SYMBOL_NAME (function))
@@ -900,6 +900,13 @@ syms_of_callint (void)
 a way to turn themselves off when a mouse command switches windows.  */);
   Vmouse_leave_buffer_hook = Qnil;
 
+  DEFVAR_BOOL ("inhibit-event-check", inhibit_event_check,
+    doc: /* Non-nil means the interactive spec "e" doesn't check for events.
+In this case `(interactive "e")' doesn't signal an error when no event
+is produced.  Then `event-start', `event-end', `event-click-count'
+can create a new event.  */);
+  inhibit_event_check = false;
+
   defsubr (&Sinteractive);
   defsubr (&Scall_interactively);
   defsubr (&Sfuncall_interactively);

Re: New Context Menu

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: spacibba@aol.com,  emacs-devel@gnu.org
> Date: Mon, 23 Aug 2021 19:04:39 +0300
> 
> > Should we perhaps condition that by some variable, which menu commands
> > could bind when they want?
> 
> So here is a new variable:

Thanks.  I'd prefer to call it inhibit-mouse-event-check.

Also, do we want to consider it an internal variable (and name it and
document is as such)?

Otherwise, LGTM, but please add a NEWS entry.

Re: New Context Menu

[Juri Linkov]

>> > Should we perhaps condition that by some variable, which menu commands
>> > could bind when they want?
>>
>> So here is a new variable:
>
> Thanks.  I'd prefer to call it inhibit-mouse-event-check.

Ok.

> Also, do we want to consider it an internal variable (and name it and
> document is as such)?

It is like other inhibit-* variables.

> Otherwise, LGTM, but please add a NEWS entry.

Pushed with a NEWS entry.

Re: New Context Menu

[Ergus]

On Mon, Aug 23, 2021 at 08:42:52PM +0300, Juri Linkov wrote:
>>> > Should we perhaps condition that by some variable, which menu commands
>>> > could bind when they want?
>>>
>>> So here is a new variable:
>>
>> Thanks.  I'd prefer to call it inhibit-mouse-event-check.
>
>Ok.
>
>> Also, do we want to consider it an internal variable (and name it and
>> document is as such)?
>
>It is like other inhibit-* variables.
>
>> Otherwise, LGTM, but please add a NEWS entry.
>
>Pushed with a NEWS entry.
>
Hi Juri:

I see you bound the menu to [S-f10]

I am still asking about the issues with the menu key in xterm; in the
other thread I showed this:

lk201.el:35:    (define-key map "\e[29~" [menu])
rxvt.el:67:    (define-key map "\e[29~" [S-f6])
xterm.el:353:    (define-key map "\e[29~" [print])

where "\e[29~" is the sequence the menu key sends. So maybe you could
use [S-f6] instead?

That will make it work out of the box in urxvt.

Re: New Context Menu

[Juri Linkov]

> I am still asking about the issues with the menu key in xterm; in the
> other thread I showed this:
>
> lk201.el:35:    (define-key map "\e[29~" [menu])
> rxvt.el:67:    (define-key map "\e[29~" [S-f6])
> xterm.el:353:    (define-key map "\e[29~" [print])
>
> where "\e[29~" is the sequence the menu key sends. So maybe you could
> use [S-f6] instead?
>
> That will make it work out of the box in urxvt.

I installed urxvt, and in urxvt started
emacs -Q -nw -f xterm-mouse-mode -f context-menu-mode
Then typed S-<f10>.  It opened the Context menu
with blue background where the selected item is red.
Then using arrows and C-n/C-p navigated to "Paste"
and typed RET, and it pasted a string at point.
All other menu items are also working fine on urxvt.
So it seems that your config is broken.

Re: New Context Menu

[Ergus]

On Tue, Aug 24, 2021 at 09:35:07AM +0300, Juri Linkov wrote:
>> I am still asking about the issues with the menu key in xterm; in the
>> other thread I showed this:
>>
>> lk201.el:35:    (define-key map "\e[29~" [menu])
>> rxvt.el:67:    (define-key map "\e[29~" [S-f6])
>> xterm.el:353:    (define-key map "\e[29~" [print])
>>
>> where "\e[29~" is the sequence the menu key sends. So maybe you could
>> use [S-f6] instead?
>>
>> That will make it work out of the box in urxvt.
>
>I installed urxvt, and in urxvt started
>emacs -Q -nw -f xterm-mouse-mode -f context-menu-mode
>Then typed S-<f10>.  It opened the Context menu
>with blue background where the selected item is red.
>Then using arrows and C-n/C-p navigated to "Paste"
>and typed RET, and it pasted a string at point.
>All other menu items are also working fine on urxvt.
>So it seems that your config is broken.

Hi Juri:

Maybe I miss explained myself. The idea to put it in [S-f6] is to make
the context menu work with the [menu] button out of the box when
available in urxvt (and on xterm if fixed).

Of course S-<f10> works as expected. The point is that the menu key is
the "right place" for it to make it more "similar" to other applications
around. And such key is "under-utilized" by us at the moment. (Nobody
even noticed it wrongly bound in xterm)

Also because S-<f10> is menu-bar-open, that may be useful for some
people, but S-<f6> is unused. SO as you say: it is a win win ;).

Re: New Context Menu

[Yuri Khan]

On Tue, 24 Aug 2021 at 15:01, Ergus <spacibba@aol.com> wrote:

> >> lk201.el:35:    (define-key map "\e[29~" [menu])
> >> rxvt.el:67:    (define-key map "\e[29~" [S-f6])
> >> xterm.el:353:    (define-key map "\e[29~" [print])
> >>
> >> where "\e[29~" is the sequence the menu key sends. So maybe you could
> >> use [S-f6] instead?
> >>
> >> That will make it work out of the box in urxvt.
>
> Maybe I miss explained myself. The idea to put it in [S-f6] is to make
> the context menu work with the [menu] button out of the box when
> available in urxvt (and on xterm if fixed).

That would be wrong. Better:

* Push for terminfo to include a string capability that indicates the
sequence sent by the Menu key. Push for the terminfo database to
include that capability for major terminal emulators.

* Push for rxvt to change its Menu sequence to something different
from Shift+F6, and submit that sequence to the terminfo database.

* In rxvt.el, change \e[29~ to the new rxvt Menu sequence.

Even better:

* Use a terminal emulator that lets you distinguish all key combinations.

Re: New Context Menu

[Ergus]

On Tue, Aug 24, 2021 at 06:44:44PM +0700, Yuri Khan wrote:
>On Tue, 24 Aug 2021 at 15:01, Ergus <spacibba@aol.com> wrote:
>
>> >> lk201.el:35:    (define-key map "\e[29~" [menu])
>> >> rxvt.el:67:    (define-key map "\e[29~" [S-f6])
>> >> xterm.el:353:    (define-key map "\e[29~" [print])
>> >>
>> >> where "\e[29~" is the sequence the menu key sends. So maybe you could
>> >> use [S-f6] instead?
>> >>
>> >> That will make it work out of the box in urxvt.
>>
>> Maybe I miss explained myself. The idea to put it in [S-f6] is to make
>> the context menu work with the [menu] button out of the box when
>> available in urxvt (and on xterm if fixed).
>
>That would be wrong. Better:
>
It is not wrong actually. Because keys like [menu] require an
alternative for those that don't have such a key. That's why in some
emulators they are the same sequence than some other complex
combinations like S-<f6> or C-S-<f6>; or some keys not present in our
keyboards anymore (like <f15>) but can be emulated with combinations.

They are intended to be more like shortcuts; and when not, we use to
bind to another combination any way. See the vt220 or the vt100
specifications for example.

>* Push for terminfo to include a string capability that indicates the
>sequence sent by the Menu key. Push for the terminfo database to
>include that capability for major terminal emulators.
>
I already discussed this with the xterm developer, but the current
translation is direct and does not rely on tricks in the emulator
side. Xterm actually can distinguish between them, but I can't force
every emacs user to use xterm because it is very limited in many
aspects.

>* Push for rxvt to change its Menu sequence to something different
>from Shift+F6, and submit that sequence to the terminfo database.
>
>* In rxvt.el, change \e[29~ to the new rxvt Menu sequence.
>
This is somehow like create a key sequence to distinguish between 2+2
and 4... Or modifying all the universe around just because we want pi to
be 4 instead of 3,14.

>Even better:
>
>* Use a terminal emulator that lets you distinguish all key combinations.

Actually the recommended terminal emulator to work with emacs is
xterm. It is the most compatible and actually was a topic of a previous
discussion/question I did long time ago.

xterm allows to distinguish between S-<f6> and the [menu] sequence, they
are different. But urxvt and many others don't; so that will imply that
in urxvt, the context menu will take at least 3 keys when bound to
[S-f10]. Because binding to [menu] will also take [S-f6]. That's what I
want to avoid. Also because S-<f10> is already taken.

So again binding it to S-<f6> will solve all the issues with a simpler
trick. 1) not replace the current S-<f10> binding, 2) take only one
S-<f#> binding 3) make the [menu] key work in urxvt the same as with
gui.

Re: New Context Menu

[Yuri Khan]

On Tue, 24 Aug 2021 at 23:06, Ergus <spacibba@aol.com> wrote:

> It is not wrong actually. Because keys like [menu] require an
> alternative for those that don't have such a key. That's why in some
> emulators they are the same sequence than some other complex
> combinations like S-<f6> or C-S-<f6>; or some keys not present in our
> keyboards anymore (like <f15>) but can be emulated with combinations.

The alternative for people who don’t have Menu is Shift+F10. Has been
since Windows 95 and is adopted by GTK applications. And wxWidgets
applications. And maybe other X toolkits as well.

Shift+F6 is “go to previous pane” in Windows guidelines. Leave that
for people who want an easier key than C-- C-x o.

What I’m opposed to is doing things in an application to cover for a
design flaw in a single terminal emulator.

> >* Push for terminfo to include a string capability that indicates the
> >sequence sent by the Menu key. Push for the terminfo database to
> >include that capability for major terminal emulators.
> >
> I already discussed this with the xterm developer, but the current
> translation is direct and does not rely on tricks in the emulator
> side. Xterm actually can distinguish between them, but I can't force
> every emacs user to use xterm because it is very limited in many
> aspects.

How is it direct? The evdev keycode <MENU> is 135. CSI 2 9 ~ is the
VT220 sequence for F16; in evdev, <FK16> is 194.

(F16 also somewhat explains rxvt’s Shift+F6, by pretending Shift+F<n>
is F<10+n>. Still wrong, because there are 12 function keys! Also
because one can build a keyboard that has both F16 and Menu, as USB
HID Tables assign different codes to these.)

> Actually the recommended terminal emulator to work with emacs is
> xterm. It is the most compatible and actually was a topic of a previous
> discussion/question I did long time ago.

The most compatible with what? VT220? Not relevant nowadays.

PC keyboard that most everybody has on their desk? No.

> xterm allows to distinguish between S-<f6> and the [menu] sequence, they
> are different. But urxvt and many others don't; so that will imply that
> in urxvt, the context menu will take at least 3 keys when bound to
> [S-f10]. Because binding to [menu] will also take [S-f6]. That's what I
> want to avoid. Also because S-<f10> is already taken.

To avoid having Menu take Shift+F6, get rxvt to use different
sequences for Menu and Shift+F6.

Re: New Context Menu

[Ergus]

On Wed, Aug 25, 2021 at 02:41:56AM +0700, Yuri Khan wrote:
>On Tue, 24 Aug 2021 at 23:06, Ergus <spacibba@aol.com> wrote:
>
>> It is not wrong actually. Because keys like [menu] require an
>> alternative for those that don't have such a key. That's why in some
>> emulators they are the same sequence than some other complex
>> combinations like S-<f6> or C-S-<f6>; or some keys not present in our
>> keyboards anymore (like <f15>) but can be emulated with combinations.
>
>The alternative for people who don’t have Menu is Shift+F10. Has been
>since Windows 95 and is adopted by GTK applications. And wxWidgets
>applications. And maybe other X toolkits as well.
>
>Shift+F6 is “go to previous pane” in Windows guidelines. Leave that
>for people who want an easier key than C-- C-x o.
>
Shift+F6 is unbound by default. Any way I can live with that but rxvt
will sacrifice an extra binding.

>What I’m opposed to is doing things in an application to cover for a
>design flaw in a single terminal emulator.
>
I don't care a design flaw while there is some design. Having [menu]
bound in gui and see the same key as [print] in xterm is just
inconsistent and a waste of a valuable key.

>> >* Push for terminfo to include a string capability that indicates the
>> >sequence sent by the Menu key. Push for the terminfo database to
>> >include that capability for major terminal emulators.
>> >
>> I already discussed this with the xterm developer, but the current
>> translation is direct and does not rely on tricks in the emulator
>> side. Xterm actually can distinguish between them, but I can't force
>> every emacs user to use xterm because it is very limited in many
>> aspects.
>
>How is it direct?
xev

> The evdev keycode <MENU> is 135. CSI 2 9 ~ is the
>VT220 sequence for F16; in evdev, <FK16> is 194.
>
>(F16 also somewhat explains rxvt’s Shift+F6, by pretending Shift+F<n>
>is F<10+n>. Still wrong, because there are 12 function keys! Also
>because one can build a keyboard that has both F16 and Menu, as USB
>HID Tables assign different codes to these.)
>
>> Actually the recommended terminal emulator to work with emacs is
>> xterm. It is the most compatible and actually was a topic of a previous
>> discussion/question I did long time ago.
>
>The most compatible with what? VT220? Not relevant nowadays.
>
The most compatible with everything in emacs out of the box; tmux; fancy
combinations and so on. Emacs gave me too many problems with bindings
when I tried to use it in other terminal emulators. (and the list is
veeery long)

>PC keyboard that most everybody has on their desk? No.
>
Totally disagree here.

>> xterm allows to distinguish between S-<f6> and the [menu] sequence, they
>> are different. But urxvt and many others don't; so that will imply that
>> in urxvt, the context menu will take at least 3 keys when bound to
>> [S-f10]. Because binding to [menu] will also take [S-f6]. That's what I
>> want to avoid. Also because S-<f10> is already taken.
>
>To avoid having Menu take Shift+F6, get rxvt to use different
>sequences for Menu and Shift+F6.

rxvt has many other worst compatibility issues than this and requires a
lot of customization to work decently with emacs... so your explication
of Shift+F<n> clarifies a lot.

Re: New Context Menu

[Ergus]

On Thu, Aug 19, 2021 at 10:01:10AM +0300, Juri Linkov wrote:
>> The current implementation follows the X11 menu interaction pattern:
>> Hold mouse-3 to keep the menu active and release mouse-3 to select an
>> entry.
>>
>> Could we add an option to avoid this and have the same interaction
>> behavior than in gui please?: mouse-3 activates the menu, a click over
>> an option selects it and a click outside the menu hides the menu
>
>When you press down-mouse-1 and immediately release the mouse button,
>it has the same effect as if you clicked mouse-1: it displays the menu
>without selecting a menu item.  So with the current win-win situation
>both scenarios are supported:
>
>1. one click: down-mouse-1, select a menu item, release mouse-1;
>2. two clicks: click mouse-1, select a menu item by clicking mouse-1 again.
>
>
>Both ways work on xterm as well - you can easily select a menu item with
>one click on xterm too.
>

Hi Juri:

For me only 1. works now as you describe on xterm.

Whenever I try 2. it doesn't work the menu disappears when I release the
button either fast or slow. With the problem that releasing fast usually
selects the first item (generally Undo).

On gui it works as you describe.

Maybe this is something deeper related with the menu API, I don't
know...

>> In case the user wants to bind the context menu without using the mouse
>> how can be done? Will the context-menu appear in the current cursor
>> (point) or in the current mouse arrow position?
>
>This is possible, but the menu appears at the left top corner,
>as for example it appears on typing 'C-<f10>' that runs the command
>buffer-menu-open.  Here is its implementation:
>
>  (defun buffer-menu-open ()
>    "Start key navigation of the buffer menu.
>  This is the keyboard interface to \\[mouse-buffer-menu]."
>    (interactive)
>    (popup-menu (mouse-buffer-menu-keymap)
>                (posn-at-x-y 0 0 nil t)))
>
>We could do the same with:
>
>    (popup-menu (context-menu-map)
>                (posn-at-x-y 0 0 nil t))
>
>Or do it much better:
>
>    (popup-menu (context-menu-map)
>                (point))
>
>What would a good key to bind such command?  Maybe 'S-<f10>'?
>
There is the menu key that nobody seems to use because since 2007 nobody
noticed that it is not bound for xterm. Everywhere else (browsers,
editors, explorers) the menu key has the same effect than right click,
so if we want a binding, this is the right one. Sadly
execute-extended-command is bound to [menu]; but the user may know that
when context-menu is enabled, that binding is replaced for something
standard... (or add a custom to set it).

I just started another thread about [menu] not bound in xterm.

>But please note that currently when you select a menu item
>using the keyboard, many commands will fail with
>
>  (error "Command must be bound to an event with parameters")
>
The dirty but functional solution for this may be to create a
function/macro that emulates a full event. Because I don't know how
difficult may be to modify the events api to distinguish when the mouse
was used or use the point otherwise...

Re: New Context Menu

[Juri Linkov]

>>1. one click: down-mouse-1, select a menu item, release mouse-1;
>>2. two clicks: click mouse-1, select a menu item by clicking mouse-1 again.
>>
>>Both ways work on xterm as well - you can easily select a menu item with
>>one click on xterm too.
>
> For me only 1. works now as you describe on xterm.
>
> Whenever I try 2. it doesn't work the menu disappears when I release the
> button either fast or slow. With the problem that releasing fast usually
> selects the first item (generally Undo).

Do other menus work for you?  What do you see when clicking
C-<down-mouse-1> bound to mouse-buffer-menu, or S-<down-mouse-1>
bound to mouse-appearance-menu, or C-<down-mouse-3> bound to
mouse-menu-bar-map, etc.

> There is the menu key that nobody seems to use because since 2007 nobody
> noticed that it is not bound for xterm. Everywhere else (browsers,
> editors, explorers) the menu key has the same effect than right click,
> so if we want a binding, this is the right one. Sadly
> execute-extended-command is bound to [menu]; but the user may know that
> when context-menu is enabled, that binding is replaced for something
> standard... (or add a custom to set it).

Does this patch work for you?  If yes, then we could create
context-menu-mode-map active for context-menu-mode
and add these keybindings to it.

diff --git a/lisp/mouse.el b/lisp/mouse.el
index d2a5200d8d..ecf95f11b5 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -454,8 +455,13 @@ context-menu-mode
     (setq context-menu--old-mouse-3 (global-key-binding [mouse-3]))
     (global-unset-key [mouse-3])
     (setq context-menu--old-down-mouse-3 (global-key-binding [down-mouse-3]))
-    (global-set-key [down-mouse-3] context-menu-entry))
+    (global-set-key [down-mouse-3] context-menu-entry)
+    (setq context-menu--old-menu (global-key-binding [menu]))
+    (global-set-key [menu] context-menu-entry))
    (t
+    (when context-menu--old-menu
+      (global-set-key [menu] context-menu--old-menu)
+      (setq context-menu--old-menu nil))
     (if (not context-menu--old-down-mouse-3)
         (global-unset-key [down-mouse-3])
       (global-set-key [down-mouse-3] context-menu--old-down-mouse-3)

Re: New Context Menu

[Ergus]

On Fri, Aug 20, 2021 at 10:24:00AM +0300, Juri Linkov wrote:
>>>1. one click: down-mouse-1, select a menu item, release mouse-1;
>>>2. two clicks: click mouse-1, select a menu item by clicking mouse-1 again.
>>>
>>>Both ways work on xterm as well - you can easily select a menu item with
>>>one click on xterm too.
>>
>> For me only 1. works now as you describe on xterm.
>>
>> Whenever I try 2. it doesn't work the menu disappears when I release the
>> button either fast or slow. With the problem that releasing fast usually
>> selects the first item (generally Undo).
>
>Do other menus work for you?  What do you see when clicking
>C-<down-mouse-1> bound to mouse-buffer-menu, or S-<down-mouse-1>
>bound to mouse-appearance-menu, or C-<down-mouse-3> bound to
>mouse-menu-bar-map, etc.
>
C-<down-mouse-1> and C-<down-mouse-3> Behave as you describe.
S-<down-mouse-1> Does not work in xterm

The issue is that context menu is bound to an "unmodified" mouse
event. If you try this on xterm:

(global-set-key [down-mouse-1] 'mouse-buffer-menu)
or
(global-set-key [down-mouse-3] 'mouse-buffer-menu)

Then you should notice the same issue.

Or when I press C-<down-mouse-1> (shows the menu), then release control,
and after that, release the mouse button: same behavior (menu disappears
and/or selects). So emacs is receiving the "up-mouse-1" as an event in
xterm. That's the issue.

>> There is the menu key that nobody seems to use because since 2007 nobody
>> noticed that it is not bound for xterm. Everywhere else (browsers,
>> editors, explorers) the menu key has the same effect than right click,
>> so if we want a binding, this is the right one. Sadly
>> execute-extended-command is bound to [menu]; but the user may know that
>> when context-menu is enabled, that binding is replaced for something
>> standard... (or add a custom to set it).
>
>Does this patch work for you?  If yes, then we could create
>context-menu-mode-map active for context-menu-mode
>and add these keybindings to it.
>
>diff --git a/lisp/mouse.el b/lisp/mouse.el
>index d2a5200d8d..ecf95f11b5 100644
>--- a/lisp/mouse.el
>+++ b/lisp/mouse.el
>@@ -454,8 +455,13 @@ context-menu-mode
>     (setq context-menu--old-mouse-3 (global-key-binding [mouse-3]))
>     (global-unset-key [mouse-3])
>     (setq context-menu--old-down-mouse-3 (global-key-binding [down-mouse-3]))
>-    (global-set-key [down-mouse-3] context-menu-entry))
>+    (global-set-key [down-mouse-3] context-menu-entry)
>+    (setq context-menu--old-menu (global-key-binding [menu]))
>+    (global-set-key [menu] context-menu-entry))
>    (t
>+    (when context-menu--old-menu
>+      (global-set-key [menu] context-menu--old-menu)
>+      (setq context-menu--old-menu nil))
>     (if (not context-menu--old-down-mouse-3)
>         (global-unset-key [down-mouse-3])
>       (global-set-key [down-mouse-3] context-menu--old-down-mouse-3)

We need to fix the [menu] issue in xterm first, because right now there
is no [menu] key action. But I haven't receive any reply about that in
the other thread; so I don't know if it is actually an issue or a design
choice.

Hopefully Stefan (who added the commit in 2007) will reply about this.

Just a question:

If the context-menu-mode is a minor mode. Why the bindings are not added
in a context-menu-mode-map and avoids manually saving the -old commands?

Is there an issue with that?

Re: New Context Menu

[Juri Linkov]

> The issue is that context menu is bound to an "unmodified" mouse
> event. If you try this on xterm:
>
> (global-set-key [down-mouse-1] 'mouse-buffer-menu)
> or
> (global-set-key [down-mouse-3] 'mouse-buffer-menu)
>
> Then you should notice the same issue.
>
> Or when I press C-<down-mouse-1> (shows the menu), then release control,
> and after that, release the mouse button: same behavior (menu disappears
> and/or selects). So emacs is receiving the "up-mouse-1" as an event in
> xterm. That's the issue.

If the menu doesn't disappear with

  (global-set-key [C-down-mouse-1] 'mouse-buffer-menu)

but disappears with

  (global-set-key [down-mouse-1] 'mouse-buffer-menu)

this means there is a bug in low-level xterm handling code.

BTW, while testing xterm for a short time, I found more bugs in xterm,
e.g. clicking [M-down-mouse-1] fails in xterm with:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  encode-coding-string(nil utf-8-unix)
  #f(compiled-function (type data) "Copy DATA to the X selection using the OSC 52 escape sequence.\n\nTYPE specifies which selection to set; it must be either\n`PRIMARY' or `CLIPBOARD'.  DATA must be a string.\n\nThis can be used as a `gui-set-selection' method for\nxterm-compatible terminal emulators.  Then your system clipboard\nwill be updated whenever you copy a region of text in Emacs.\n\nIf the resulting OSC 52 sequence would be longer than\n`xterm-max-cut-length', then the TEXT is not sent to the system\nclipboard.\n\nThis function either sends a raw OSC 52 sequence or wraps the OSC\n52 in a Device Control String sequence.  This way, it will work\non a bare terminal emulators as well as inside the screen\nprogram.  When inside the screen program, this function also\nchops long DCS s
 equences into multiple smaller ones to avoid\nhitting screen's max DCS length." #<bytecode -0x1b4ad63ac0b5ef21>)(SECONDARY nil)
  apply(#f(compiled-function (type data) "Copy DATA to the X selection using the OSC 52 escape sequence.\n\nTYPE specifies which selection to set; it must be either\n`PRIMARY' or `CLIPBOARD'.  DATA must be a string.\n\nThis can be used as a `gui-set-selection' method for\nxterm-compatible terminal emulators.  Then your system clipboard\nwill be updated whenever you copy a region of text in Emacs.\n\nIf the resulting OSC 52 sequence would be longer than\n`xterm-max-cut-length', then the TEXT is not sent to the system\nclipboard.\n\nThis function either sends a raw OSC 52 sequence or wraps the OSC\n52 in a Device Control String sequence.  This way, it will work\non a bare terminal emulators as well as inside the screen\nprogram.  When inside the screen program, this function also\nchops long
  DCS sequences into multiple smaller ones to avoid\nhitting screen's max DCS length." #<bytecode -0x1b4ad63ac0b5ef21>) (SECONDARY nil))
  #f(compiled-function (&rest args) #<bytecode 0x19ad559537b92ff3>)(SECONDARY nil)
  apply(#f(compiled-function (&rest args) #<bytecode 0x19ad559537b92ff3>) (SECONDARY nil))
  gui-backend-set-selection(SECONDARY nil)
  gui-set-selection(SECONDARY nil)
  mouse-drag-secondary((M-down-mouse-1 (#<window 1 on *scratch*> 153 (42 . 10) 16176 nil 153 (41 . 3) nil (35 . 7) (1 . 0))))
  funcall-interactively(mouse-drag-secondary (M-down-mouse-1 (#<window 1 on *scratch*> 153 (42 . 10) 16176 nil 153 (41 . 3) nil (35 . 7) (1 . 0))))
  command-execute(mouse-drag-secondary)

> Just a question:
>
> If the context-menu-mode is a minor mode. Why the bindings are not added
> in a context-menu-mode-map and avoids manually saving the -old commands?
>
> Is there an issue with that?

Thanks for the idea, this should work.

Re: New Context Menu

[Ergus via Emacs development discussions.]

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


>> Just a question:
>>
>> If the context-menu-mode is a minor mode. Why the bindings are not added
>> in a context-menu-mode-map and avoids manually saving the -old commands?
>>
>> Is there an issue with that?
>
>Thanks for the idea, this should work.
>

Please check the attached patch. It works for me and simplifies the
current code for the bindings.



[-- Attachment #2: context-map.patch --]
[-- Type: text/plain, Size: 2112 bytes --]

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 3441a4787e..86427a02c6 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -440,42 +440,22 @@ context-menu-entry
   `(menu-item ,(purecopy "Context Menu") ignore
               :filter (lambda (_) (context-menu-map))))
 
-(defvar context-menu--saved-bindings nil
-  "Alist of bindings to restore when `context-menu-mode' is disabled.")
-
-(defun context-menu--bind-mouse (click-sym down-sym)
-  "Enable `context-menu-mode' mouse bindings.
-CLICK-SYM and DOWN-SYM are the mouse click and down key symbols to use."
-  (let ((click (vector click-sym))
-        (down (vector down-sym)))
-    (push (cons click-sym (global-key-binding click))
-          context-menu--saved-bindings)
-    (global-unset-key click)
-    (push (cons down-sym (global-key-binding down))
-          context-menu--saved-bindings)
-    (global-set-key down context-menu-entry)))
-
-(defun context-menu--restore-bindings ()
-  "Restore saved `context-menu-mode' bindings."
-  (pcase-dolist (`(,sym . ,binding) context-menu--saved-bindings)
-    (let ((key (vector sym)))
-      (if binding
-          (global-set-key key binding)
-        (global-unset-key key)))))
+(defvar context-menu-mode-map
+  (let ((map (make-sparse-keymap)))
+    (define-key map [mouse-3] nil)
+    (define-key map [down-mouse-3] context-menu-entry)
+    (when (featurep 'ns)
+      (define-key map [C-mouse-1] nil)
+      (define-key map [C-down-mouse-1] context-menu-entry))
+    map)
+  "Context-menu-mode map.")
 
 (define-minor-mode context-menu-mode
   "Toggle Context Menu mode.
 
 When Context Menu mode is enabled, clicking the mouse button down-mouse-3
 activates the menu whose contents depends on its surrounding context."
-  :global t :group 'mouse
-  (if context-menu-mode
-      (progn
-        (setq context-menu--saved-bindings nil)
-        (context-menu--bind-mouse 'mouse-3 'down-mouse-3)
-        (when (featurep 'ns)
-          (context-menu--bind-mouse 'C-mouse-1 'C-down-mouse-1)))
-    (context-menu--restore-bindings)))
+  :global t :group 'mouse)
 
 \f
 ;; Commands that operate on windows.

Re: New Context Menu

[Juri Linkov]

>>> If the context-menu-mode is a minor mode. Why the bindings are not added
>>> in a context-menu-mode-map and avoids manually saving the -old commands?
>>>
>>> Is there an issue with that?
>>
>>Thanks for the idea, this should work.
>
> Please check the attached patch. It works for me and simplifies the
> current code for the bindings.

Thanks, pushed now.

Re: New Context Menu and mouse-1

[Juri Linkov]

Other apps support the following optimal mouse gesture:

1. Press down-mouse-1 and move the mouse to select the region;
2. Without releasing mouse-1, click mouse-3 to pop up the context menu;
3. Release mouse-1 on the menu item "Cut", thus deleting the region.

This allows selecting and deleting the region with just 2 mouse clicks.
The same works almost perfectly in Emacs with a single snag:
while dragging mouse-1, visually it looks like the region is selected,
but really the region don't get selected until mouse-1 is released
and calls 'mouse-set-region' bound to [drag-mouse-1].

But while using the above gesture, [drag-mouse-1] (mouse-set-region) is
never invoked:

 <down-mouse-1>		    ;; mouse-drag-region
 <mouse-movement>	    ;; anonymous-command
 <mouse-movement>	    ;; anonymous-command
 <mouse-movement>	    ;; anonymous-command
 <down-mouse-3> <cut>	    ;; kill-region

I have no idea how this could be fixed.

Maybe mouse--drag-set-mark-and-point should set the real region when
called from lambda bound to [mouse-movement] by set-transient-map in
mouse-drag-track?

Re: New Context Menu and mouse-1

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Fri, 27 Aug 2021 09:21:21 +0300
> 
> Other apps support the following optimal mouse gesture:
> 
> 1. Press down-mouse-1 and move the mouse to select the region;
> 2. Without releasing mouse-1, click mouse-3 to pop up the context menu;
> 3. Release mouse-1 on the menu item "Cut", thus deleting the region.
> 
> This allows selecting and deleting the region with just 2 mouse clicks.
> The same works almost perfectly in Emacs with a single snag:
> while dragging mouse-1, visually it looks like the region is selected,
> but really the region don't get selected until mouse-1 is released
> and calls 'mouse-set-region' bound to [drag-mouse-1].
> 
> But while using the above gesture, [drag-mouse-1] (mouse-set-region) is
> never invoked:
> 
>  <down-mouse-1>		    ;; mouse-drag-region
>  <mouse-movement>	    ;; anonymous-command
>  <mouse-movement>	    ;; anonymous-command
>  <mouse-movement>	    ;; anonymous-command
>  <down-mouse-3> <cut>	    ;; kill-region
> 
> I have no idea how this could be fixed.

Why do you need mouse-set-region to be invoked?  And if you do, why
cannot the command bound to down-mouse-3 do that?

Re: New Context Menu and mouse-1

[Juri Linkov]

>>  <down-mouse-1>          ;; mouse-drag-region
>>  <mouse-movement>        ;; anonymous-command
>>  <mouse-movement>        ;; anonymous-command
>>  <mouse-movement>        ;; anonymous-command
>>  <down-mouse-3> <cut>    ;; kill-region
>> 
>> I have no idea how this could be fixed.
>
> Why do you need mouse-set-region to be invoked?  And if you do, why
> cannot the command bound to down-mouse-3 do that?

There should be no need to invoke mouse-set-region,
because <mouse-movement> already sets the region.
And indeed, the minimal change that fixes this problem
is just removing these lines:

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 7d3ed9a0e4..933ad5181e 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -1578,9 +1578,7 @@ mouse-drag-track
        map)
      t (lambda ()
          (setq track-mouse old-track-mouse)
-         (setq auto-hscroll-mode auto-hscroll-mode-saved)
-         (deactivate-mark)
-         (pop-mark)))))
+         (setq auto-hscroll-mode auto-hscroll-mode-saved)))))
 
 (defun mouse--drag-set-mark-and-point (start click click-count)
   (let* ((range (mouse-start-end start click click-count))

Then everything works fine: the aforementioned case
and the normal using mouse-1 to select a region.

Re: New Context Menu and mouse-1

[Stefan Monnier]

> diff --git a/lisp/mouse.el b/lisp/mouse.el
> index 7d3ed9a0e4..933ad5181e 100644
> --- a/lisp/mouse.el
> +++ b/lisp/mouse.el
> @@ -1578,9 +1578,7 @@ mouse-drag-track
>         map)
>       t (lambda ()
>           (setq track-mouse old-track-mouse)
> -         (setq auto-hscroll-mode auto-hscroll-mode-saved)
> -         (deactivate-mark)
> -         (pop-mark)))))
> +         (setq auto-hscroll-mode auto-hscroll-mode-saved)))))
>  
>  (defun mouse--drag-set-mark-and-point (start click click-count)
>    (let* ((range (mouse-start-end start click click-count))
>
> Then everything works fine: the aforementioned case
> and the normal using mouse-1 to select a region.

Note that this changes conceptually what `mouse-drag-track` does.
Instead of only giving visual feedback during a drag, it actually does
select the region (whereas in the current code, the region selection is
actually performed by the binding of `drag-mouse-1` to `mouse-set-region`).

So the above will lead to `mouse-set-region` being called when the
region has already been set (at least in terminals that provide
`mouse-movement` events).

I'm not sure if it can introduce problems, but it would deserve
a comment about the fact that the region selection is performed
"redundantly" here and in `mouse-set-region` and why it's done this way.

From what I remember about the last time I worked in this code, it's
a somewhat messy area.

BTW, maybe another way to look at the problem is to say that
invoking the context-menu should not exit the transient map (but this
may come with its own set of problems, of course).

Related to this, I wonder if `down-mouse-1` .. move .. `down-mouse-3`,
`up-mouse-3` ... `up-mouse-1` would and/or should generate
a `drag-mouse-1` event.


        Stefan

Re: New Context Menu and mouse-1

[Juri Linkov]

>> -         (deactivate-mark)
>> -         (pop-mark)))))
>
> Note that this changes conceptually what `mouse-drag-track` does.
> Instead of only giving visual feedback during a drag, it actually does
> select the region (whereas in the current code, the region selection is
> actually performed by the binding of `drag-mouse-1` to `mouse-set-region`).
>
> So the above will lead to `mouse-set-region` being called when the
> region has already been set (at least in terminals that provide
> `mouse-movement` events).
>
> I'm not sure if it can introduce problems, but it would deserve
> a comment about the fact that the region selection is performed
> "redundantly" here and in `mouse-set-region` and why it's done this way.

With more testing I noticed that after pushing the mark twice
it requires more C-u C-SPC to get back to the original mark.
Maybe push-mark could be optimized to not push the mark
to the same position that is already at the top of the mark-ring.
Hmm, interesting that it intentionally let-binds history-delete-duplicates
to nil.

> From what I remember about the last time I worked in this code, it's
> a somewhat messy area.

Indeed, this code looks overcomplicated.  I tried to implement
extending the existing region with S-mouse-1 based on existing code,
but this is not a simple task due to code complexity.

> BTW, maybe another way to look at the problem is to say that
> invoking the context-menu should not exit the transient map (but this
> may come with its own set of problems, of course).
>
> Related to this, I wonder if `down-mouse-1` .. move .. `down-mouse-3`,
> `up-mouse-3` ... `up-mouse-1` would and/or should generate
> a `drag-mouse-1` event.

Actually, the existing event sequence without the final `drag-mouse-1`
is exactly what is needed, because `drag-mouse-1` is intended to finalize
the region selection, but there may be nothing to select at this time
after `up-mouse-3` invoked "Cut" or "Clear" from the context menu.

Re: New Context Menu and mouse-1

[Juri Linkov]

> BTW, maybe another way to look at the problem is to say that
> invoking the context-menu should not exit the transient map (but this
> may come with its own set of problems, of course).

The problem is that not to exit the transient map
it's not possible to check for some known events,
because e.g. selecting "Cut" produces 'cut',
and other such symbols.

So the other way around would be to check for
the known events and then deactivate the mark.
This is necessary because otherwise simply clicking mouse-1
will activate the mark and leave it active afterwards.

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 7d3ed9a0e4..e97352cdf8 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -1579,8 +1579,9 @@ mouse-drag-track
      t (lambda ()
          (setq track-mouse old-track-mouse)
          (setq auto-hscroll-mode auto-hscroll-mode-saved)
-         (deactivate-mark)
-         (pop-mark)))))
+         (when (memq (car-safe last-input-event) '(mouse-1 drag-mouse-1))
+           (deactivate-mark)
+           (pop-mark))))))

This still exits the transient map in both cases, and I don't know
how not to exit the transient map only for events from the context-menu.

Re: New Context Menu and mouse-1

[Juri Linkov]

>> BTW, maybe another way to look at the problem is to say that
>> invoking the context-menu should not exit the transient map (but this
>> may come with its own set of problems, of course).
>
> +         (when (memq (car-safe last-input-event) '(mouse-1 drag-mouse-1))
> +           (deactivate-mark)
> +           (pop-mark))))))

Or rather

+         (unless (and context-menu-mode
+                      (eq (car-safe (aref (this-command-keys-vector) 0))
+                          'down-mouse-3))
+           (deactivate-mark)
+           (pop-mark))))))

Re: New Context Menu and mouse-1

[Stefan Monnier]

Juri Linkov [2021-08-30 10:22:01] wrote:
>>> BTW, maybe another way to look at the problem is to say that
>>> invoking the context-menu should not exit the transient map (but this
>>> may come with its own set of problems, of course).
>>
>> +         (when (memq (car-safe last-input-event) '(mouse-1 drag-mouse-1))
>> +           (deactivate-mark)
>> +           (pop-mark))))))
>
> Or rather
>
> +         (unless (and context-menu-mode
> +                      (eq (car-safe (aref (this-command-keys-vector) 0))
> +                          'down-mouse-3))
> +           (deactivate-mark)
> +           (pop-mark))))))

This looks "honest and safe".  If you can add a comment explaining why
we have this ad-hoc hack there, then I think it's quite acceptable
(given that we're unable to figure out what is The Right Way).


        Stefan