Re: Several Major Modes.

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Nov 17, 2019 at 14:48:35 +0200, Dmitry Gutov wrote:
> 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.

Other than CC Mode's handling of syntax-table text properties, what
precisely is hindering it working in MMM Mode?  (That question's partly
addressed at myself.)

[ .... ]

> >>>> 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.

Being more precise, with this idea there would be several sets of s-t
properties present at the same time.  Each would have a different symbol,
e.g. gensyms like syntax-table-13, syntax-table-14, .....  The code in
textprop.c would check the symbol 'syntax-table for a particular symbol
property, which if set would cause it to substitute, say,
syntax-table-13, and read/write that property instead.   Fast, and only a
bit inelegant.

Naturally, all the low-level caches in syntax.c would need to be
synchronised at the same time we bind the thing to syntax-table-13.  The
caches belonging to each individual MMM chunk (such as syntax-ppss
caches) would be OK without change, since they would only be used while
the chunk was current, and hence syntax-table-13 currently in use.

Given how much in Emacs depends on syntax, this scheme might save a lot
of work and a lot of workarounds in MMM Mode.  If MMM Mode could be
responsible for putting space syntax-table-13 properties on all chunks
but the current one, it is possible major modes could be used in MMM Mode
with only minimal adaptations to those major modes.

Implementing this scheme would not be difficult.  (As I said, it's half
done already.)  How would you feel about using it in MMM Mode, and do you
see any difficult problems 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.

:-)  Sorry, yes.  I think working with an incomplete chunk would be
difficult at the moment.  With all the other chunks "spaced out", as
suggested above, it would be easy, I think.

-- 
Alan Mackenzie (Nuremberg, Germany).