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

[Drew Adams <drew.adams@oracle.com>]

> > 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 guess you're referring to point movements, among other things.

`isearch-filter-predicate', or similar, could presumably be made
so (more widely applicable).  It is also used by `perform-replace'
(e.g. `query-replace'), BTW - not just search.

The point is that a predicate is more general than a regexp, and
it doesn't interfere with the use of a regexp (and vice versa).

> > > 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.
> >
> > `isearch-filter-predicate'.  It can let code know whether
> > you are island-searching or not.
> 
> That would only work for isearch.

Not if other code takes it into account.  It only worked for
search until `perform-replace' started taking it into account.

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

What's the alternative?  If you're worried about different
modes (for example) for aaaaaa and bbbbbb then consider
keeping lists of markers per mode (or whatever) - like we
sometimes handle overlays using one or more lists.

Anyway, it was only a "FWIW".  I use both text properties
and markers.  There are advantages and disadvantages to
any implementation.

Also, where I use markers I allow extra info in a given
zone, in addition to the markers:

;; A "basic zone" is a list of two buffer positions followed
;; by a possibly empty list of extra information:
;; (POS1 POS2 . EXTRA).

IOW, some info is location-specific (buffer and position),
and other info (EXTRA) is zone-specific.

In your scenario, if a zone's second marker is deleted
then code could decide, based on whatever (including whether
or not aaaaaaaa and bbbbbbbb are in the same mode or have
compatible "EXTRA" island info), whether to: coalesce them,
delete them (as islands, not the text), or keep them separate.

The point is that the code can do anything.  But yes, a
single marker does not record more than a buffer and a
position.  I think, however, that the additional info
you are wanting to associate here is really (typically, at
least) info to associate with the island, and not info to
associate with an individual marker.