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

Previous Next

Package: emacs;

Reported by: Bastien Guerry <bzg <at> gnu.org>

Date: Sat, 17 May 2025 22:56:02 UTC

Severity: normal

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

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: Mon, 21 Jul 2025 18:00:47 +0200
[Message part 1 (text/plain, inline)]
Eli Zaretskii, le lun. 21 juil. 2025 18:47:07 +0300, a ecrit:
> > 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.

Of course there is.

> The bytes are sent and executed by the video driver.

No, it's the terminal layer.

> Using tabs can save several spaces or several bytes of
> a cursor movement command, and that is not a trivial difference.

But a right-arrow interpretation is quite more trivial than a tab
interpretation plus backspace interpretation.

Really, please come up with actual figures. We can't be trading
performance for accuracy without significant figures.

I have tried the attached test which reproduces both ways and reports
the time to achieve one million iteration, on my system:

- with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
- with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
  ~2.0s.

So on my system at least the "optimized" way is actually slower.

Samuel
[test.c (text/x-csrc, attachment)]

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.