Re: A vision for multiple major modes: some design notes

[Dmitry Gutov]

Hello Alan,

Thank you for writing this expansive summary. I'll comment on a couple 
of the items below, but overall, if you're asking my personal opinion, 
we should put a pin in this for now, and first see where the hard-widen 
feature gets us.

After that, we could see whether it wouldn't be easier to extract 
certain individual pieces of this proposal in an independent fashion. 
The main two I see are:

- A way to assign buffer boundaries that make certain core primitives 
treat some buffer regions as whitespace, maybe with support for nesting. 
I don't know if that should be via text properties. As long as this 
feature is only used dynamically, it could be a list structure stored in 
a dynamic variable. That way the `in-islands' variable would become 
redundant.

- A way to quickly store and switch between sets of buffer-local variables.

If you go ahead with this proposal, though, I think it should be 
implemented in close collaboration with an author of a related package. 
Vitalie Spinu and Christoph Wedler (polymode and andlr-mode maintainers) 
would be good candidates, and neither has shown up at this discussion 
yet. Unfortunately, I don't have a lot of time to dedicate to mmm-mode 
lately (and it probably has the highest backward compatibility 
expectations out of the three anyway).

The main drawbacks of this, IMHO, are that it's big (like you mentioned 
yourself), and that it's fairly opinionated. Hence the two-item list above.

On 04/20/2016 10:44 PM, Alan Mackenzie wrote:

>     * - The coordination of these bindings will be carried out by the
>       mechanisms described below, without explicit coding in the super mode.

This seems a little too optimistic. For instance:

>   o - To the user, the current major mode will be that of the island where
>     point is.  All familiar commands will work without restriction.

Imenu, as one example, will require coordination from the super mode, or 
from the multi-mode framework. The user will normally want to see all of 
entries in the current buffer in the index, so something would have to 
merge them.

>   o - To the writer of major modes, a minimal set of restrictions will apply:
>     * - For some major mode commands, the mode will have to bind the variable
>       `in-islands' (see below) to non-nil.

Ideally, the writers of the "island" major modes wouldn't do anything 
special to support multi-mode usage. It would be better if the 
"superior" major modes would have to do all the "special" things.

I.e., it's fine to have to introduce a new major mode for a templating 
language if it can easily use existing major modes for the code regions 
inside.

Here's a related question: would `indent-for-tab-command' bind 
`in-islands' to t, or not?

> (iv) Islands.
>   o - An island will be delimited in two complementary ways:
>     * - It will be enclosed syntactically by characters with "open island" and
>       "close island" syntax (see section (v)).  Both of these syntactic
>       markers will include a flag "chain" indicating whether there is a
>       previous/next island in the chain.  The cdr of the syntax value will be
>       the island chain to which the island belongs.
>     * - It will be covered by the text property `island', whose value will be
>       the pertinent island or island chain (see section (ii)) (not yet
>       decided).  Note that if islands are enclosed inside other islands, the
>       value is the innermost island.  There is the possibility of using an
>       interval tree independent of the one for text properties to increase
>       performance.

Going by the current implementation in mmm-mode, it would be handy if 
the islands could be distinguished using one text property only. Then we 
simply set it on all overlays that cover mmm-mode's subregions. But if 
all three elements are required, so be it.