bug#22983: syntax-ppss returns wrong result.

[Dmitry Gutov <dgutov@yandex.ru>]

On 03/19/2016 02:27 PM, Alan Mackenzie wrote:

> OK, no bad thing!

Good.

> But seeing that the function is a new function (its specification has
> changed), it will need new test cases, fresh new attempts to break it.

Sure, please go ahead.

It needed new test cases even before this miraculous transformation.

>> +(defvar syntax-ppss-dont-widen nil
>> +  "If non-nil, `syntax-ppss' will work on the non-widened buffer.
>> +The code that uses this should create local bindings for
>> +`syntax-ppss-cache' and `syntax-ppss-last' too.")
>> +
>
> I'm against this bit.

I'm not married to it, but at least it would provide a backward 
compatibility escape hatch for a while. If a new way of handling mixed 
modes is added and turns out to be satisfactory, we can remove this 
variable later.

> If syntax-ppss-dont-widen is non-nil, the buffer
> is narrowed, and the local cache variables are correctly bound and
> filled, then something at a low level is going to widen the buffer (and
> call back_comment) without knowing to restore the global bindings for
> those cache variables.

When and why would that happen? I do not recall that happening before.

Since the "low level" is a bounded set, we should be able to make sure 
that the primitives do not, in fact, widen before calling syntax-ppss.

I suppose some could widen afterward.

> This could easily give the wrong result and
> corrupt the locally bound cache.

Even so, that would only affect the local cache, and as such, only the 
subregions, in the case of mixed-mode usage. In the general case, it 
would only affect the consumers of syntax-ppss that bound 
syntax-ppss-dont-widen, as long as they bound the cache variables as 
well, which we tell them to.

That lowers the damage area considerably.

> I think the only sensible functionality for syntax-ppss is to be
> equivalent to (parse-partial-sexp 1 pos).  Then everybody knows where
> they stand.  Those pieces of code which actually need a ppss cache with
> origin other than 1 could then use a more appropriate specialized
> function whose cache wouldn't get mixed up with syntax-ppss's.  (It
> could share a lot of code with syntax-ppss).

They already use syntax-ppss. I imagine Emacs's backward compatibility 
policy has something to say about that.