GNU bug report logs - #56682
Fix the long lines font locking related slowdowns

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 56682 <at> debbugs.gnu.org, gregory <at> heytings.org, dgutov <at> yandex.ru
Subject: Re: locked narrowing
Date: Wed, 17 Aug 2022 13:58:21 -0400

>> >> - The problem I already mentioned: the cache seems to be
>> >>   maintained/flushed by the redisplay code, so when the function is
>> >>   called outside of redisplay I don't know if `w->base_line_number/pos`
>> >>   is still valid.
>> >
>> > So you are saying that any command which uses vertical-motion or more
>> > generally any of the move_it_* functions will work incorrectly when
>> > line numbers are on display?  I'm not aware of any such problems.
>> 
>> No, I'm sure the existing code somehow handles it right.  I just don't
>> know how.  I can't see anything in the code of `insert` (say) which
>> flushes `w->base_line_number` when needed, so there needs to be code
>> somewhere which flushes it more lazily before using that value.  I just
>> don't know where that code is and which data it uses to flush it.
>> For this reason I don't know under which condition I can make use of
>> `w->base_line_number`.
>
> Why can't you simply use the same code maybe_produce_line_number uses
> for that?

Because I can't find that code.  Apparently `maybe_produce_line_number`
just uses `w->base_line_number` whenever it's not 0, so apparently it's
set to 0 elsewhere.

[ BTW, apparently when `display_line_numbers_widen` is in use and the
  buffer is narrowed, we don't use that cache at all for
  `maybe_produce_line_number` (according to xdisp.c:24217).  IOW that
  cache always counts from BEGV, so we also need to check that BEGV is
  still the same as when the cache was filled.  I also can't see in
  `decode_mode_spec` where we check that the narrowing has changed
  before using the cached value.  All in all, I just don't understand
  how that cache is maintained.  ]

>> [ BTW, another hurdle if that the existing cache is linked to windows,
>>   whereas the actual info requested doesn't care about windows (as long
>>   as we count logical lines rather than screen lines) and would also
>>   make sense in a buffer that's not displayed at all.  This should
>>   usually not be a problem for nlinum-mode, tho it could happen
>>   when called from `font-lock-ensure`.  ]
> Why does it matter which line numbers you compute if they are never
> displayed?

They may be displayed at some other time: nlinum-mode won't be invoked
if that same portion of the buffer becomes visible later on (it's just
like font-lock: the highlighting applied stays until something like the
after-change-function causes it to be refreshed).


        Stefan

Previous Next

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