bug#56682: locked narrowing

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: dgutov@yandex.ru,  56682@debbugs.gnu.org,  gregory@heytings.org
> Date: Wed, 17 Aug 2022 11:58:32 -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?

> [ 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?