bug-gnu-emacs
[Top][All Lists]
Advanced

[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:11:15 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0

On 9/11/17 2:10 PM, Stefan Monnier wrote:

My suggestion is to have a list of N caches, instead of having exactly
2 caches.  I can't see how that could lead to more clobbering.

Um, sorry I misunderstood. I interpreted that as only keeping one pair.

But here are some other issues:

1) If we maintain a cache for all narrowings that have ever been used in the buffer, we adopt the idea that all of them are "real" and e.g. correspond to chunks in different major modes in a multi-mode context. Switching to a different syntax table and parsing a segment of text like ruby-syntax-propertize-percent-literal does falls outside of this concept. But of course, we can index by syntax table as well... overall, things become much complex than when changing the narrowing bounds implies just throwing away that cache.

2) If there are a lot of elements inside the cache alist, we have to get rid of them from time to time. Not sure what the rules will be. Again, if they correspond to multi-mode chunks, we can at least be confident that the number of items in the alist will be finite. Not necessarily so if narrowing+spss is used for arbitrary purposes.

3) As the number of elements in the alist grows, flushing each value inside syntax-ppss-flush-cache eagerly will become slower and slower, I expect. And a lazy strategy of the kind proposed by Alan will become necessary.

I'm considering the idea now that syntax-ppss should stay a caching wrapper
around parse-partial-sexp, and the responsibility to widen should always be
the caller's.  This way, it can be used for different purposes that we've
discussed before many times.

It does have the advantage of circumventing the discussion of
"up-to-where should we widen" ;-)

Indeed. :)





reply via email to

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