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

Previous Next

Full log

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

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

Samuel Thibault (2025/07/22 20:20 +0200):
> 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.

And the road down to this findking has been quite longbecause we first
had to fix all the problems in vte, which took the decade Samuel
mentionned and is still not integrated, before then realising that
although we get a nice behaviour with editors suchas vimor joe, that
didn't hold for Emacs. And it took another bunch of time and brain
resources to figure out what was going on there. Credit again goes to
Samuel for that.

A very friendly note to the Emacs maintainers whoare reading this
thread: my intention is *not* tomake you feel bad. I appreciate that you
are here, discuss, genuinely try tounderstand. Precisely, to broaden
your understanding, I would like to explain one point you may be missing
and it's certainly not your faul if you are missing it, but please read
me and think over it.

The discussion we are currently having with you, wehave to  haveon
dozens and dozens of projects. So yes, having to have such discussions
again and again is super tiring and it's kind of a miracle that people
like Samuel are still there, although not directly concerned.

We try to suggest solutions that are viable, as "main stream" as
possible because we believe that the best thing that can happen to
accessibility is that it gets integrated to programs as readily as
possible.

As much as possible, we would like to avoid that accessibility has to go
to dedicated code paths because we know from experience tat, in the long
run, such code paths will receive less testing and maintenance
attenition.

And I think this becomes even more true if, as it seems to be the case
here, the proposed code is actually cleaner, more efficient and more
standard than what was done before. Tome, the fact that the former code
has not had to change for decades does not mean it shouldn't be changed
now.

Previous Next

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