Subject: bug#56682: feature/improved-locked-narrowing 9dee6df39c: Reworked locked narrowing.

From: Eli Zaretskii <[email-masked]>
Date: Sat, 06 May 2023 09:26:40 +0300

> Date: Fri, 05 May 2023 21:29:16 +0000
> From: Gregory Heytings <[email-masked]>
> cc: [email-masked], [email-masked]
> 
> >> +      struct Lisp_Marker *begv
> >> +	= labeled_restrictions_get_bound (buf, true, true);
> >> +      struct Lisp_Marker *zv
> >> +	= labeled_restrictions_get_bound (buf, false, true);
> >
> > Why the strange design of having a function return a pointer to a 
> > 'struct Lisp_Marker'? why not return the marker itself instead?  (I 
> > realize that this was so in the code we already have, but I still don't 
> > understand why you did it that way, and prefer that function to return a 
> > marker instead.)
> >
> 
> Good question.  You mean that it would have been better to return a 
> Lisp_Object, right?  I don't recall exactly, I think it was because in the 
> calls to SET_BUF_BEGV_BOTH/SET_BUF_ZV_BOTH (which are the only places 
> where the return value of labeled_restrictions_get_bound are used) one can 
> use the pointer to a struct Lisp_Marker immediately, whereas a call to 
> XMARKER would have been necessary if a Lisp_Object had been used.

I'd prefer to use a marker there, but that can be a separate
changeset.

> > Is it okay for this function to return a position > POS, its input?
> 
> Unless I misunderstood something, it cannot, because find_newline1 is 
> called with end = pos and end_byte = pos_bytepos.

The logic is quite convoluted, so I think we should have an assertion
about this before the function returns, because callers depend on the
returned position not to exceed POS, AFAICT.

Please install this after fixing those nits, and please ack this time
after installing.

Thanks.