Re: forward-comment and syntax-ppss

[Alan Mackenzie]

Hello, Dmitry.

On Sat, Dec 10, 2016 at 01:30:24AM +0200, Dmitry Gutov wrote:
> On 09.12.2016 21:07, Alan Mackenzie wrote:

> > That could be.  But a variable called syntax-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.

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.

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

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

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

I don't think so.  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.  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.

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

Oh dear, Dmitry!  ;-)

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).