Subject: bug#56682: locked narrowing

From: Gregory Heytings <[email-masked]>
Date: Tue, 16 Aug 2022 21:18:21 +0000

>
> Adding such a LOCK argument might be a good idea, actually, since ELisp 
> packages may also want to impose restrictions on widening (see my recent 
> message to `emacs-devel` about ELisp support for locked narrowing).
>

It might be a good idea indeed.  I did not have an immediate need for it, 
and did not see how to do it (because of the unbalanced specbind).

>
> Why leave the `specbind (Qrestrictions_locked, Qt)` out of the function 
> when you've already included the 3 calls to `record_unwind_protect`? The 
> 4 share the same requirements (because `specbind` pushes on the 
> `specpdl`, just like `record_unwind_protect`).  They naturally belong 
> together.
>

They do indeed, and that's actually what the original code did, but I was 
told that it was better to not do that.

>
> Also, a function that sometimes pushes to `specpdl` (and hence requires 
> the caller to do the `SPECPDL_INDEX + unbind_to` dance) and sometimes 
> not, depending on some value of its argument is a bit unnatural (it 
> complicates the reasoning when we try and convince ourselves that the 
> stack discipline of the specpdl is obeyed).  So I'd recommend you split 
> the function into two: a first one that only does the narrowing itself 
> and a second one which calls the first plus unconditionally does the 
> `specbind+record_unwind_protect`.
>

Okay, thanks.  That's probably another way to do it, indeed.

>> Not "a lot", but indeed there's some redundancy there that could have 
>> been avoided.
>
> AFAICT it's more than half of the code of each branch.
>

That's still not "a lot", there are 12 statements in total in the two 
branches.  And they have 3 statements in common...