[Top][All Lists]

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

Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-pp

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
Date: Tue, 19 Jan 2016 04:25:27 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0

On 01/19/2016 01:12 AM, Stefan Monnier wrote:
Doesn't paren-matching code call syntax-ppss anyway?

Not that I know, no.

electric-pair-syntax-info calls syntax-ppss. blink-matching-open calls (forward-sexp -1).

Yes, this whole area is rather murky.  The font-lock syntax-table should
mostly disappear (90% of the uses were to turn "_" syntax into "w"
syntax so as to be able to use \< and \>, but this has been made
obsolete by the new \_< and \_>), I think.

font-lock-syntax-table should go away, yes. But it's still there.

Are current-syntax-table and syntax-ppss-table allowed to differ more than that?

E.g. in TeX and HTML, we want to match parentheses even though the formal
syntax does not give any special rule to parentheses.  Similar thing for
matching parens when the open and close parens are both inside comments,
but not inside the same one.

Multiple major modes strike again! Or multiple syntactic regions, anyway. I'm not sure if having a different value of syntax-table (any variable) between different comments will help us any.

But up-list uses the return value of syntax-ppss, so it will be affected by

syntax-ppss is indeed used, but only to decide if we're strings or
comments, so it should be OK.

Never for its 9th element?

It doesn't seem easy to reason about.

Indeed, it's not.

So, I'm wondering if we could postpone introducing a new variable, and implement the same thing in nxml-mode somehow in a different way.

But you've probably already considered that.

reply via email to

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