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

[Vitalie Spinu <spinuvit@gmail.com>]

>> On Tue, Mar 22 2016 22:22, Stefan Monnier wrote:

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

Ok. So we agree that there is work involved of tracking an extra
marker. Whenever buffer is modified by low level code, it must track new ZH
marker and respect the relationship between ZH and ZV. There are 544 occurrences
of ZV in emacs source. In order to add this extra marker one would need to go
through all of those cases and enforce the semantics of ZH.

It might be that adjusting ZV macros might do the job, but I cannot judge
because I am not yet familiar with buffer modification code.

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

True, but it's almost a direct implementation of the restriction in
prog-widen. It has same limitations and multi-modes are completely fine with
those. A with-widen-limits macro will suffice for multi-mode use case. But you
proposed to extend it to permanent set-widen-limits or (narrow-to-region
.. 'hard). I see the benefit of it in info mode but I think it's pretty
marginal.

The proposed non-marker implementation will deter usage of widen-limits in
contexts that involve buffer modification. But it will work just fine with
multi-modes and with read-only info use cases. It also works fine with editing
as long as it's not followed by widen. If widen is used the buffer will be
re-narrowed to old limits.

I will look into ZH marker this weekend. Maybe it's not that hard as I imagine.

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

Oh common. You know I was referring to current widen/narrow mechanism. It's one
step to extrapolate to hard narrowing from there.

  Vitalie