Re: New Context Menu

[Ergus <spacibba@aol.com>]

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