Re: Several Major Modes.

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Alan,

On 16.11.2019 15:10, Alan Mackenzie wrote:

>>> You also need to make sure narrowing is available for any purpose
>>> required by a major mode.
> 
>> Eh, I think it's "available" already, but I'd have to see specific examples.
> 
> Oh good!  I have to admit I haven't actually seen MMM Mode running, or
> at least I don't remember it.

I think we won't really know until there's a good change of CC Mode 
working with MMM Mode, so then people could try and exercise various 
features. And we'll see what works and what does not.

> I've taken a closer look at the functions in syntax.el, and I think
> you're right.  The removal of the syntax-table text properties happens
> up to END, not to EOB.  It would merely need syntax-propertize-function
> to be nil whenever anything involving the CC Mode region (including
> fontification) happens.

Yes, it should do that already.

>>>> Is it feasible to support embedded chunks? To support chunks with
>>>> incomplete pieces of code (which are e.g. included conditionally by the
>>>> surrounding template)?
> 
>>> Well CC Mode already supports preprocessor macros and (for C++) raw
>>> strings, which are syntactically somewhat and very different from the
>>> enclosing code.
> 
>> I'm not sure it's the same. Like, would CC Mode cope with a region
>> starting with closing brackets, etc. This might not be a frequent
>> situation, but at least it shouldn't blow up.
> 
> Maybe having several sets of syntax-table text properties in a buffer,
> one set for each sub-buffer, would help.  I devised and half-implemented
> such a facility back in 2017, calling it "indirect text properties".  To
> switch to a different set of properties, you would merely have to set
> (or bind) a dynamic variable.
> 
> With this, I could set whitespace syntax-table props all over the non-CC
> Mode regions while CC Mode is "in scope", thus making syntactic stuff
> and fontification easy.

It's an interesting suggestion, but a difficult problem. Like, if you 
just swap the meanings of syntax-table text properties, it would make 
syntax-ppss caches invalid without telling it. A better solution would 
be to somehow integrate with it.

Anyway, you mentioned a real problem (for which I only have workarounds 
thus far), but for now I was just asking whether an isolated 
"incomplete" chunk would work okay.