bug#44908: emacs -nw: view-lossage polluted by termcap / terminfo jazz

bug#44908: emacs -nw: view-lossage polluted by termcap / terminfo jazz

[積丹尼 Dan Jacobson]

$ emacs -Q -nw
abc123
C-h l

shows:

 ESC [ > ESC [ > 4 1 ; 3 6 2 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 0 / 0 0 0 0 / 0 0 0 0 ESC \ a ;; self-insert-command
 b			;; self-insert-command
 c			;; self-insert-command
 1			;; self-insert-command
 2			;; self-insert-command
 3			;; self-insert-command
 C-h l			;; view-lossage

Notice the super-barfy first line?

The defendant swears he did not type that.

All he typed was the "a".

So please keep your termcap junk to yourself and don't pollute the C-h l
output.

> Well, we need to intiatialze the terminal. emacs -nw is for engineers
> who are used to bugs anyway.

Yeah, but as you see, you are "not in control of your bladder."

If you were, then the first line wouldn't shove the the innocent user's
"a ;; self-insert-command"
all the way to the right.

> Well it is just the first line of the evening. Surely they will type
> more before wanting to hit C-h l. That way they usually won't notice
> the bug. In fact if they type just a couple of lines of text then that
> jazz will be pushed so far up that, well, let's just say nobody will
> ever know.

emacs-version "27.1"

bug#44908: emacs -nw: view-lossage polluted by termcap / terminfo jazz

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> shows:
>
>  ESC [ > ESC [ > 4 1 ; 3 6 2 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 0 / 0 0 0
> 0 / 0 0 0 0 ESC \ a ;; self-insert-command

This bug is still present in Emacs 28.  Steps to reproduce:

emacs -Q -nw -f view-lossage

I get a *Help* buffer that has:

 ESC [ > ESC [ > 6 5 ; 6 2 0 1 ; 1 c ;;

(This is on Debian/bullseye.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44908: emacs -nw: view-lossage polluted by termcap / terminfo jazz

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 29 Nov 2020 11:23:06 +0100
> Cc: 44908@debbugs.gnu.org
> 
> >  ESC [ > ESC [ > 4 1 ; 3 6 2 ; 0 c ESC ] 1 1 ; r g b : 0 0 0 0 / 0 0 0
> > 0 / 0 0 0 0 ESC \ a ;; self-insert-command
> 
> This bug is still present in Emacs 28.  Steps to reproduce:
> 
> emacs -Q -nw -f view-lossage
> 
> I get a *Help* buffer that has:
> 
>  ESC [ > ESC [ > 6 5 ; 6 2 0 1 ; 1 c ;;

What do you have in recent-keys in that case?

bug#44908: emacs -nw: view-lossage polluted by termcap / terminfo jazz

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I get a *Help* buffer that has:
>> 
>>  ESC [ > ESC [ > 6 5 ; 6 2 0 1 ; 1 c ;;
>
> What do you have in recent-keys in that case?

emacs -Q -nw --eval '(message "%s" (recent-keys))'

gives me the following *Messages*:

[27 91 62 27 91 62 54 53 59 54 50 48 49 59 49 99]

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44908: emacs -nw: view-lossage polluted by termcap / terminfo jazz

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 44908@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Sun, 29 Nov 2020 17:21:20 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I get a *Help* buffer that has:
> >> 
> >>  ESC [ > ESC [ > 6 5 ; 6 2 0 1 ; 1 c ;;
> >
> > What do you have in recent-keys in that case?
> 
> emacs -Q -nw --eval '(message "%s" (recent-keys))'
> 
> gives me the following *Messages*:
> 
> [27 91 62 27 91 62 54 53 59 54 50 48 49 59 49 99]

Does the below fix the problem?  (But maybe we should still arrange
for recording these events in the dribble file? or is it impossible to
have dribble active at this point?)

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 1a727e3..7094100 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -767,7 +767,8 @@ xterm--read-event-for-query
 By not redisplaying right away for xterm queries, we can avoid
 unsightly flashing during initialization. Give up and redisplay
 anyway if we've been waiting a little while."
-  (let ((start-time (current-time)))
+  (let ((start-time (current-time))
+        (inhibit--record-char t))
     (or (let ((inhibit-redisplay t))
           (read-event nil nil xterm-query-redisplay-timeout))
         (read-event nil nil

bug#44908: emacs -nw: view-lossage polluted by termcap / terminfo jazz

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Does the below fix the problem?

Yes, that fixes the problem.

> (But maybe we should still arrange for recording these events in the
> dribble file? or is it impossible to have dribble active at this
> point?)

Hm...  is it useful to have the events in the dribble file?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44908: emacs -nw: view-lossage polluted by termcap / terminfo jazz

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 44908@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Mon, 30 Nov 2020 11:19:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does the below fix the problem?
> 
> Yes, that fixes the problem.

Thanks, installed on the emacs-27 branch.

> > (But maybe we should still arrange for recording these events in the
> > dribble file? or is it impossible to have dribble active at this
> > point?)
> 
> Hm...  is it useful to have the events in the dribble file?

They are not events, they are responses by the terminal emulator to
our queries about its capabilities.  Emacs cannot distinguish between
such characters and those the user types, as they are read in the same
way.

Anyway, I convinced myself that the dribble file cannot be open at
this point, since all the functions that use
xterm--read-event-for-query do that during terminal initialization.

So I'm closing this bug report.