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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Tue, 19 Jul 2022 15:48:39 +0300

> Cc: 56393 <at> debbugs.gnu.org
> Date: Tue, 19 Jul 2022 08:53:12 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> 
> If a buffer with long lines is never or not yet displayed, the specific 
> optimizations do not take place.  That was a very important if not 
> critical improvement, because Emacs may internally use buffers with long 
> lines, and they should be entirely unaffected by that change.  (For 
> example, the newsrc.eld file used internally by Gnus contains one such 
> long line; if the same temporary restrictions were used in that buffer, it 
> is possible that Gnus would not work correctly anymore.)
> 
> As far as I can tell, iterators are used in such buffers, too, but they 
> are not fontified.  Fontification happens only when necessary, that is, 
> when the buffer is actually displayed.

Not sure what you mean by "fontification" here.  AFAIR, when iterators
are used in any buffer, Emacs always calls jit-lock, and then always
resolves the faces produced by jit-lock (via font-lock).  Those faces
are never displayed, of course, if the buffer has no window.

I agree that functions that use iterators should rarely be called in
buffers that aren't displayed, but that still can happen.  Stuff like
vertical-motion, window-text-pixel-size, etc.

Previous Next

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