Re: forward-comment and syntax-ppss

[Dmitry Gutov]

On 09.12.2016 21:07, Alan Mackenzie wrote:

> That could be.  But a variable called wyntax-ppss-dont-widen has the
> caller explicitly messing around with the flowchart of syntax-ppss,
> which is not a good thing.  I think my proposed new local variable is
> better for this reason.

It's better in one sense and worse in another. Since parse-partial-sexp 
can't parse backwards, you're leaving a whole range of values of POS on 
which syntax-ppss will have to just raise an error.

> Narrowing doesn't change the buffer state either, beyond what it
> explicitly says it does.

It changes state and, as such, behavior of a huge number of functions 
(both core and third-party ones).

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

> It tends to be trivial to add stuff on.  Much easier than getting rid of
> stuff.  And that extra stuff might well be fat rather than muscle.

That's just rhetoric.

> > You keep repeating that word (replace), as though that solves anything.
>
> It would solve bug #22983.

No, it won't. For instance, because the bug is complaining about the 
behavior of syntax-ppss (see, I can play these word games too).

More importantly, any change you would make to the "new" function you 
could make to syntax-ppss instead.

> > and that function doesn't have an "escape hatch", the multi-mode
> > packages will be hung out to dry.
>
> I wouldn't want that to happen.  Does the suggested new buffer local
> variable (to specify the lower bound in the notional partial-parse-sexp)
> not provide this escape hatch?

It would (if we're talking about changing syntax-ppss, and not anything 
else). It does come with its own weird semantics, however, mentioned at 
the top of this message.

Further, the good part of this proposal is more or less equivalent to 
"indexing syntax-ppss cache by point-min" as proposed by Stefan.