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

Previous Next

Full log

View this message in rfc822 format

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

Eli Zaretskii, le mer. 23 juil. 2025 13:50:24 +0300, a ecrit:
> > 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?

The whole set of packages that depend on libvte is:

Package: aghermann
Package: astroidmail
Package: blackbox-terminal
Package: cairo-dock-plug-ins
Package: cdebconf-terminal
Package: cdebconf-terminal
Package: cherrytree
Package: easyssh
Package: emacs-libvterm
Package: geany-plugins
Package: gedit-plugins
Package: genius
Package: gnome-boxes
Package: gnome-builder
Package: gnome-console
Package: gnome-terminal
Package: gtk-d
Package: gtkterm
Package: haskell-gi-vte
Package: lxterminal
Package: mate-terminal
Package: mssh
Package: neovim
Package: pluma-plugins
Package: ptyxis
Package: qemu
Package: rasmol
Package: remmina
Package: sakura
Package: synaptic
Package: terminus
Package: termit
Package: tilda
Package: tilix
Package: timeshift
Package: virt-viewer
Package: xcfa
Package: xfce4-terminal

Among which some are indeed terminals that run a shell, others use it to
display information, etc.

My point is: there is a dozen now, and there will be more later. We
can't rely on knowling the list.

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

Because of the details below.

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

Again, the question is: what is the expected behavior of 

echo 'a\ta'

And yes, a lot of terminals just announce themselves as xterm in TERM,
that's how it is nowadays. Fighting it is a lost cause nowadays.

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

For that case, yes.

Samuel

Previous Next

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