[Top][All Lists]

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

Re: Islands and streams

From: Alan Mackenzie
Subject: Re: Islands and streams
Date: Tue, 23 Nov 2010 22:23:25 +0000
User-agent: Mutt/1.5.9i

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.

> If you want something like this to work at all, all "wrong" parts of the
> buffer must disappear completely from character counts and similar.
> Then you need not worry about fixing syntax highlighting and similar.
> It will just work.

You mean, throw out the absolutely standard buffer position integer?

> Other than that, it will never work reliably.

Thanks for the optimism!  ;-)

> -- 
> David Kastrup

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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