bug#50067: Context menus

[Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>]

>> I suggest to assign [drag-mouse-3] as well, as shown below.
>> 
>> (define-key map [mouse-3] context-menu-entry)
>> (define-key map [drag-mouse-3] context-menu-entry)
> 
> There is no need to bind [drag-mouse-3] because [down-mouse-3] is bound.

I confirmed. I took the suggestion back.

>> On Mac, I suggest to assign [C-double-mouse-1] as well as shown below.
>> 
>> (define-key map [C-down-mouse-1] #'ignore)
>> (define-key map [C-mouse-1] context-menu-entry)
>> (define-key map [C-double-mouse-1] context-menu-entry)
>> (define-key map [C-triple-mouse-1] context-menu-entry)
>> (define-key map [C-drag-mouse-1] context-menu-entry)
> 
> I leave this for the users of Mac to decide what would be better on Mac.

I agree.  User can bind it later too.

>> * Error detection system
>> 
>> It is good if the context-menu system is ready for
>> an error that occurs on one of context-menu-functions.
>> For now, when there is error, Emacs only tells
>> `<mouse-3> is undefined'.
> 
> I agree, a better error reporting would be nice.  Patches welcome.

This is something I wanted to have for a long time.  I do not have
idea where to start. I hope someone works on this using this opportunity.

>> * Long click system
>> 
>> It’s time to discuss long-left-click also as trigger to
>> show context menu.
>> 
>> https://lists.gnu.org/archive/html/emacs-devel/2017-11/msg00267.html
>> https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01277.html
> 
> I tried to implement this, but soon found that long-left-click is unusable,
> because such artificial delay is a hassle - no one would have
> patience to wait even half a second until the menu finally appears.
> But this could be implemented anyway when users will demand this.

I think this is useful especially on laptop computer with Mac.
As inferred on other posts laptop computer with Mac does not have
mouse-3.  However, it is possible that I’m the only one.

>> * Open by other frame
>> 
>> File would be opened by this window. Sometimes I want to open it by
>> other frame.  It is good if which window to open, is selectable after
>> showing context-menu. I do not know how to do so.
> 
> Sorry, I don't understand what menu do you mean, maybe in Dired mode?

`ffap-at-mouse’ will open a file under pointer on `this window’.
Randomly I want to open it by `other frame’.
It’s good if I can choose open the file on `this window’ or `other frame’.
Is there a way to detect meta key pressed when select one of menu items?

>> * Details
>> 
>> It is handy to have buffer menu when right click mode bar.
> 
> I don't see where buffer-menu-open currently is used on the mode-line.
>> (define-key map [remap buffer-menu-open] context-menu-entry)
> 
> This gives the error "void-variable map".


This suggestion may be unrelated to context-menu.
On mode bar, both mouse-1 and mouse-3 switches buffer. 
I think mouse-3 should show something like (mouse-buffer-menu-map).

>> Also it is handy to have frame menu when right click title bar.
> 
> I think this is a good idea.
> 
>> I do not know how to do so.
> 
> I do not know how to do this for the frame title bar.
> But currently I'm doing this for the tab bar.

OK.

>> Also it is nice to show word candidates by ispell when click a word.
> 
> Maybe like flyspell-mode?

I have an idea. Possibly, send patch in the future.

>> ** context-menu-region
>> 
>> All commands belong to `Edit' in menu bar.
>> I think `context-menu-edit' sounds better.
> 
> I already tried to use your idea to name it `context-menu-edit'.
> But the problem is that other functions like context-menu-undo are also
> related to editing.  OTOH, some items in context-menu-region don't do
> editing such as "Select All" is not editing, "Copy" is not editing, etc.
> 

>> Isn't it better to use `menu-bar-edit-menu' as a source rather than
>> create a menu from scratch?
> 
> I already tried this idea but this menu is already available
> in the global menu that already can be enabled by adding
> context-menu-global to context-menu-functions.
> But maybe `context-menu-edit' could be added as well
> from `menu-bar-edit-menu'.


OK.  I only wanted to suggest reducing maintenance cost.

> 
>> On paste when there is a region and delete-selection-mode is t, the
>> region should be replaced by the text.
> 
> Please explain how the region should be replaced by the text,
> when mouse-yank-at-click or mouse-yank-primary is used
> to paste where the mouse is clicked.  Should it delete the region
> and paste where mouse is clicked on another part of the buffer?
> What if the mouse is clicked in another window?

When there is a region and yank text by `C-y’, the text would
be replaced.

I think when there is a region and point in on region, region
should be replaced by text.  No?

>> ** no multiple horizontal lines
>> 
>> Sometimes I see double lines on the context menu.  I think that there is
>> no useful case to have double lines.  To allow only one horizontal line
>> would look cool.
> 
> Right, double separators should be removed.

OK.

>> ** reuse existing menu
>> 
>> I cannot figure out how to include pre-existing menu such for
>> (mouse-buffer-menu-map).  To lean how to manipulate menu is not easy.
>> It's nice to have an example something like below (does not work).
>> 
>>  (defun context-menu-buffer (menu)
>>  "Add a buffer menu entry to MENU."
>>    (let ((map (mouse-buffer-menu-map)))
>>      (define-key-after menu [buffer] map))
>>    menu)
> 
> Adding the existing menu is not easy.  There are some examples in
> context-menu-global, context-menu-local, context-menu-minor.

OK.  I did not know it is not easy.
I cannot find guid line how the menu should be created.
Do you know where to look?