[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56682: locked narrowing
From: |
Stefan Monnier |
Subject: |
bug#56682: locked narrowing |
Date: |
Wed, 17 Aug 2022 13:58:21 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
>> >> - 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
- bug#56682: locked narrowing, (continued)
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing,
Stefan Monnier <=
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/17
- bug#56682: locked narrowing, Stefan Monnier, 2022/08/17
- bug#56682: locked narrowing, Eli Zaretskii, 2022/08/18
- bug#56682: locked narrowing, Gregory Heytings, 2022/08/20