Re: Islands and streams [Was: convert regex.c, .... to standard C]

[David De La Harpe Golden <david@harpegolden.net>]

On 22/11/10 19:38, Alan Mackenzie wrote:

> So have I, vaguely.  Here are my thoughts:
>
> Emacs's syntax and movement routines should be enhanced to handle
> "islands".  An @dfn{island} is a contiguous region of text where a
> major mode different from the surrounding text's is in force.  It might
> be feasible to mark an island with syntax-table text props, it might not.
> Islands can be nested.
>
> Movement commands normally don't recognise islands as anything unusual,
> and just move into/out of them.  By binding variable "respect-islands" to
> non-nil, any movement command would skip over any islands it encountered,
> and such commands could not move point out of an island.
>
> Several islands with the same major mode can by chained together as a
> @dfn{stream}.  When respect-islands is non-nil, movement commands can
> jump over the "ocean" to the next/previous island in the chain.
>
> Some other Emacs features, such as font locking, would need enhancement.
>
> POSSIBLE USES OF ISLANDS:
> (i) In mumamo.  This is obvious.
> (ii) In CC Mode: implementing macros as islands would drastically
>    simplify CC Mode.
> (iii) In Shell-script mode: embedded "here documents" could be edited in
>    their own mode (e.g. AWK Mode).
> (iv) (Maybe) Line comments could be islands.  This might be a bit over
>    the top.
> (v) In putative LEX and YACC Modes.
>
> POSSIBLE USE OF STREAMS:
> (i) In literate programing.
>
> What do people think (other than the obvious, that I should implement it
> myself ;-)?
>

in a way (a vague way) similar to what you're saying- wasn't there 
something about foliating with sortof hidden indirect buffers (rather 
mutant ones) last time this was discussed?  Making two indirect buffers 
to an underlying buffer and putting the indirect buffers in different 
modes already "nearly works" (though there are undoubtedly a lot of 
details that don't).  If the stretches "belonging" to the indirect 
buffer in mode X were sortof intangible stretches in the indirect buffer 
in mode Y and vice-versa, existing modes would need minimal adaptation 
(less than (IIRC) current mumamo's requirement for play-nice font 
locking everywhere).

(A below being the same type of mode as a, but nested in b, say a html 
string literal in javascript in html. Or something.)

aaabbbbbaaaabbbaabbbcccccbbAAAbbbbaaaaaaa [0] splitter
| |:   :|  |: :||:               :|     |
aaa_____aaaa___aa_________________aaaaaaa  [a from 0] mode ma
    :   :    : :  :               :
___bbbbb____bbb__bbbcccccbbAAAbbbb_______  [¬a from 0] splitter
    |   |    | |  | |:   :||: :|  |
___bbbbb____bbb__bbb_____bb___bbbb_______   [b from ¬a] mode mb
                     :   :  : :
____________________ccccc__AAA___________   [¬b from ¬a] splitter
                     |   |  : :
____________________ccccc________________    [c from ¬b] mode mc
                            : :
___________________________AAA___________    [A from ¬b] mode ma

:::::::::::::::::::::::::::::::::::::::::
aaabbbbaaaabbbaabbbccccccbbAAAbbbaaaaaaaa  Unifier (solid handwavium)