Re: Several Major Modes.

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Fri, Nov 15, 2019 at 23:45:44 +0200, Dmitry Gutov wrote:
> On 15.11.2019 22:10, Alan Mackenzie wrote:

> >> There are options. We'd have to decide on a suitable model, calling
> >> them islands or whatever, but I think the first approximation is to
> >> either make sure narrowing is available for this purpose ....

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

> The problem which triggered this discussion is that *something* called 
> font-lock rules from a narrowed buffer directly. But that's not a 
> "purpose required by a major mode".

> >> Regarding "new type of local variable", mmm-mode already tracks
> >> something like that.

> > I was envisaging something at the C level, where different regions of a
> > buffer would have different values of variables, without needing the
> > continual swapping at the Lisp level.  Maybe such a thing isn't needed.

> I'd been told that even a C-based implementation is unlikely to make 
> things much faster. Anyway, it would be a perf optimization, and we 
> could get to it later.

OK.

> > It can't work if any external Lisp corrupts its syntax-table text
> > properties.  This is what syntax-ppss-flush-cache (on
> > before-change-functions for many modes) would do if there were a non-nil
> > syntax-propertize-function at the time.  This may be the biggest problem
> > to getting CC Mode integrated into MMM Mode.

> mmm-mode sets its own syntax-propertize-function that calls major mode 
> specific syntax-propertize-function's over their respective 
> chunks/subregions. So, in principle, that should work fine. As long as 
> nobody calls 'widen' unexpectedly.

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.

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

-- 
Alan Mackenzie (Nuremberg, Germany).