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

[Drew Adams]

[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?

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

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

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

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

[The `isearch-prop.el' code can use zones defined by either
their limits (e.g., markers) or text or overlay properties
on their text.  It lets commands like `query-replace' do
similarly.]