Subject: bug#78474: 31.0.50; Wrong char insertion in rxvt

From: Eli Zaretskii <[email-masked]>
Date: Wed, 23 Jul 2025 13:50:24 +0300

> Date: Tue, 22 Jul 2025 19:49:31 +0200
> From: Samuel Thibault <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> 
> 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.