[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David De La Harpe Golden
Subject: Re: Islands and streams [Was: convert regex.c, .... to standard C]
Date: Tue, 23 Nov 2010 01:20:10 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101030 Icedove/3.0.10

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.

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

(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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]