[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-pp

From: Andreas Röhler
Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch
Date: Thu, 20 Feb 2014 22:28:33 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

Am 12.02.2014 02:30, schrieb Stefan Monnier:
IIRC the reason was so that (syntax-ppss) called from a place like
a "column-0 just before an open paren" can correctly indicate if this
open paren is within a string/comment while at the same time parsing the
subsequent text assuming that this open paren was outside of any
Why? That sounds confusing.

That's the point: it makes it possible to find those sources of
confusion and highlight them.

E.g. I had some font-lock code which would highlight an
open-paren-in-column-0-in-string/comment with the `warning' face.
So such an "incorrect" open paren would still cause incorrect
highlighting, but the `warning' face on it would provide the clue as to
what was the source of the problem.

I would've bound `syntax-ppss-last` and `syntax-ppss-cache` to nil around
the region and let it be forced to call the syntax-begin-function.

Right, but that largely defeats the purpose of syntax-ppss (which is to
use caching to speed up (parse-partial-sexp (point-min) (point))).

[ ... ]

Wouldn't it be cleaner to forget about syntax-ppss here and resort to 
(parse-partial-sexp BEGINNING-of-Subsection point) ?

BTW org-babel deals with a lot of modes nicely. Why not port the code from 

reply via email to

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