From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Islands and streams [Was: convert regex.c, .... to standard C] Date: Tue, 23 Nov 2010 01:20:10 +0000 Message-ID: <4CEB16CA.6060901@harpegolden.net> References: <201011201200.06827.bruno@clisp.org> <20101122193824.GA2745@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1290475235 15430 80.91.229.12 (23 Nov 2010 01:20:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Nov 2010 01:20:35 +0000 (UTC) Cc: Lars Magne Ingebrigtsen , Lennart Borgman , rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 23 02:20:30 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PKhYb-0007me-Bc for ged-emacs-devel@m.gmane.org; Tue, 23 Nov 2010 02:20:29 +0100 Original-Received: from localhost ([127.0.0.1]:45179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKhYa-00061c-N6 for ged-emacs-devel@m.gmane.org; Mon, 22 Nov 2010 20:20:28 -0500 Original-Received: from [140.186.70.92] (port=59944 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKhYS-00061W-B6 for emacs-devel@gnu.org; Mon, 22 Nov 2010 20:20:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKhYN-0007XZ-Et for emacs-devel@gnu.org; Mon, 22 Nov 2010 20:20:20 -0500 Original-Received: from harpegolden.net ([65.99.215.13]:60956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKhYM-0007XV-Tb; Mon, 22 Nov 2010 20:20:15 -0500 Original-Received: from [87.198.54.231] (87-198-54-231.ptr.magnet.ie [87.198.54.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id 86E84683A2; Tue, 23 Nov 2010 01:20:12 +0000 (GMT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10 In-Reply-To: <20101122193824.GA2745@muc.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133035 Archived-At: 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 no= t. > 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 encountere= d, > 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 i= n > 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 i= t > myself ;-)? > in a way (a vague way) similar to what you're saying- wasn't there=20 something about foliating with sortof hidden indirect buffers (rather=20 mutant ones) last time this was discussed? Making two indirect buffers=20 to an underlying buffer and putting the indirect buffers in different=20 modes already "nearly works" (though there are undoubtedly a lot of=20 details that don't). If the stretches "belonging" to the indirect=20 buffer in mode X were sortof intangible stretches in the indirect buffer=20 in mode Y and vice-versa, existing modes would need minimal adaptation=20 (less than (IIRC) current mumamo's requirement for play-nice font=20 locking everywhere). (A below being the same type of mode as a, but nested in b, say a html=20 string literal in javascript in html. Or something.) aaabbbbbaaaabbbaabbbcccccbbAAAbbbbaaaaaaa [0] splitter | |: :| |: :||: :| | aaa_____aaaa___aa_________________aaaaaaa [a from 0] mode ma : : : : : : ___bbbbb____bbb__bbbcccccbbAAAbbbb_______ [=C2=ACa from 0] splitter | | | | | |: :||: :| | ___bbbbb____bbb__bbb_____bb___bbbb_______ [b from =C2=ACa] mode mb : : : : ____________________ccccc__AAA___________ [=C2=ACb from =C2=ACa] splitt= er | | : : ____________________ccccc________________ [c from =C2=ACb] mode mc : : ___________________________AAA___________ [A from =C2=ACb] mode ma ::::::::::::::::::::::::::::::::::::::::: aaabbbbaaaabbbaabbbccccccbbAAAbbbaaaaaaaa Unifier (solid handwavium)