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

From: Samuel Thibault <[email-masked]>
Date: Tue, 22 Jul 2025 19:49:31 +0200

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.

> 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.

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.

> > 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.

Samuel