[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Islands and streams
From: |
David Kastrup |
Subject: |
Re: Islands and streams |
Date: |
Tue, 23 Nov 2010 10:21:32 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
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.
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.
Other than that, it will never work reliably.
--
David Kastrup
- Re: convert regex.c, strftime.c mktime.c to standard C, (continued)
- Re: convert regex.c, strftime.c mktime.c to standard C, Richard Stallman, 2010/11/22
- Re: convert regex.c, strftime.c mktime.c to standard C, Lars Magne Ingebrigtsen, 2010/11/22
- Re: convert regex.c, strftime.c mktime.c to standard C, Lennart Borgman, 2010/11/22
- Islands and streams [Was: convert regex.c, .... to standard C], Alan Mackenzie, 2010/11/22
- Re: Islands and streams [Was: convert regex.c, .... to standard C], David De La Harpe Golden, 2010/11/22
- Re: Islands and streams [Was: convert regex.c, .... to standard C], Lennart Borgman, 2010/11/22
- Re: Islands and streams [Was: convert regex.c, .... to standard C], Stefan Monnier, 2010/11/22
- Re: Islands and streams [Was: convert regex.c, .... to standard C], Eli Zaretskii, 2010/11/23
- Re: Islands and streams [Was: convert regex.c, .... to standard C], Lennart Borgman, 2010/11/23
- Re: Islands and streams [Was: convert regex.c, .... to standard C], Stefan Monnier, 2010/11/23
- Re: Islands and streams,
David Kastrup <=
- Re: Islands and streams, Alan Mackenzie, 2010/11/23
- Re: Islands and streams, Lennart Borgman, 2010/11/23
- Re: Islands and streams [Was: convert regex.c, .... to standard C], Chong Yidong, 2010/11/24
- Re: convert regex.c, strftime.c mktime.c to standard C, Stefan Monnier, 2010/11/22
- Re: convert regex.c, strftime.c mktime.c to standard C, Richard Stallman, 2010/11/23