GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Mon, 18 Jul 2022 17:07:26 +0000

>
> Not that I know of, no.  At least we don't keep this information 
> anywhere, even after we compute it for display.  In particular, if we 
> never displayed some part of the buffer since the beginning of the 
> session, we don't even know what fonts that could require.  And 
> computing that takes the same effort as displaying the text in the first 
> place.
>
> [...]
>
> That translates into a lot of potential issues.  First, you need a 
> fixed-pitch default face, right?  Then you need to ensure we don't have 
> any characters that are displayed by fonts other than the default face's 
> font, either because these characters aren't supported by the font, or 
> required by some non-default face, or even because some face requires 
> the default font, but with a different weight or size or slant.  You 
> also need to make sure there are no overlays in the buffer, and no 
> 'display' or invisible properties.  Maybe also that tab-width is at its 
> default value?  Maybe there's more.
>

Thanks for the detailed explanation.  It's clear that computing that 
information would largely outweigh its potential benefit, so I'll have to 
live without that potential optimization.

Previous Next

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