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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Apr 23, 2016 at 09:12:25PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 23 Apr 2016 17:02:08 +0000
> > Cc: emacs-devel@gnu.org, dgutov@yandex.ru
> > From: Alan Mackenzie <acm@muc.de>

> > > More generally, I think we should first and foremost make our goal to
> > > have a clean and reasonably simple design, and only care about the
> > > amount of changes in major mode code as a secondary goal.  Thinking
> > > about the changes in major modes first could easily lead us astray.

> > We must consider both these things together.  A prime design goal is to
> > allow an arbitrary major mode to be used by a super mode with the minimum
> > of adaptation to the major mode, ideally none.

> I think you make this goal the main one, and that is a mistake.  The
> changes that will be needed for supporting multiple modes in the same
> buffer will be extensive, whether you want it or not, so trying too
> hard to make it easier on modes to adapt will skew the design.

Let me put things another way.  Above all, I want this new facility to be
based on clean abstractions.  Such are generally easier to code, easier
to understand, and easier to debug, should such be necessary.  And I
assure you that in my head, the abstractions, particularly that of
islands, came before the design.

I see three layers of software, here:  Major modes, super modes, and
subsystems.  What is the relationship of each of them to islands?

Super modes essentially deal with islands - that is what their main
purpose is.  They create islands, they destroy them, possibly they
coalesce them, they coordinate the rare interactions between islands
(yanking for example), they coordinate change hooks as they affect
islands.  Most of the changes I have proposed is in features directly to
support super modes' handling of islands.

Subsystems code, like redisplay, font locking, timers, ...., is going to
have to deal with islands incidentally - that is not its main purpose,
but there is no getting away from it.  A redisplay action might act on
several islands, so might a font locking action.  And so on.

But major modes?  The abstraction I propose is that major modes see their
own parts of the buffer as the entire buffer, and know nothing of
islands or gaps between them.  This is a clean abstraction and will lead
to all the advantages enumerated a few paragraphs back.

Eli, you seem to disagree with the above analysis.  Would you like to
outline your scheme of abstractions on this topic?

You say that extensive changes will be needed to support multiple modes
in a buffer, and this is clearly true.  Where we seem to differ is where
these changes should be made.  I want the vast bulk of these changes to
be in super mode support and subsystems.  You seem additionally to want
to make subtantial changes in the major mode "layer".  I cannot see this
as a good thing at the moment.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).