Re: locked narrowing in ELisp

[Stefan Monnier]

>> Such a display-only narrowing might be a good alternative for many uses
>> of narrowing, but narrowing is also used quite commonly (either by the
>> end-user or in ELisp code) in order to restrict the effect of an
>> operation (like search&replace) to a particular region.
>
> Certain operations could look up the "soft narrowing" bounds and act
> accordingly, if it's implemented in the core and appropriately documented.

Could be, but unless we go through the whole C code looking for checks
of BEGV/ZV and updating the code to also check the "soft bounds" this
won't work reliably enough to replace existing uses of narrowing.

> To my understanding, there are more commands and facilities that want to
> ignore user-level narrowing, rather than the ones that want to obey it. Also
> a lot of "undecided" ones, waiting for someone to report that they should,
> in fact, ignore narrowing.

But for backward compatibility reasons, we can't break the cases that
need the bounds to be hard, even if it could fix some cases.


        Stefan