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

[Alan Mackenzie <acm@muc.de>]

Hello, Drew.

On Thu, Apr 21, 2016 at 03:01:12PM -0700, Drew Adams wrote:
> [More interesting details.  Thx.]

> > Given a buffer position, we need to be able to find the corresponding
> > island chain.  "Obviously", we do this with a text property, which we
> > might as well call `island', or possibly `chain'.  Since successive
> > accesses to chain local variables are very likely to be in the same
> > chain most of the time, we will cache the "current" chain in buffer
> > local variables.

> I guess you are referring to the possibility of more than one
> chain having an island at point, and wanting to pick up the right
> one as the "current" chain - so you check a text property, which
> identifies the chain that is currently active.  Is that right?

Er, no.  ;-)  Even when there is only one island at point, we still need
to determine it.  A text property is a good way of doing this.

> > When it comes to movement and search primitives, we want to adapt these
> > so that the impact on existing major modes is minimised.  Ideally, we
> > would want major modes to "see" only their own islands (or lack
> > thereof).  Thus we treat irrelevant islands as blocks of whitespace.  It
> > seems to make sense to have such islands matched by subexpressions in
> > regexps which match spaces.  This would obviate the need to amend a
> > great number of regexps currently coded in major modes.

> For search, at least, I don't see why you don't make use of
> `isearch-filter-predicate'.  That's what I do in my code, to
> search only within (or without: complement) a set of zones
> (~chain of islands).  That seems simple and cheap.

Thanks, I didn't know about that variable.  But it may not be widely
applicable enough.

> [I also optionally dim the non-islands during search (or the
> non-non-islands, if complementing), so the areas being searched
> stand out more.]

That's another matter, at a different level of abstraction from the main
topic.

> > On the other hand, when a user does C-s or C-M-s, the Right Thing is
> > surely to search the buffer as a whole, without regard to islands.  We
> > therefore need a flag which instructs the primitives how to behave when
> > there are islands.  We might as well call this flag `in-islands', for
> > want of a better name.

> `isearch-filter-predicate'.  It can let code know whether
> you are island-searching or not.

That would only work for isearch.

> > The user will, from time to time, delete the delimiters which define
> > islands, and will insert other ones.

> FWIW, markers as delimiters do not have that problem.

I think they do.  What happens when you have two islands bounded by four
markers, and you delete a region containing the two middle markers;

      MaaaaaaaaaaaM       MbbbbbbbbbbbbbM
               dddddddddddddddddd

?  You might well not want the two islands a and b to be coalesced.

-- 
Alan Mackenzie (Nuremberg, Germany).