GNU bug report logs - #34476
fluffy whitespace in the mode-line, despite it running off the screen

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: contovob <at> tcd.ie, 34476 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#34476: fluffy whitespace in the mode-line, despite it
 running off the screen
Date: Sat, 08 Aug 2020 12:48:30 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: contovob <at> tcd.ie,  34476 <at> debbugs.gnu.org,  jidanni <at> jidanni.org
> Date: Sat, 08 Aug 2020 11:11:48 +0200
> 
> > I don't want to argue with your reading of the code.  I'm saying that
> > the natural way of removing extra spaces is to post-process the glyphs
> > produced by display_string directly; anything else is IMO inelegant
> > and unnatural.
> 
> I just don't understand why -- pre-processing the string is more
> efficient and...  normal...  than post-processing the glyphs, surely?
> Preparing a string and then calling the display functions is what we do
> all over the place.

You don't really have a string here, you need to generate it first,
from several individual C and Lisp strings, and from :eval
expressions.  Generating it involves employing some of the same code
that display_mode_element calls, but in a context that was not meant
for display, so I'm not even sure the result will be the same (i.e. we
risk inadvertent changes in behavior).  We will also be consing at
least one more Lisp string, so displaying a mode-line under this
option will produce more garbage.  All of these are IMO disadvantages
that don't exist in my proposal.

And I don't see why post-processing would be less efficient.  Can you
explain why you think so?

Previous Next

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