Re: forward-comment and syntax-ppss

[Dmitry Gutov]

On 11.12.2016 12:17, Alan Mackenzie wrote:

> I don't think this is an issue.  (syntax-ppss-1 POS), when
> new-local-variable is non-nil simulates (parse-partial-sexp
> new-local-variable POS), and the latter would throw an error for
> precisely the same values of POS as the former.

Indeed, but this way the first argument will be implicit, and, unlike 
point-min, often non-obvious to the code calling syntax-ppss. It's easy 
to produce a buffer position lower than the arbitrary value of the new 
variable. It's harder to produce a buffer position lower than point-min.

Anyway, it's a minor issue. A good error message should be sufficient.

> Maybe, but these changes are the direct desired effect of narrowing.
> They're not nasty unforeseen side effects.

"nasty" or "unforeseen" is beside the point. Like described previously, 
some code doesn't really know how to behave in the face of narrowing if 
the user's intent that resulted in narrowing, isn't known.

> > > In particular, it doesn't change things like
> > > whether a particular buffer position is inside a string.
>
> > Not every buffer position is unequivocally "inside a strong" or not.
>
> > Take this example.
>
> > // Here's a string: "abc".
>
> > Is abc inside a string? That depends on what exactly we mean by that,
> > for a given use case.
>
> That may be the case, but that has nothing to do with what I said ("In
> particular, it doesn't change ....").  Whether abc is inside a string or
> not doesn't vary by the narrowing.  It's determined by other factors.

It can be determined by the narrowing (i.e. a function named 
`inside-a-string?' could confidently know whether to rely on the current 
narrowing or ignore it, to produce its result, if narrowing were 
annotated with intent).

> In particular, I was thinking of what I think is
> called "hard widening".  I think it would be a mistake to add this
> feature.  At the moment, narrowing is a strong, direct, simple facility
> - it does what it says it does and no more.

From where I'm standing, the things you use it for (hide buffer 
contents) can be implemented in a much better fashion using overlays 
with invisibility (in fact, one such implementation exists already), 
which don't introduce the difficulties of changing point-min and 
point-max. Thus, without making things harder for many other facilities.

> Were "hard widening" to be
> introduced, we could easily end up with a confused mess of `widen' and
> `hard-widen' through the code, with nobody being quite sure which one to
> use and why.  There might be lots of depressing errors where the wrong
> one is used.

These are issues of design and documentation. The previous discussions 
of hard-widen didn't come up with any real conceptual problems. Just 
with low-level implementation ones.

> > More importantly, any change you would make to the "new" function you
> > could make to syntax-ppss instead.
>
> The new function would be a different function, i.e. it would have a
> different definition.  Just for clarity, it would not be written from
> scratch, it would be based on the current syntax-ppss.

And then it would be utterly useless for third-party code, for years to 
come. Further, if it uses a separate variable for its cache, and the new 
function is used in the code, while the old function continues to be 
used by third-party code (and also stable packages like Gnus and 
CC-Mode) for compatibility reasons, we'll have two syntax caches that 
will interact in fascinating, difficult to predict ways.

Am I interpreting your intention correctly?

> > Further, the good part of this proposal is more or less equivalent to
> > "indexing syntax-ppss cache by point-min" as proposed by Stefan.
>
> I think I agree here.  But "good part" implies the existence of a "less
> good part".  What, in your view, constitues this "less good part"?

Well... both your and Stefan's proposals will end up actually having to 
maintain the index of syntax-ppss caches, and having to invalidate those 
values somehow. I'm sure it's possible to arrive at a satisfactory 
algorithm (like only keeping around two values, for point-min equal to 1 
and the most recent other value), but there must be use cases which some 
other invalidation approach would be better.

With syntax-ppss-dont-widen, the caller code can take the responsibility 
of maintaining the values of syntax-ppss-cache and syntax-ppss-last. And 
it turns out, it's rather easy to bind them to nil around the same 
pieces of code that starts with (save-restriction (narrow-to-region 
...)). Which currently seems to give the same result as the idea in the 
previous paragraph, with much less code.

In short, letting the caller code control cache invalidation has its 
benefits.