GNU bug report logs -
#78474
31.0.50; Wrong char insertion in rxvt
Previous Next
Full log
Message #287 received at 78474 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.