Re: Context menus and mouse-3

[Juri Linkov <juri@linkov.net>]

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

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

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

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

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