GNU bug report logs - #12354
24.2; garbage inserted at the beginning of the buffer even when xterm-extra-capabilities is t

Previous Next

Package: emacs;

Reported by: Vincent Lefevre <vincent <at> vinc17.net>

Date: Wed, 5 Sep 2012 11:18:02 UTC

Severity: normal

Tags: fixed

Found in version 24.2

Done: Noam Postavsky <npostavs <at> users.sourceforge.net>

Bug is archived. No further changes may be made.

Full log


Message #29 received at 12354 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: Glenn Morris <rgm <at> gnu.org>, 12354 <at> debbugs.gnu.org
Subject: Re: bug#12354: 24.2;
 garbage inserted at the beginning of the buffer even when
 xterm-extra-capabilities is t
Date: Mon, 29 Jun 2015 09:12:01 -0400
> In fact, reportBackground also yields the garbage problem.
> So, there's a bug here:

>     (when (memq 'reportBackground xterm-extra-capabilities)
>       (xterm--query "\e]11;?\e\\"
>                     '(("\e]11;" .  xterm--report-background-handler))))

> If I understand correctly, there's a timeout here, but since the
> feature is claimed to be supported, the timeout should be removed.

The timeout is present because we prefer having garbage in those
(presumably rare) cases where the terminal answers too late, over having
Emacs hang forever (tho it's not a hard-hang) when the terminal doesn't
understand the request.

You try the patch below, and set xterm-query-timeout to some value of
your choosing (e.g. nil).


        Stefan


diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 45da1bd..54c46de 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -688,6 +688,10 @@ string bytes that can be copied is 3/4 of this value."
           ;;(xterm--init-activate-get-selection)
           (xterm--init-activate-set-selection))))))
 
+(defvar xterm-query-timeout 2
+  "Seconds to wait for an answer from the terminal.
+Can be nil to mean \"no timeout\".")
+
 (defun xterm--query (query handlers &optional no-async)
   "Send QUERY string to the terminal and watch for a response.
 HANDLERS is an alist with elements of the form (STRING . FUNCTION).
@@ -696,7 +700,8 @@ We run the first FUNCTION whose STRING matches the input events."
   ;; rather annoying (bug#6758).  Maybe we could always use the asynchronous
   ;; approach, but it's less tested.
   ;; FIXME: Merge the two branches.
-  (if (and (input-pending-p) (not no-async))
+  (if (and (or (null xterm-query-timeout) (input-pending-p))
+           (not no-async))
       (progn
         (dolist (handler handlers)
           (define-key input-decode-map (car handler)
@@ -714,7 +719,7 @@ We run the first FUNCTION whose STRING matches the input events."
       (let ((handler (pop handlers))
             (i 0))
         (while (and (< i (length (car handler)))
-                    (let ((evt (read-event nil nil 2)))
+                    (let ((evt (read-event nil nil xterm-query-timeout)))
                       (or (eq evt (aref (car handler) i))
                           (progn (if evt (push evt unread-command-events))
                                  nil))))

> However it is not passed by default via SSH,

Ah, indeed, that's my case: I almost only use "-nw" in an SSH session.


        Stefan




This bug report was last modified 7 years and 163 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.