GNU bug report logs - #78474
31.0.50; Wrong char insertion in rxvt

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Samuel Thibault <samuel.thibault <at> gnu.org>
Cc: bzg <at> gnu.org, Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com,
 78474 <at> debbugs.gnu.org
Subject: Re: bug#78474: 31.0.50; Wrong char insertion in rxvt
Date: Wed, 23 Jul 2025 13:50:24 +0300

> Date: Tue, 22 Jul 2025 19:49:31 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, rpluim <at> gmail.com
> 
> Eli Zaretskii, le mar. 22 juil. 2025 18:47:18 +0300, a ecrit:
> > Btw, let me make sure I understand correctly: is screen-reading
> > software affected by this only on those two kinds of terminals (rxvt
> > and vte), where \t\b produces wrong output?
> 
> Yes. But vte happens to be the only terminal layer that implements
> accessibility. Screen readers cannot be used with all the others.
> 
> Seb Hinderer, le mar. 22 juil. 2025 18:05:14 +0200, a ecrit:
> > I am not completely sure and would rather let Samuel complete here. What
> > I know isthat libvte is used for several terminals so I expect all of
> > them to  be affected.
> 
> Yes, there is a dozen of those in Debian, at least.

Can you name them, please?

> > If only those two terminals are affected, both in the effect of the
> > cursor motion and what that does to screen readers, then we could
> > disable the \t\b sequence only for those two terminals.  Emacs can
> > look at the name of the terminal to decide what to do.
> 
> No, it cannot.

Why not?  Looking at the value of TERM is something Emacs already
does, because it needs to load a corresponding library from
lisp/term/.  So such a library would be a natural place to set this
variable if we decide to disable \t\b on thos specific terminals by
default.

> Eli Zaretskii, le mar. 22 juil. 2025 19:59:50 +0300, a ecrit:
> > > > Emacs can look at the name of the terminal to decide what to do.
> > > 
> > > Would that be ssh-proof?
> > 
> > You need to set TERM in the ssh session.
> 
> Yes, although libvte announces itself as xterm-256color.

So we could have a terminal which sets TERM=xterm-256color, but which
doesn't behave like xterm does?

> > > And what about running screen or tmux in such a terminal?
> > 
> > Again, TERM should be set.
> 
> In that case it's actually screen and tmux that interpret sequences, and
> TERM is then screen and tmux. And those happen not to be using the \t\b
> trick when re-displaying their output, so they "fix" the issue.

Thus no problem.

Previous Next

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