all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lennart Borgman <lennart.borgman@gmail.com>
To: David De La Harpe Golden <david@harpegolden.net>
Cc: Alan Mackenzie <acm@muc.de>,
	Lars Magne Ingebrigtsen <larsi@gnus.org>,
	rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Islands and streams [Was: convert regex.c, .... to standard C]
Date: Tue, 23 Nov 2010 02:26:23 +0100	[thread overview]
Message-ID: <AANLkTi=7rkwwq8ADs8za-XSQBO14M8jLnjbUOG-=TVE7@mail.gmail.com> (raw)
In-Reply-To: <4CEB16CA.6060901@harpegolden.net>

On Tue, Nov 23, 2010 at 2:20 AM, David De La Harpe Golden
<david@harpegolden.net> wrote:
> 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.
>>
>> POSSIBLE USES OF ISLANDS:
>> (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.
>>
>> POSSIBLE USE OF STREAMS:
>> (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).

Maybe indirect buffers could be used too, but I am not sure it is
needed (for hiding portions of the buffer text).

However in the current (not released) version of mumamo.el I have
implemented "mirror buffers" (or tried to do it, it is not that easy)
that copies chunks with the same major modes to a new buffer and
leaves the rest of the buffer blank. This is not intended for long
time use - instead it is meant as a way to prove the concept and move
on to a better implementation (the one we are talking about here).



  reply	other threads:[~2010-11-23  1:26 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-15  6:03 convert regex.c, strftime.c mktime.c to standard C Dan Nicolaescu
2010-11-15 17:19 ` Stefan Monnier
2010-11-15 22:01 ` Richard Stallman
2010-11-16 15:45   ` Dan Nicolaescu
2010-11-17 19:29     ` Richard Stallman
2010-11-18  4:21       ` Dan Nicolaescu
2010-11-19  6:16         ` Richard Stallman
2010-11-19  7:39           ` Eli Zaretskii
2010-11-19 16:58             ` Chong Yidong
2010-11-19 17:10               ` Sam Steingold
2010-11-19 17:15               ` Lars Magne Ingebrigtsen
2010-11-19 17:52                 ` Eli Zaretskii
2010-11-19 18:02                   ` Lars Magne Ingebrigtsen
2010-11-19 18:10                     ` Eli Zaretskii
2010-11-19 18:54                       ` Lars Magne Ingebrigtsen
2010-11-19 19:05                         ` Lars Magne Ingebrigtsen
2010-11-19 19:23                           ` Lars Magne Ingebrigtsen
2010-11-19 18:11                     ` Sven Joachim
2010-11-19 18:10                 ` Andreas Schwab
2010-11-20 11:57             ` Bruno Haible
2010-11-20 12:35               ` Eli Zaretskii
2010-11-20 15:43                 ` Bruno Haible
2010-11-20 17:19                   ` Eli Zaretskii
2010-11-21  0:37                     ` Bruno Haible
2010-11-20 17:52                   ` David De La Harpe Golden
2010-11-21  0:14                     ` Bruno Haible
2010-11-20 11:00   ` Bruno Haible
2010-11-21  7:42     ` Richard Stallman
2010-11-21 17:25       ` Lars Magne Ingebrigtsen
2010-11-22 16:35         ` Richard Stallman
2010-11-22 16:45           ` Lars Magne Ingebrigtsen
2010-11-22 16:59             ` Lennart Borgman
2010-11-22 19:38               ` Islands and streams [Was: convert regex.c, .... to standard C] Alan Mackenzie
2010-11-23  1:20                 ` David De La Harpe Golden
2010-11-23  1:26                   ` Lennart Borgman [this message]
2010-11-23  4:48                 ` Stefan Monnier
2010-11-23 18:26                   ` Eli Zaretskii
2010-11-23 19:01                   ` Lennart Borgman
2010-11-23 20:08                     ` Stefan Monnier
2010-11-23  9:21                 ` Islands and streams David Kastrup
2010-11-23 22:23                   ` Alan Mackenzie
2010-11-23 22:42                     ` Lennart Borgman
2010-11-24 17:13                 ` Islands and streams [Was: convert regex.c, .... to standard C] Chong Yidong
2010-11-22 19:39             ` convert regex.c, strftime.c mktime.c to standard C Stefan Monnier
2010-11-23 17:19             ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=7rkwwq8ADs8za-XSQBO14M8jLnjbUOG-=TVE7@mail.gmail.com' \
    --to=lennart.borgman@gmail.com \
    --cc=acm@muc.de \
    --cc=david@harpegolden.net \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.