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

Previous Next

Full log

Message #221 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: larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Thu, 07 Jul 2022 22:05:18 +0300

> Date: Thu, 07 Jul 2022 18:46:53 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> By the way, that's a problem I see with the idea of computing the 
> narrowing dynamically by multiplying window-body-width by 
> window-total-height.  If a buffer is displayed in two windows, a small one 
> and a larger one, and we navigate the buffer in the smaller one, the 
> larger one will display only a part of what it could display.

If you are saying the above in the context of my proposal to implement
the "narrowing" such that it's only visible to redisplay, then I see
no problem: redisplay_window is called separately for each window, and
so the "narrowing" will be computed separately and differently for
each one of them.  (Which might, btw, mean we will see each window
with slightly different fontifications, if we limit font-lock to the
same restriction.  Something to keep in mind for later, I suppose.)

If you are saying the above in the context of the current
auto-narrow-mode, then it shouldn't be hard to loop over all the
windows showing the same buffer and choose the widest narrowing of
them all.  Or am I missing something?

Previous Next

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