[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-pp
Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var
Tue, 19 Jan 2016 09:30:39 -0500
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)
>>> Doesn't paren-matching code call syntax-ppss anyway?
>> Not that I know, no.
> electric-pair-syntax-info calls syntax-ppss.
Yes, but again that's only to figure out if we're inside
a string/comment, so I think it's fine.
> Are current-syntax-table and syntax-ppss-table allowed to differ more
> than that?
In the one current use case, they differ significantly, yes.
>>> 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?
AFAICT no (even though it could, indeed).
>>> 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.
I think syntax-ppss-table is "the right way" in that it is the place
where we can define the "low-level, strict, formal syntax".
This new variable makes it possible to use with-syntax-table safely with
any random syntax table which happens to parse things the way we
currently need it.
There are indeed potential problems with interactions with other
functions, but I expect that the right fix for them would be to be more
careful about whether they use the output of syntax-ppss (and hence
the proper syntax of the major mode) or if they use something else
(e.g. forward-sexp) to get a more dwimish behavior.