From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: Re: Better parse-partial-sexp; multiple major modes Date: Sun, 31 Aug 2008 17:02:36 +0200 Message-ID: <48BAB28C.9000407@gmail.com> References: <20080726214429.GB3623@muc.de> <20080727145058.GA1598@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220194977 26040 80.91.229.12 (31 Aug 2008 15:02:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2008 15:02:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 31 17:03:52 2008 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.50) id 1KZoT1-0007D1-Nz for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 17:03:52 +0200 Original-Received: from localhost ([127.0.0.1]:46977 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZoS3-0006Tj-4Y for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 11:02:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZoRx-0006PJ-NA for emacs-devel@gnu.org; Sun, 31 Aug 2008 11:02:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZoRw-0006Nj-Ot for emacs-devel@gnu.org; Sun, 31 Aug 2008 11:02:45 -0400 Original-Received: from [199.232.76.173] (port=54407 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZoRw-0006NX-J5 for emacs-devel@gnu.org; Sun, 31 Aug 2008 11:02:44 -0400 Original-Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]:52860) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KZoRw-0003Xj-23 for emacs-devel@gnu.org; Sun, 31 Aug 2008 11:02:44 -0400 Original-Received: from c83-254-151-87.bredband.comhem.se ([83.254.151.87]:60895 helo=[127.0.0.1]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1KZoRs-0000rQ-76; Sun, 31 Aug 2008 17:02:40 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 In-Reply-To: X-Enigmail-Version: 0.95.7 X-Antivirus: avast! (VPS 080830-0, 2008-08-30), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.151.87 X-Scan-Result: No virus found in message 1KZoRs-0000rQ-76. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1KZoRs-0000rQ-76 7e67b4f9a953f4d6e98d40db2d230a2a X-detected-kernel: by monty-python.gnu.org: Linux 2.6? (barebone, rare!) 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:103321 Archived-At: Daniel Colascione wrote: >> Also, Lennart is asking for it to work nicely with multiple major modes. >> Surely this would be a Good Thing. Files containing several major modes >> are commonplace (awk or sed embedded within a shell script, html >> embedded within php, ....). > > After several attempts at using and understanding multiple major mode > facilities, I'm convinced the only way forward is core support for the > concept. Lennart's done a fine job with what's in Emacs currently. But > anything involving multiple major modes today is a quivering mound of > hacks. All the work Lennart's had to do to get modes playing nice with > each other is a testament to that. Are you suggesting that you have problems using MuMaMo today? If so then please report it as a bug. > Maybe a core solution could be something like this: in a given buffer, > each character has a chunk-name character property. You'd buffer-locally > map chunk names to major modes. For each chunk name, create a buffer > containing just the text assigned to that chunk. Make the major-mode the > major mode for the chunk buffer, and let that major-mode handle > fontification, keybindings, and so on. In the main buffer, assemble the > various bits from the chunk-buffers and allow the user to navigate the > combined buffer normally. This was an idea I played with at the beginning when I wrote mumamo.el. I am afraid I think the concepts involved (like buffer local etc) must be considered quite a bit more first before going in this direction. It is unclear to me now whether chunk-buffers really would be of any help. They might be, but I am not sure. > Keybindings with point at a particular character would just be the > keybindings present in that character's chunk-buffer. If you need > special keybindings common across all chunk buffers, just bind the key > in all the chunk buffers. If a given chunk needs placeholder text to > represent text of some other chunk, it should be possible add it to that > chunk buffer without affecting any of the others. > > Anyway, this scheme is: > > 1) Robust - no messing around with variables, no tweaking fontification Unfortunately I do not think that will hold. I think the way to go is "interface style". font-lock has some good support for making multiple major modes possible. > 2) Backwards compatible - a major-mode doesn't need to know it's being > used this way Are you aware of that a major mode does not need to know anything when used in MuMaMo? > 3) Versatile - you can compose arbitrary modes this way, even recursively The main difficulty with sub-modes in sub-modes is stability. How do you find the sub-modes in sub-modes after buffer changes? I think I know how to implement this in MuMaMo, but I do not have time right now. (And it is not very much needed.) > 4) Conceptually simple (I hope) > > Any thoughts? > > >