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

[Dmitry Gutov]

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.