[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result.
Date: Tue, 12 Sep 2017 03:24:08 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0

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

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.


- Any package than advises syntax-ppss will have to juggle fewer global

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.


reply via email to

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