[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.
- Re: forward-comment and syntax-ppss, (continued)
- Re: forward-comment and syntax-ppss, Alan Mackenzie, 2016/12/09
- Re: forward-comment and syntax-ppss, Stefan Monnier, 2016/12/09
- Re: forward-comment and syntax-ppss, Clément Pit--Claudel, 2016/12/09
- Re: forward-comment and syntax-ppss, Alan Mackenzie, 2016/12/09
- Re: forward-comment and syntax-ppss, Eli Zaretskii, 2016/12/10
- Re: forward-comment and syntax-ppss, Andreas Röhler, 2016/12/10
- Re: forward-comment and syntax-ppss, Dmitry Gutov, 2016/12/08
- Re: forward-comment and syntax-ppss, Stefan Monnier, 2016/12/08
- Re: forward-comment and syntax-ppss, Andreas Röhler, 2016/12/09
- Re: forward-comment and syntax-ppss, Alan Mackenzie, 2016/12/09
- Re: forward-comment and syntax-ppss,
Dmitry Gutov <=
- Re: forward-comment and syntax-ppss, Stefan Monnier, 2016/12/10
- Re: forward-comment and syntax-ppss, Alan Mackenzie, 2016/12/11
- Re: forward-comment and syntax-ppss, Andreas Röhler, 2016/12/11
- Re: forward-comment and syntax-ppss, Dmitry Gutov, 2016/12/15
- RE: forward-comment and syntax-ppss, Drew Adams, 2016/12/15
- Re: forward-comment and syntax-ppss, Eli Zaretskii, 2016/12/16
- RE: forward-comment and syntax-ppss, Drew Adams, 2016/12/16
- Re: forward-comment and syntax-ppss, Eli Zaretskii, 2016/12/16
- RE: forward-comment and syntax-ppss, Drew Adams, 2016/12/16
- Re: forward-comment and syntax-ppss, Dmitry Gutov, 2016/12/16