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 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 wrote: > >> Matt Bisson 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 >> >