GNU bug report logs -
#78474
31.0.50; Wrong char insertion in rxvt
Previous Next
Full log
View this message in rfc822 format
> Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, rpluim <at> gmail.com,
> samuel.thibault <at> gnu.org
> Date: Tue, 22 Jul 2025 17:46:35 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Backward-compatibility matters suggest to continue to emit exactly the
> > same thing and the possibility to disable the problematic sequence but,
> > as I explained earlier in this thread, I really findthis painful and
> > unfair to people who already have to tinker with everything.
> >
> > Can we please consider makingthe new style the default and provide the
> > option to re-enable the sequence if there are people forwhom it
> > actuallymakes a difference?
>
> That's what we are discussing. We are not done yet. In fact, we
> don't even have a working agreed-upon patch which implements the
> request when \t\b sequences are disabled. The question of the default
> behavior will become relevant once we are past that.
>
> So please be a bit more patient while we discuss this.
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? Or do other terminals,
where the above sequence is processed correctly, also dupe screen
readers into reading incorrect content?
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.
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.