bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result.

[Dmitry Gutov <dgutov@yandex.ru>]

On 9/10/17 2:36 PM, Alan Mackenzie wrote:

>>> The solution I propose is to introduce a second cache into syntax-ppss,
>>> and this cache would be used whenever (not (eq (point-min) 1)).
>>> Whenever point-min changes, and isn't 1, this second cached would be
>>> calculated again from scratch.
> 
> Here is a patch implementing this.  Comments about it would be welcome.

Thank you. It seems to hold up to the main test scenario I had in mind, 
so I don't have any complaints behavior-wise.

It looks pretty big, though. With lots of new global variables.

Before, we had syntax-ppss-cache and syntax-ppss-last. The patch adds 8 
new ones.

I propose two avenues for simplification:

1) Use a cons structure for the (PPSS-CACHE . PPSS-LAST) structure. We 
will have three global variables total: syntax-ppss-data-wide, 
syntax-ppss-data-narrow, syntax-ppss-data-narrow-point-min. syntax-ppss 
would bind a local variable syntax-ppss-data to one of the first two 
depending on the value of the third (and then modify its car and cdr 
during the course of execution).

2) Some extra vars serve to delay the actual clearing of the unused 
cache until it's used again. It's a valid idea, but what if we try 
without it at first? So syntax-ppss-flush-cache would always clear both 
caches eagerly.

The advantages:

- Less code, easier to reason about.

- Any package than advises syntax-ppss will have to juggle fewer global 
variables. So Vatalie's polymode will have an easier time of it. It 
could even reuse some of the cache-while-narrowed logic by substituting 
the values of syntax-ppss-data-narrow and 
syntax-ppss-data-narrow-point-min as appropriate.

The obvious downside is, of course, extra indirection, which translates 
to extra overhead. We don't know how significant it will be, though.

Would you like to see the code?