bug#50067: Context menus

[Juri Linkov]

> 1. Mac users expect C-mouse-1 to be equivalent to mouse-3 because Macs
> traditionally only have one mouse button; this is especially true of laptop
> users (probably the majority today). Simply speaking, control-mouse-1 is
> expected to invoke the context menu; this is the platform convention and we
> should try to find a way to make it so.
>
> We could add a mac-only setting that remaps control-mouse-1 to mouse-3
> (preserving all other modifiers like shift, alt and super). (I don't think
> there already is such a translation but could be mistaken). I'm attaching
> a tentative patch as a proof of concept.
>
> It is also possible to just do it in Lisp, but then we'd probably need
> to do it specially for the context menu. (I tried using event
> translation but that didn't work right.)

The raison d'être for the special mode context-menu-mode is to
rebind the default keys optionally.  So it would make sense to bind
context-menu-entry conditionally:

1. to [C-mouse-1] on macOS depending on ‘(featurep 'ns)’;
2. to [down-mouse-3] everywhere else.

in the function body of context-menu-mode.

> Currently, C-mouse-1 pops up the buffer menu but it's unclear if
> that's used by a sizeable part of the population, and in any case Macs
> have a Buffer menu easily accessible in the menu bar.

Additionally, a Buffer menu is accessible from the context menu
when context-menu-functions is customized to contain ‘context-menu-global’.

> 2. The context menu contains the disabled entry "Context Menu" as some kind
> of title – that is very alien on macOS where context menus never have
> titles. I believe the same is true at least on Windows, and frankly, there
> should be no need to explicitly tell the user that what he or she is
> looking at is a context menu. I suggest we just drop the title on
> all platforms.
>
> Replacing (purecopy "Context Menu") by "" in `context-menu-entry` makes it
> go away, but then we get the new title "Select" from heavens knows where
> (menu.c, from the look of it). Apparently the Emacs menu system just wants
> a title; we should find a way to disable it in popup menus.

After trying to remove it altogether, there is no title at all,
but maybe it's platform-dependent (I tested on GTK):

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 9b7d4c240f..5193994231 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -304,7 +304,7 @@ context-menu-filter-function
 (defun context-menu-map ()
   "Return composite menu map."
-  (let ((menu (make-sparse-keymap "Context Menu")))
+  (let ((menu (make-sparse-keymap)))
     (run-hook-wrapped 'context-menu-functions
                       (lambda (fun)
                         (setq menu (funcall fun menu))

> 3. Not Mac-specific (really about xref): in some modes, Find Definition
> applies to point instead of where the click occurred. Apparently the xref
> backend ignores the symbol discovered by xref-find-definition-at-mouse
> because that tokenisation isn't appropriate for the language and it does
> a more thorough job that is based on point instead. What we really should
> do is to set point temporarily for the whole duration of the
> xref-find-definitions call.

Could you please provide a test case?  Because I've thoroughly tested
“Find Definition” to apply where the click occurred, and it works as expected.