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

[Gregory Heytings]

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

Can you confirm that the attached patch is what you would prefer?  IMHO it 
is better/clearer to have a single call to XMARKER in 
'labeled_restrictions_get_bound', instead of having to repeat it 
everywhere its return value is used.  The price is indeed that the 
signature of that (internal) function is unusual.  (Note that we cannot 
wrap the calls to 'labeled_restrictions_get_bound' in a call to XMARKER, 
because it can return nil.)

editfns.patch
Description: Text Data