Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.

Date:

Sat, 11 Jun 2016 21:44:27 +0000

User-agent:

Mutt/1.5.24 (2015-08-30)

Hello, Stefan and Dmitry.
On Sat, Jun 11, 2016 at 05:24:25PM -0400, Stefan Monnier wrote:
> > If we follow this path, and not hard-widen, the proposal must carefully
> > consider the existing use cases for font-lock-dont-widen. Because if
Er, hang on a moment, you two! The thread is supposed to be about
syntax-ppss. syntax-ppss is supposed to be a function which does one
thing and does it well.
That one thing is to determine, possibly from a cache, the equivalent to
(parse-partial-sexp "1" pos)
, where "1" may take non-canonical values.
Use cases for font-lock-dont-widen, existing or not, HAVE NO BEARING on
that determination of the parse-partial-sexp equivalent. So why are we
talking about them here?
> Yes, the new mechanism should really supercede font-lock-dont-widen.
> Just syntax-ppss-base as a single integer probably wouldn't cut it.
> It should probably be a setting that's not specifically tied to
> `syntax'.
How can anything more than a single integer be required to specify the
desired value of "1"?
> And as you point out in another message, it might make sense to have it
> specify an upper-bound too.
Maybe, but that's got nothing to do with syntax-ppss.
Can we PLEASE not confuse the specification and inner workings of
syntax-ppss with the contexts in which it may or may not be used?
I propose one third of us should now fix syntax-ppss so that it conforms
to its (new) specification, and that syntax-ppss-base should comprise an
integral part of this fix.
I don't consider myself to be the best of the three of us for this job
(given that I dislike syntax-ppss) but I'll do it if nobody else is
willing to.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).