GNU bug report logs - #22983
syntax-ppss returns wrong result.

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Alan Mackenzie <acm <at> muc.de>, Philipp Stephani <p.stephani2 <at> gmail.com>, 22983 <at> debbugs.gnu.org, John Wiegley <jwiegley <at> gmail.com>
Subject: bug#22983: [ Patch ] Re: bug#22983: syntax-ppss returns wrong result.
Date: Tue, 12 Sep 2017 03:11:15 +0300

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. :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.