From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Islands and streams [Was: convert regex.c, .... to standard C] Date: Tue, 23 Nov 2010 02:26:23 +0100 Message-ID: References: <201011201200.06827.bruno@clisp.org> <20101122193824.GA2745@muc.de> <4CEB16CA.6060901@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1290475632 16731 80.91.229.12 (23 Nov 2010 01:27:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Nov 2010 01:27:12 +0000 (UTC) Cc: Alan Mackenzie , Lars Magne Ingebrigtsen , rms@gnu.org, emacs-devel@gnu.org To: David De La Harpe Golden Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 23 02:27:07 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 1PKhf1-0001Vm-53 for ged-emacs-devel@m.gmane.org; Tue, 23 Nov 2010 02:27:07 +0100 Original-Received: from localhost ([127.0.0.1]:56336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKhf0-0008S9-6O for ged-emacs-devel@m.gmane.org; Mon, 22 Nov 2010 20:27:06 -0500 Original-Received: from [140.186.70.92] (port=54314 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKheo-0008Pi-VU for emacs-devel@gnu.org; Mon, 22 Nov 2010 20:27:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKhee-000058-Nb for emacs-devel@gnu.org; Mon, 22 Nov 2010 20:26:54 -0500 Original-Received: from mail-ew0-f41.google.com ([209.85.215.41]:55763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKhee-00004y-G1; Mon, 22 Nov 2010 20:26:44 -0500 Original-Received: by ewy21 with SMTP id 21so577828ewy.0 for ; Mon, 22 Nov 2010 17:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=S705oHKhW405fsLX11Rdn5LiHAxPQpZU3wEPdKUdF9g=; b=brFGPNLHQQoeOvoSVtN62063eYaxNnMzdOVmZ3ILQJtZGDribgQkWnReyza2QjzsgT s99v0ZsR47vkF7XuVfOUBEH+uyQ/In7PTLPIAfTVt2WInlHGeYaj6fLmSxE8PrknMZSF Pi03oD/9lSFv9oBGcxfLCOUxZlf5Qefp121ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=BjdCZFopKZs/QFJjdSu80zt8OWDBau3lHOHfvOdcMoAG+UbiWnwubsLAo/ObMg4T0a wv0CcZN0REqefa8I2LIdEcqFwnYalyQqADNubkH0VeFVAtetD6weZcKF1TG14GCN1T4N kowILZk5zdXzDWkug/17IaU+aMDszoln7cFq4= Original-Received: by 10.213.34.20 with SMTP id j20mr5656084ebd.71.1290475603476; Mon, 22 Nov 2010 17:26:43 -0800 (PST) Original-Received: by 10.213.22.135 with HTTP; Mon, 22 Nov 2010 17:26:23 -0800 (PST) In-Reply-To: <4CEB16CA.6060901@harpegolden.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:133036 Archived-At: On Tue, Nov 23, 2010 at 2:20 AM, David De La Harpe Golden wrote: > On 22/11/10 19:38, Alan Mackenzie wrote: > >> So have I, vaguely. =C2=A0Here are my thoughts: >> >> Emacs's syntax and movement routines should be enhanced to handle >> "islands". =C2=A0An @dfn{island} is a contiguous region of text where a >> major mode different from the surrounding text's is in force. =C2=A0It m= ight >> 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. =C2=A0By binding variable "respect-islan= ds" 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}. =C2=A0When respect-islands is non-nil, movement commands c= an >> 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. =C2=A0This is obvious. >> (ii) In CC Mode: implementing macros as islands would drastically >> =C2=A0 simplify CC Mode. >> (iii) In Shell-script mode: embedded "here documents" could be edited in >> =C2=A0 their own mode (e.g. AWK Mode). >> (iv) (Maybe) Line comments could be islands. =C2=A0This might be a bit o= ver >> =C2=A0 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 someth= ing > about foliating with sortof hidden indirect buffers (rather mutant ones) > last time this was discussed? =C2=A0Making two indirect buffers to an und= erlying > buffer and putting the indirect buffers in different modes already "nearl= y > works" (though there are undoubtedly a lot of details that don't). =C2=A0= 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).