bug#49253: 27.2; Emacs non-responsive when pasting into terminal-mode

[Matt Bisson]

TL;DR: It works!

> I don't think this is the right approach.

Totally! :)  The patch was definitely not a serious suggestion of what
should be submitted, but just a demonstration that the interplay
between the two functions is causing the issue, and it can be solved
by touching only that.  I haven't built up the knowledge of how these
events function like you have, and was hoping you'd teach me a bit in
response, and you did!

The solution works for XTerm pasting into a scratch buffer, into a
term buffer with line-mode enabled, and most notably, with char-mode
enabled.  As I use term-mode for basically everything I do in a
terminal on a daily basis, this will make my life significantly nicer,
so thanks for the fix!

On Sat, Dec 9, 2023 at 4:38 PM Jared Finder <jared@finder.org> wrote:
>
> On 2023-12-09 03:10, Eli Zaretskii wrote:
> > Jared, can I ask you to look into this and share your thoughts and
> > comments to the proposed change?  TIA.
> >
> >> Cc: 49253@debbugs.gnu.org
> >> From: Matt Bisson <bisson.m@gmail.com>
> >> Date: Fri, 8 Dec 2023 15:35:36 -0500
> >>
> >> Right, so this silly little fix works, but it's an obvious hack.  I
> >> clearly don't know enough about how the key-bindings work, because I
> >> would have expected those set by term-mode to override those in the
> >> global keybindings (from xterm.el), but they don't.  The xterm.el one
> >> runs first.  Here's the diff:
> >>
> >> diff --git a/lisp/term.el b/lisp/term.el
> >> index 81746e0c20d..e047fa767e8 100644
> >> --- a/lisp/term.el
> >> +++ b/lisp/term.el
> >> @@ -956,6 +956,7 @@ term-raw-map
> >>      (define-key map [?\C- ] #'term-send-C-@)
> >>      (define-key map [?\C-\M-/] #'term-send-C-M-_)
> >>      (define-key map [?\C-\M- ] #'term-send-C-M-@)
> >> +    (define-key map "\e[200~" #'term--xterm-paste)
> >>
> >>      (when term-bind-function-keys
> >>        (dotimes (key 21)
>
> Thanks for the investigation.  I don't think this is the right approach.
>   The xterm escape codes all go through input-decode-map and I would
> expect to preserve that.
>
> Looking at code, the current behavior in xterm.el is the following:
>
> Step 1: \e[200~ is put on input-decode-map, using
> xterm-translate-backeted-paste to decode.
>
> Step 2: The function xterm-translate-bracketed-paste reads the pasted
> text and creates an event (xterm-paste "PASTED TEXT HERE")
>
> Step 3: Globally, the event xterm-paste is bound to the function also
> named xterm-paste, which grabs the pasted text and puts it on the kill
> ring, then runs the function insert-for-yank.
>
> Step 3a: In Term mode, the event xterm-paste is instead bound to the
> function term--xterm-paste.  However, instead of reading the pasted text
> off the event, it calls (xterm-pasted-text) again.
>
> I think the correct fix is to change term--xterm-paste to read the
> pasted text off of the event generated in Step 2.  So something like the
> following (a real fix would add error checking like in xterm-paste):
>
> (defun term--xterm-paste (event)
>    "Insert the text pasted in an XTerm bracketed paste operation."
>    (interactive "e")
>    (term-send-raw-string (nth 1 event)))
>
> Matt, can you try this change locally?  It worked for me.
>
>    -- MJF