Re: Context menus and mouse-3

[Stefan Monnier]

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

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

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

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

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

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

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

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

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

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


        Stefan