Re: Writing syntax-propertize-function for strings in code in strings, etc

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>>> Yes, one "push <inner-syntax-table>" and one "pop".
>>> So, I don't see the usefulness of the <inner-syntax-table> value in the
>>> simple case of embedding code in the same language.
>> It's for the other cases: strings with strings and comments within strings.
> Okay. I guess I just don't know [well enough] any languages with different
> embedded syntaxes.

I mentioned Postscript as a language that allows strings within strings
(Postscript strings are delimited by parentheses).

>> Without knowing the inner syntax table, it's pretty difficult to know
>> what can be skipped (unless we assume that the "push" can only be marked
>> with a `syntax-table' text-property).
> Indeed. But I think it's a reasonable assumption.

It's not for Postscript strings, I think.

> In all cases I can think about the "region opener" is at least two
> characters long, and it often depends on the context (like only inside
> a string).

OTOH, if we really need to find the inner syntax-table, we could ask
syntax-ppss to give the state right before the "pop", which will also
immediately tell us where is the matching push.
So maybe it's an acceptable workaround (provide a config variable to
either use syntax-ppss or assume that a push can only be within
a syntax-table text-property).

> Let's move point inside an embedded code region, maybe several levels
> deep.  Now we want to call `forward-sexp'.  How will it know the
> effective syntax-table value at that position?

That's not a new problem, actually, since if you start a `forward-sexp'
from within a string or within a comment you already get
similar problems.


        Stefan


PS: My secret longer-term agenda for world domination might include
    using push/pop for all strings and comments as well.