GNU bug report logs - #57266
Maintaining the base_line_number cache

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57266 <at> debbugs.gnu.org
Subject: bug#57266: Maintaining the base_line_number cache
Date: Mon, 22 Aug 2022 08:41:41 -0400

>> I think the `!just_this_one_p` is important enough since the test isn't
>> needed, and it otherwise prevents caching the base_line when a buffer is
>> displayed in more than 1 window, which can slow down redisplay noticeably
>> in such a case.
>
> I didn't just mean just_this_one_p thingy, I meant all the changes
> that attempt to somehow "clean up" the use of the line-number cache.
> Why do we have to do that at all?  This stuff is not too complex, and
> it works for ages!  Isn't the fact that we find more and more small
> issues with the changes telling you something?

Yes, it's telling me that the code is a mess and I'm trying to fix it by
documenting what is actually needed.

>> It's not necessary because the only way the cache can be out of date
>> if when either clipping or buffer text or w->contents is changed and
>> that is already taken into account.
> What about the w->last_overlay_modified part, which window_outdated
> takes into account?

Overlays have no influence over the line number count, because the
base_line cache only counts real \n characters, not display lines.

> Once again, I'd prefer that we didn't touch working code, which

Code we don't dare to change is a problem we should fix.

> nowadays supports at least 3e features: the mode-line display, the
> display-line-numbers mode, and the line-number-at-pos function and its
> callers.

AFAIK it's not used (yet) in `line-number-at-pos`.


        Stefan

Previous Next

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