[Top][All Lists]

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

Re: Context menus and mouse-3

From: Juri Linkov
Subject: Re: Context menus and mouse-3
Date: Mon, 12 Jul 2021 23:56:39 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu)

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

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

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

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

Every mode can define own [context-menu] in their mode-maps,
then users will be able to customize mode's [context-menu]
using mode hooks.  Even text-properties could define
the [context-menu] in their local bindings that will be used
by '(current-local-map)' or better '(current-active-maps)'.

To be able to override the [context-menu], local bindings could use
text-property maps with another binding named [overriding-context-menu]
that will replace the whole composite [context-menu], so e.g.
flyspell-mode could put it on misspelled words, etc.

reply via email to

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