Re: Idea for syntax-ppss. Is it new? Could it be any good?

[Stefan Monnier]

>> When I wrote syntax-ppss, my main goal was to never be significantly
>> slower than parse-partial-sexp.  Even if it's not as fast as it could
>> be if written in C (which is pretty much obviously true), that's not a
>> reason to recode it in C.
> Surely the goal should be to be significantly faster most of the time.

Of course, but that's the easy part.

> Presumably it achieves this in practice.  The reason to recode in C
> would be to make it fast enough, or to couple it up to things which
> couldn't be done in lisp.  But probably neither of these things is
> needed.

I may prove necessary to reimplement it in C at some point, but for now
I haven't found any need for it.

>> That can be done, tho it needs extra info in order to know how to
>> interpret the fact that it's narrowed.

> Don't understand.  The function is defined as the equivalent of
> (parse-partial-sexp (point-min) pos)?  You've said before that the
> function is best not called when a buffer is narrowed.  Couldn't we just
> redefine it as (parse-partial-sexp 1 pos)?  Then we could just put
> (save-extension (widen ..... )) into syntax-ppss.

We need the equivalent of font-lock-dont-widen for cases such a Rmail or
Info.  Probably this could be considered as a special case of
multi-mode buffers.

>> I think this will result in too many cache flushes and will make the
>> code too intrusive or too ad-hoc.  I'd rather have a
>> syntax-ppss-syntax-table (and force parse-sexp-lookup-properties to t)
>> if you want more reliable results.

> Hey, syntax-ppss-syntax-table is a brilliant idea!  In its doc string one
> could say "after setting this, clear the cache by calling ...
> (syntax-ppss-flush-cache 1)".

Tho, it'd then make sense to let (syntax-ppss-flush-cache) do the job,
so as to avoid the need to hardcode this ugly 1.
[ Note: my own buffers all start at position 12345678. ]

> No.  I think I've been scared by its vagueness (about narrowed regions)
> more than anything.  It's defined in the elisp manual as equivalent to
> (pps (point-min) pos) rather than (pps 1 pos).  It also uses
> syntax-begin-function, which doesn't seem right, and wouldn't work well
> in CC Mode; the only way s-b-f can give a cast-iron result is by calling
> parse-partial-sexp, or syntax-ppss.  In fact, if syntax-ppss was
> bulletproof, syntax-begin-function would be redundant.

Note that it's default value is nil.  I.e. it's only provided for those
cases where the major mode can provide the info more cheaply than by
running parse-partial-sexp.

> Maybe I should test syntax-ppss by coding up inside a macro which
> widens.  And I've been less than convinced it's actually faster.  In
> fact, I'll go and do some speed tests and report back.

I'm sure you can come up with tests where it's consistently slower than
<writeyouralternativehere>.  The specific use I had in mind of
syntax-ppss is when you call it very freely, even several times within
the same command in nearby locations.  And as mentioned, it mostly tries
to avoid pathological behaviors rather than trying to get the very best
possible speed in "the usual case".

Also the question is not "is it faster", but "is it fast enough".


        Stefan