Re: Islands and streams

[Lennart Borgman]

On Tue, Nov 23, 2010 at 11:23 PM, Alan Mackenzie <address@hidden> wrote:
> Evening, David!
>
> On Tue, Nov 23, 2010 at 10:21:32AM +0100, David Kastrup wrote:
>> Alan Mackenzie <address@hidden> writes:
>
>> > 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.
>
>> [...]
>
>> > What do people think (other than the obvious, that I should implement it
>> > myself ;-)?
>
>> That it is an excessively bad idea.  Lots of Elisp code relies on
>> (= (1+ (point)) (save-excursion (forward-char) (point)))
>> and similar equivalences.  For this reason, "intangible" regions have
>> never worked reliably, and only in very limited contexts.  Also for this
>> reason, multibyte support was quite unreliable and unpredictable until
>> buffer positions were made to correspond to character positions instead
>> of byte counts.
>
> That's a good point.  But by default, the new feature would not be
> enabled.  Only when a major mode binds `respect-islands' would it come
> into effect, and presumably the major mode would know what it was doing.

Maybe I am misunderstanding something here. What I proposed was low
level changes that makes chunks in other major modes look like they
were just filled with spaces.

Is not this the same as you propose, Alan?
Is there any problems with such a change? (Other than implementing it. ;-)