bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Matt Bisson
Subject: bug#49253: 27.2; Emacs non-responsive when pasting into terminal-mode
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)
diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 5ed4e46e0a5..117bd131123 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -149,7 +149,8 @@ xterm--suspend-tty-function
 ;; looping on read-key and buffering input for later processing.

 (defun xterm-translate-bracketed-paste (_prompt)
-  (vector (list 'xterm-paste (xterm--pasted-text))))
+  (unless (and (eq major-mode 'term-mode) (term-in-char-mode))
+    (vector (list 'xterm-paste (xterm--pasted-text)))))

 (defvar xterm-rxvt-function-map
   (let ((map (make-sparse-keymap)))


On Fri, Dec 8, 2023 at 2:06 PM Matt Bisson <bisson.m@gmail.com> wrote:
>
> 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 <bisson.m@gmail.com> 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 <larsi@gnus.org> wrote:
>>>
>>> Matt Bisson <bisson.m@gmail.com> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]