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

[Andy Moreton]

On Thu 21 Apr 2016, Alan Mackenzie wrote:

> Hello, Eli.
>
> On Thu, Apr 21, 2016 at 05:17:09PM +0300, Eli Zaretskii wrote:
>> > Date: Wed, 20 Apr 2016 19:44:50 +0000
>> > From: Alan Mackenzie <address@hidden>
>> > 
>> > This post describes my notion of how multiple major modes {c,sh}ould be
>> > implemented.  Key notions are "islands", "island chains", and "chain
>> > local" variable bindings.
>
>> Thank you for publishing this.  A few comments and questions below.
>> Please keep in mind that I never had to write any Lisp that deals with
>> these issues, so apologies in advance for possibly silly questions and
>> misunderstandings.
>
>> >   o - To the user, the current major mode will be that of the island where
>> >     point is.  All familiar commands will work without restriction.
>
>> Does this mean the display of mode line, menu bar, and tool bar will
>> change accordingly?
>
> Yes, please!
>
>> A more subtle issue is with point movements that are not shown to the
>> user (those done by Lisp code of some command, before redisplay kicks
>> in) -- what will be the effect of those? do they trigger redisplay,
>> for example?
>
> They shouldn't trigger redisplay, no.
>
>> >   o - An island chain will have @dfn{chain local} variable bindings.  Such 
>> > a
>> >     binding will become current and accessible when point is within one of 
>> > the
>> >     chain's islands.  When point is not in an island, the buffer local 
>> > binding
>> >     of the variable will be current.
>
>> Emacs sometimes examines buffer text without moving point, and we
>> generally expect for buffer-local bindings to be in effect regardless.
>> A prominent example is the display engine.  I will return to that
>> later.
>
> OK.
>
>> >     * - [Island] 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.
>
>> I don't understand the notion of "enclosed" islands: wouldn't such
>> "enclosing" simply break the "outer" island into two separate islands?
>
> If we mark island start and end with the syntax-table text properties
> "{" and "}", we're going to have something like
>
>     {     a{  }b    }
>
> .  Simply to break the outer island into two pieces, we'd really need to
> apply delimiters at a and b, giving:
>
>     {     }{  }{    }
>
> .  This would overwrite the previous syntaxes at a and b, and this might
> be a Bad Thing.

Care will be needed to allow more than one island chain using the same
inner mode, where the chains represent unrelated documents that are
independently embedded in the larger document.

>> >   o - `scan-lists', `scan-sexps', etc. will treat a "foreign" island as
>> >     whitespace, much as they do comments.  They will also treat as 
>> > whitespace
>> >     the gap between two islands in a chain.
>
>> Why whitespace? why not some new category?  By overloading whitespace,
>> you make things harder on the underlying infrastructure, like regexp
>> search and matching.
>
> I think it's clear that the "foreign" island's syntax has no interaction
> with the current island.  If we treat it as whitespace, that should
> minimise the amount of adapting we need to do to existing major modes.

There may be some interaction. The language used for the enclosing text
(using the super mode) may require quoting and escaping to be performed
on the content embedded in it. This means that the textual
representation of the content in the island chain may depend on what it
is embedded into.

The inner mode for the island chain will either need to be aware of this
quoting and escaping syntax (belonging to the super mode), or the text
in the island chain will need to be unescaped and unquoted for the inner
mode to make sense of it.

    AndyM