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

[Eli Zaretskii]

> Date: Sat, 23 Apr 2016 21:08:07 +0000
> Cc: address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> 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?

Most of my comments were not about the abstractions.  I don't have any
alternative scheme to offer, because I have no experience in using,
let alone writing, multiple modes in the same buffer.

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

I'm saying that worrying about the amount of changes in major modes at
this stage is premature optimization.  If major modes will have to
adapt themselves in non-trivial ways, e.g. by changing their regexps
or font-lock settings, it's not a big deal.  It is much more important
to make sure the design doesn't contradict more basic assumptions and
design principles of Emacs, including the low-level code which
implements searching, syntax, redisplay, etc., because if the
contradiction does happen, you will at best have a bunch of hairy
problems to solve, and at worst will simply fail to produce a workable
solution.

IOW, I suggest to forget for a while about the amount of changes major
modes will need, and leave that for later.  At this stage, you should
be worried much more about how core design features of Emacs will work
with islands, and make sure you have all that figured out, before you
decide that the island design is valid.  In practice, this means that,
for example, I would expect you to study all the uses of search in the
low-level code, before you decide that making [:space:] match an
island edge is sound.  E.g., did you know that even bidi.c, which is
about as low-level as you can get, uses regexp search to look for a
certain combination of whitespace characters?  Did you consider how
this will work when islands are in the way?  What about basic features
like find_newline -- did you look into that?  You see, if any of these
break due to islands, you have some major rewrites on your hands, and
the ripples will probably be very far-reaching.  The need to change
major modes pales by comparison.