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

Previous Next

Full log

Message #380 received at 78474 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#78474: 31.0.50; Wrong char insertion in rxvt
Date: Wed, 23 Jul 2025 13:34:03 +0200

Eli Zaretskii, le mer. 23 juil. 2025 14:24:09 +0300, a ecrit:
> > Date: Tue, 22 Jul 2025 20:20:39 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> > 	78474 <at> debbugs.gnu.org
> > 
> > Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> > > > If I had a text that explicitly says that \t produces content, it
> > > > would be way easier to fix this on the vte side. For now, we have
> > > > been stuck for a *decade* there.
> > > 
> > > I think I understand, but the refusal of the vte developers to provide
> > > some solution doesn't mean it becomes the responsibility of Emacs to
> > > solve that, does it?
> > 
> > emacs is the only program we know that uses such \t\b trick and thus
> > poses cursor position problem.
> 
> Emacs is not just any program.  There's nothing wrong in changing the
> behavior of vte to cater to Emacs, at least as an option.  You expect
> us to do the same.

And that's why Sébastien was previously talking about RFCs, because
they are the typical documents that people follow to make programs
behave correctly altogether.

Samuel

Previous Next

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