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

[Lennart Borgman <lennart.borgman@gmail.com>]

On Tue, Nov 23, 2010 at 2:20 AM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> 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).

Maybe indirect buffers could be used too, but I am not sure it is
needed (for hiding portions of the buffer text).

However in the current (not released) version of mumamo.el I have
implemented "mirror buffers" (or tried to do it, it is not that easy)
that copies chunks with the same major modes to a new buffer and
leaves the rest of the buffer blank. This is not intended for long
time use - instead it is meant as a way to prove the concept and move
on to a better implementation (the one we are talking about here).