[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).
- Re: convert regex.c, strftime.c mktime.c to standard C, (continued)
- 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, 2010/11/23
- Re: Islands and streams,
Alan Mackenzie <=
- 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