Re: New Context Menu

[Juri Linkov <juri@linkov.net>]

> The issue is that context menu is bound to an "unmodified" mouse
> event. If you try this on xterm:
>
> (global-set-key [down-mouse-1] 'mouse-buffer-menu)
> or
> (global-set-key [down-mouse-3] 'mouse-buffer-menu)
>
> Then you should notice the same issue.
>
> Or when I press C-<down-mouse-1> (shows the menu), then release control,
> and after that, release the mouse button: same behavior (menu disappears
> and/or selects). So emacs is receiving the "up-mouse-1" as an event in
> xterm. That's the issue.

If the menu doesn't disappear with

  (global-set-key [C-down-mouse-1] 'mouse-buffer-menu)

but disappears with

  (global-set-key [down-mouse-1] 'mouse-buffer-menu)

this means there is a bug in low-level xterm handling code.

BTW, while testing xterm for a short time, I found more bugs in xterm,
e.g. clicking [M-down-mouse-1] fails in xterm with:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  encode-coding-string(nil utf-8-unix)
  #f(compiled-function (type data) "Copy DATA to the X selection using the OSC 52 escape sequence.\n\nTYPE specifies which selection to set; it must be either\n`PRIMARY' or `CLIPBOARD'.  DATA must be a string.\n\nThis can be used as a `gui-set-selection' method for\nxterm-compatible terminal emulators.  Then your system clipboard\nwill be updated whenever you copy a region of text in Emacs.\n\nIf the resulting OSC 52 sequence would be longer than\n`xterm-max-cut-length', then the TEXT is not sent to the system\nclipboard.\n\nThis function either sends a raw OSC 52 sequence or wraps the OSC\n52 in a Device Control String sequence.  This way, it will work\non a bare terminal emulators as well as inside the screen\nprogram.  When inside the screen program, this function also\nchops long DCS s
 equences into multiple smaller ones to avoid\nhitting screen's max DCS length." #<bytecode -0x1b4ad63ac0b5ef21>)(SECONDARY nil)
  apply(#f(compiled-function (type data) "Copy DATA to the X selection using the OSC 52 escape sequence.\n\nTYPE specifies which selection to set; it must be either\n`PRIMARY' or `CLIPBOARD'.  DATA must be a string.\n\nThis can be used as a `gui-set-selection' method for\nxterm-compatible terminal emulators.  Then your system clipboard\nwill be updated whenever you copy a region of text in Emacs.\n\nIf the resulting OSC 52 sequence would be longer than\n`xterm-max-cut-length', then the TEXT is not sent to the system\nclipboard.\n\nThis function either sends a raw OSC 52 sequence or wraps the OSC\n52 in a Device Control String sequence.  This way, it will work\non a bare terminal emulators as well as inside the screen\nprogram.  When inside the screen program, this function also\nchops long
  DCS sequences into multiple smaller ones to avoid\nhitting screen's max DCS length." #<bytecode -0x1b4ad63ac0b5ef21>) (SECONDARY nil))
  #f(compiled-function (&rest args) #<bytecode 0x19ad559537b92ff3>)(SECONDARY nil)
  apply(#f(compiled-function (&rest args) #<bytecode 0x19ad559537b92ff3>) (SECONDARY nil))
  gui-backend-set-selection(SECONDARY nil)
  gui-set-selection(SECONDARY nil)
  mouse-drag-secondary((M-down-mouse-1 (#<window 1 on *scratch*> 153 (42 . 10) 16176 nil 153 (41 . 3) nil (35 . 7) (1 . 0))))
  funcall-interactively(mouse-drag-secondary (M-down-mouse-1 (#<window 1 on *scratch*> 153 (42 . 10) 16176 nil 153 (41 . 3) nil (35 . 7) (1 . 0))))
  command-execute(mouse-drag-secondary)

> Just a question:
>
> If the context-menu-mode is a minor mode. Why the bindings are not added
> in a context-menu-mode-map and avoids manually saving the -old commands?
>
> Is there an issue with that?

Thanks for the idea, this should work.