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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Samuel Thibault <samuel.thibault <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: Mon, 21 Jul 2025 18:47:07 +0300

> Date: Mon, 21 Jul 2025 17:37:02 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>,
> 	Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> 
> Hello,
> 
> Robert Pluim, le lun. 21 juil. 2025 16:53:34 +0200, a ecrit:
> > I honestly donʼt know if the performance optimization makes any
> > difference these days,
> 
> I don't think it will be actually measurable by any mean. The
> optimization we are talking about saves transmitting one byte while
> making the terminal interpret one more character sequence (tab+backspace
> vs arrow-right). In the common case of running emacs in a terminal, I'd
> rather guess that the overhead of the additional character sequence
> interpretation is most probably way more expensive than the transmission
> of an additional byte.

There's no interpretation.  The bytes are sent and executed by the
video driver.  Using tabs can save several spaces or several bytes of
a cursor movement command, and that is not a trivial difference.

So let's please not argue about this.  We can only turn this feature
on by default if Emacs can tell, with a sufficient degree of
certainty, that a screen-reading software is in use.  Otherwise, users
will need to enable this manually.

Previous Next

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