Subject: Re: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.

From: Stefan Monnier <[email-masked]>
Date: Fri, 30 Dec 2022 12:01:48 -0500

>> - I don't see any mention of those new features in etc/NEWS.
> Yes, that's something I still need to do.

I think it's quite urgent (it's all too easy to forget: better a subpar
entry than no entry at all).

>> - In `nlinum--line-number-at-pos`, I want to circumvent the narrowing lock
>> due to long lines (since its performance is only affected by buffer size
>> but not by line length), but I can't see how to do that. The only
>> primitive I see which would let me get out of the locked narrowing is
>> `narrowing-unlock` but:
>>
>> - I don't know which tag(s) to use.
>
> That depends on the place where 'nlinum--line-number-at-pos' is called, or
> IOW where/by which function the narrowing was locked, or IOW again which tag
> was used to unlock the narrowing.

Hmm... I understand that part but that doesn't tell me how I (the coder)
or the function can find out which tag to use :-(

>> - I don't want to remove the lock, I only want to circumvent it
>> temporarily, and I can't see how to re-install a lock after removing it
>> (`narrowing-lock` doesn't fit the bill because I don't know the bounds of
>> the lock and because that would not preserve the stacking order of locks).
>
> That's part of the improvements you suggested, and I implemented.
> Simply do a:
>
> (save-restriction
>   (narrowing-unlock 'the-appropriate-tag)
>   (widen)
>   ... your code ...)
>
> Upon return from the save-restriction, the narrowing locks are restored.

Ah, great, I had missed that, thanks.
So the remaining issue is to find the (set of) tags to unlock.

Looking more at the code, I have another question: why is
`narrowing_locks` a global alist indexed by buffers, instead of being
a buffer-local variable?

        Stefan