Re: Several Major Modes.

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

On Fri, Nov 15, 2019 at 00:11:17 +0200, Dmitry Gutov wrote:
> On 14.11.2019 23:24, Alan Mackenzie wrote:
> > Hello, Dmitry.

> > On Thu, Nov 14, 2019 at 00:33:33 +0200, Dmitry Gutov wrote:

> > [ .... ]

> >>>> In mmm-mode context, however, we apply definite boundaries to the
> >>>> region chunks. Here's an example of some Noweb code:
> >>>> https://en.wikipedia.org/wiki/Noweb#Example_of_a_simple_noweb_program

> >>>> The inside of hello.c block would be narrowed to.

> >>> I think I've said this before, but I don't think narrowing is the right
> >>> tool for that task.  I don't think there is a suitable tool in Emacs at
> >>> the moment.

> >> *shrug* We do the best with what we have.

> > Why can we not formulate something better, an enhancement to the Emacs
> > core which would support several major modes properly?  I have made
> > proposals in this area before, but I think they were to grandiose to be
> > implementable.

> > What seems to be needed is a way of partioning a buffer into several
> > sub-buffers (which I have called "islands" in the past), and having a new
> > type of local variable, one valid in exactly one sub-buffer.  More or
> > less.

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

> .... or, if we absolutely can't make it work, add a new element to
> prog-indentation-context which will be a function that would return the
> bounds of the current chunk.

Or something like that.

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

> >>>> Now, I have remembered that CC Mode calls widen from many places
> >>>> already, so it already is problematic for using in a context like
> >>>> that.

> >>> It does, yes.  Users also use widening and narrowing.

> > I believe these problems won't go away, and there will always be
> > conflicts between CC Mode (as it is) and mmm-mode (as it is).

> I think we should also try to understand whether making CC Mode play 
> nice to doable/feasible, and for what uses. Like, I think it can work 
> (more or less) already when it's the primary major mode (meaning the 
> buffer starts and ends with it), so the embedded chunks are all other 
> modes.

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.

> 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.  So I don't see why not, once the problem with the
syntax-table text properties is solved.

> By answering these questions we can temper our expectations and come up
> with a practical plan.

> Doing nothing is also a valid choice, BTW, since for many uses replacing 
> c-mode with js-mode works pretty okay. I've been recommending it to 
> MMM-mode users.

That's a rather rough workaround.  It would be better if we could solve
the problems.

-- 
Alan Mackenzie (Nuremberg, Germany).