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

[Eli Zaretskii]

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

> > By hard-wiring this special meaning of [:space:] into your design, you
> > are limiting future (and possibly some rare extant) major modes.
> 
> I don't think it's all that special.  It's natural.

IME, authors who write Emacs features are known to not limit
themselves to only those things that the infrastructure designers deem
"natural".

> > Are you sure that none of the background processing will ever need to
> > treat islands as such?  I'm talking about stuff like timers, process
> > filters and sentinels, hook functions run by redisplay and the command
> > loop, etc.
> 
> All these subsystems will need to be aware of whether they are dealing
> with the buffer as a whole, or merely with an island chain.  They will
> need to bind `in-islands' appropriately, frequently using the value that
> was current when they were invoked.

Which means that code that was never aware of any "current mode" will
need to adapt.  For example, BEGV and ZV (a.k.a pointy-min and
point-max) will be suddenly limited to an island while such code runs.
That's a major issue, IMO, something that will need changes in many
places.
> > > > If it is stored in the text property, then you will have to decide
> > > > what happens when text is copied and yanked elsewhere.
> 
> > > It would be the job of the `island-after-change-function' to strip the
> > > unwanted text properties (both the `island' and `syntax-table' ones) and
> > > to apply any needed new ones to the yanked region.
> 
> > The problem is the decision whether they are unwanted or not.  It's
> > usually not simple to make that decision for text properties that
> > change the way text is displayed, when surrounding text also affects
> > that.
> 
> But that decision has to made somewhere, somehow, by the super mode,
> regardless of how multiple major modes are implemented.

If the implementation is not based on text properties, then it doesn't
have to.

> One detail struck me immediately on seeing the code in
> set_buffer_internal_1.  The code has to cdr its way down the entire
> list of variables in local_var_alist_, despite the fact that only a
> few of them point to C variables.  Maybe it would make sense to
> extract this smaller list into a separate chain.

You can't: redisplay allows Lisp evaluation in some places (like the
mode line), and any Lisp run there will expect to find buffer-local
bindings of all the variables.