[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: Mon, 11 Sep 2017 02:36:53 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0

On 9/11/17 1:53 AM, Stefan Monnier wrote:

I think that (parse-partial-sexp 1 x) is more often what the caller
wants than (parse-partial-sexp (point-min) x), but if you're happy with
the behavior described by the docstring, then that's fine.

And yet, I struggle to find such callers. But those that do, can (save-restriction (widen) (syntax-ppss)) anyway.

+;; The implementation which follows uses three caches, the current one
+;; (in `syntax-ppss-cache' and `syntax-ppss-last') and two inactive
+;; ones (in `syntax-ppss-{cache,last}-{wide,narrow}'), which store the
+;; former state of the active cache as it was used in widened and
+;; narrowed buffers respectively.

Earlier in the thread, I suggested to use a single cache indexed by the
position of point-min

That would lead to clobbering the global cache when we use syntax-ppss for some local parsing. E.g. if ruby-syntax-propertize-percent-literal didn't bind parse-sexp-lookup-properties to nil, it might clobber the cache unnecessarily.

I don't have the data on whether this would be a frequent problem, though.

i.e. a list of (POINT-MIN-POS . CACHE-DATA) or
((POINT-MIN-POS . SYNTAX-TABLE) . CACHE-DATA).  I think it would lead to
less code duplication than your patch which only handles 2 different
POINT-MIN-POS (and one of the two has to be equal to 1), but existing
code trumps hypothetical designs.

I also think there's a way to implement this behavior with less code and new variables, albeit with extra indirection.

So, I have no objections to the patch.  But I think (parse-partial-sexp
(point-min) x) is a design bug in syntax-ppss which we will need to fix
sooner or later, which is why I never bothered to implement something
like your patch, which only makes the code do what its doc says rather
than what the caller needs.

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.

reply via email to

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