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

From: Matt Bisson <[email-masked]>
Date: Fri, 8 Dec 2023 14:06:05 -0500

I've finally had some time to look at this and what's happening is
term/xterm.el is fighting with term.el.  The bracketed paste command comes
in with "\e[200~", arrives in term/xterm.el's xterm--pasted-text function
first.  It correctly reads the text from the clipboard.  This is because
xterm-translate-bracketed-paste is registered as a key binding for
[xterm-paste] (or "\e[200~" on RXVT).

Immediately thereafter, term--xterm-paste in term.el notices the
[xterm-paste] key as well (it has also registered a binding for "raw"
mode), and begins the same process of xterm--pasted-text.  At this point,
there's nothing to read from read-event, and it hangs for
most-positive-fixnum (basically, forever).

So this is the root cause analysis.  Unfortunately, naively removing the
key binding from term.el does not work, because the pasted text must be
inserted via term-send-raw-string.

-Matt

On Sat, Jul 16, 2022 at 3:13 PM Matt Bisson <[email-masked]> wrote:

> For sure.  Even in emacs 28.2, if I want to paste something into the
> terminal buffer, I have to switch to line mode, and back when I'm done.
> You just can't paste into the terminal buffer in terminal emacs in key mode.
>
> On Sat, Jul 16, 2022, 8:21 AM Lars Ingebrigtsen <[email-masked]> wrote:
>
>> Matt Bisson <[email-masked]> writes:
>>
>> > I have observed this behavior from MacOS, with an Emacs running either
>> > locally on MacOS, or over SSH (running on Linux).  Without any
>> > modifications, a -Q invocation causes "xterm--pasted-text: Failed
>> > select: Invalid argument", but without -Q it simply hangs.
>>
>> (I'm going through old bug reports that unfortunately weren't resolved
>> at the time.)
>>
>> Are you still seeing this problem in recent Emacs versions?
>>
>> --
>> (domestic pets only, the antidote for overdose, milk.)
>>    bloggy blog: http://lars.ingebrigtsen.no
>>
>