emacs-devel
[Top][All Lists]
Advanced

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

Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss return


From: Dmitry Gutov
Subject: Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]
Date: Mon, 14 Mar 2016 22:06:02 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

Hi Alan,

On 03/14/2016 05:16 PM, Alan Mackenzie wrote:

How about an extension to the parse-partial-sexp (etc.) code?  For
example, a feature I would call an "island", where a character could be
marked with the "island start" syntax-table property, and another
character lower down could be marked with the "island end" character.

Something like that might help, although I hesitate asking for that change because it's a relatively big one, and it would still solve only one multiple-mode-related issue.

What it would help with, is fool the "outer" major mode into ignoring the preceding submode regions, in the return value of syntax-ppss. But we could have pretty much that already by advising syntax-ppss. That leaves out parse-partial-sexp, but it's not used that often directly in major mode code (though sgml-mode uses it).

parse-partial-sexp, on encountering an island start syntax would somehow
stack the current parse state and start a new one with a different syntax
table.  The parse state, instead of consisting of the 10 elements
currently, would in general have 10n elements, where n is the depth of
nesting.

To be able to parse across different regions, it would need to know the syntax table for each one (using the syntax-table text property?), as well as to be able to apply the appropriate syntax-propertize-function in each region. The latter is handled by mmm-mode, though, in a seemingly adequate fashion (it installs a composite function that knows how to dispatch to mode-specific ones).

Maybe it's worth a try. Though I don't know how Stefan uses narrowing in sm-c-mode, and whether this proposal is appropriate to replace narrowing in syntax-ppss for this use case.



reply via email to

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