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

[Dmitry Gutov <dgutov@yandex.ru>]

On 9/11/17 11:12 PM, Alan Mackenzie wrote:

>> Before, we had syntax-ppss-cache and syntax-ppss-last. The patch adds 8
>> new ones.
> 
> Yes.  But each one has a very single purpose, and there are no loops in
> the new code, which makes it easier to be sure it is correct.

On the one hand, yes, on the other hand, the more code you have (or the 
more vars you have to juggle), the harder it is to keep track.

> I'm in favour rather of setting syntax-ppss-{cache,last} to the
> appropriate stored cache.  This will avoid needing to change the
> function syntax-ppss much.

My proposal will change syntax-ppss, yes. So, unfortunately, the patch 
will be more difficult to read. But not the resulting code, hopefully.

But I think I see what you mean. The disadvantage is that we'll need 
code that will ferry those values back to the appropriate variables as 
well (which we see in your patch). We can discuss that option after.

> A disadvantage of using such a cons is in debugging.  It is more
> difficult to understand a cons like this when it is printed out, than
> the two component lists (which are difficult enough themselves).

You win some, you lose some. We could use structs, if you like, but 
overall, the values are already complex, so consing won't make that much 
worse.

> When there's a lot of buffer changing going on, it is an overhead having
> to clear both (or several) caches continually.  (I'm thinking about the
> possible extension to using an alist of caches, which could be quite
> long.)

Both caches - yes, but shouldn't be too bad. The "alist of caches" 
approach would most likely require that laziness, but I'm not sure we 
really want to go there (see another email).

> Also clearing both caches at the same time would be a bigger change to
> syntax-ppss-flush-cache than it's suffered so far.

True.

>> - Any package than advises syntax-ppss will have to juggle fewer global
>> variables.
> 
> I was intending that the new variables be purely internal, and that no
> external elisp would need to access them.  I suppose I really ought to
> have put "--" in the middle of their names.

Yes, but if we can make life easier for some, why not? Sometimes 
third-party author can life with breakage between Emacs versions.

>> 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.
> 
> That sounds a little dangerous.

Not much worse than what multi-mode packages already do, though.

>> The obvious downside is, of course, extra indirection, which translates
>> to extra overhead. We don't know how significant it will be, though.
> 
> I wouldn't be keen on seeing lots of (car compound-variable) and (cdr
> compound-variable) throughout the syntax-ppss function.  I think it
> would make it significantly more difficult to understand.

Hopefully there will be only several such places. But again, we can use 
structs.

>> Would you like to see the code?
> 
> Yes, why not?

Please give me until the end of the week.

> But just to make my position clear, I'm not particularly fixed on my
> patch as submitted.  It was optimised for simplicity and correctness
> rather than elegance, though I don't think it's too bad.  I'm fairly
> open on whether we use your suggestions or Stefan's suggestion of having
> an alist of caches.

Cool.