bug#56682: locked narrowing

[Gregory Heytings]

> 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...