Re: [Patch] hard-widen-limits [was Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]]

[Stefan Monnier <monnier@iro.umontreal.ca>]

> There is no real need to invent extra type of narrowing. It's a lot of extra
> work with no additional benefit.

I don't see any extra work.  (narrow-to-region BEG END 'hard) would just
be the API used to set your hard limits, and that's all there is to it.

> If user typed within a hard region the hard narrowed region, will the
> upper hard limit expand just as ZV does?

This is indispensable, yes.  No matter whether the hard limits are
folded int narrow-to-region or any other way: the upper limit has to be
a marker, and unless we strictly enforce that the hard limits can't be
circumvented at all, the lower limit would probably have to be a marker
as well.

> My approach is simpler and leaves current narrowing functionality
> alone.  You set the limits and allow narrowing happening inside those
> limits normally.

That's also how I imagine (narrow-to-region BEG END 'hard) working.
It just won't allow widening outside of those hard limits.

> You might end up loosing text outside of the bounds if you modify the
> buffer and then call widen, but that's by design and this is how it's
> different from visual narrowing.  Hard limits stay the same
> irrespective of what happens to the buffer.

Sounds like a wart.  What's the benefit?

>>> limits at the end. Problems will occur if major modes start using hard
>>> limits in such contexts directly.
>> I don't see any reason why problems *will* occur in that case (tho, of
>> course, Murphy could be that reason).  So until such problems do show up,
>> I wouldn't worry.
> The problem is not hypothetical. It's occurring right now.

It can't because we don't have hard limits right now.


        Stefan