bug#22983: syntax-ppss returns wrong result.

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Tue, Sep 05, 2017 at 02:34:15 +0300, Dmitry Gutov wrote:
> On 9/2/17 8:40 PM, Alan Mackenzie wrote:
> > I'm not happy about this.  22983 is a serious design flaw, which has had
> > deleterious effects deep within Emacs.

> I'm sure we want to fix design flaws. As long as there is a solid plan 
> that does not swap one flaw for another.

Plan or not, it should be fixed.

> > One recorded example, resulting
> > in an infinite loop, is:
> > 
> > #########################################################################
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > To: emacs-devel@gnu.org
> > Subject: [PATCH] Protect against an infloop in python-mode
> > Date: Tue, 28 Feb 2017 22:31:49 +0100
> > 
> > There appears to be an edge case caused by using `syntax-ppss' in a
> > narrowed buffer during JIT lock inside of Python triple-quote strings.
> > Unfortunately it is impossible to reproduce without manually
> > destroying the syntactic information in the Python buffer, but it has
> > been observed in practice.  In that case it can happen that the syntax
> > caches get sufficiently out of whack so that there appear to be
> > overlapping strings in the buffer.  As Python has no nested strings,
> > this situation is impossible and leads to an infloop in
> > `python-nav-end-of-statement'.  Protect against this by checking
> > whether the search for the end of the current string makes progress.
> > #########################################################################
> > 
> > In this case, Philipp had to apply a workaround.

> The problem manifested during jit-lock. Do we understand why the (widen) 
> call inside font-lock-default-fontify-region didn't help?

I don't, not in detail, no.  Philipp might know.  But if syntax-ppss was
used whilst the buffer was narrowed, it likely corrupted its cache, and
that corruption remained after widening the buffer.

-- 
Alan Mackenzie (Nuremberg, Germany).