bug#56682: locked narrowing

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> >> Last time I looked at it, I couldn't quite understand how the cache
>> >> works there, so I wasn't sure how to make sure it returns valid
>> >> information even if called outside of redisplay.
>> > Looking at what maybe_produce_line_number does doesn't help?
>> 
>> I see two problems:
>> 
>> - 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`.

>> - The fact that this uses line numbers counted from BEGV whereas nlinum
>>   counts from BEG.
>
> I think you missed the display-line-numbers-widen variable and its
> effect.

Ah, indeed, thanks, that helps.
[ 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`.  ]


        Stefan