[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: forward-comment and syntax-ppss

From: Dmitry Gutov
Subject: Re: forward-comment and syntax-ppss
Date: Sat, 10 Dec 2016 01:30:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]