[Top][All Lists]

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

Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could w

From: Alan Mackenzie
Subject: 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).

reply via email to

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