From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: kai.grossjohann@gmx.net (=?iso-8859-1?q?Kai_Gro=DFjohann?=) Newsgroups: gmane.emacs.devel Subject: Re: [MMM] Re: narrow-to-here-document Date: Tue, 08 Jul 2003 09:19:50 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <84ptklfpt5.fsf@lucy.is.informatik.uni-duisburg.de> References: <20030620141028.GA1331@math.berkeley.edu> <20030621.012632.74543482.jet@gyve.org> <3EF73468.1030503@yahoo.com> <84r85cw0rk.fsf@lucy.is.informatik.uni-duisburg.de> <200307040032.h640WhKL015234@rum.cs.yale.edu> <20030707234541.GC11786@schilling.ugcs.caltech.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1057651305 25251 80.91.224.249 (8 Jul 2003 08:01:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 8 Jul 2003 08:01:45 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jul 08 10:01:43 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19ZnPz-0006Z8-00 for ; Tue, 08 Jul 2003 10:01:43 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19ZnaE-0008M7-00 for ; Tue, 08 Jul 2003 10:12:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19ZnOn-0007tI-NW for emacs-devel@quimby.gnus.org; Tue, 08 Jul 2003 04:00:29 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19ZnNo-0007TP-Ve for emacs-devel@gnu.org; Tue, 08 Jul 2003 03:59:28 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19ZnNB-0006mH-Jh for emacs-devel@gnu.org; Tue, 08 Jul 2003 03:58:59 -0400 Original-Received: from perikles.informatik.uni-duisburg.de ([134.91.35.3]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19ZnMx-0006DC-Ch; Tue, 08 Jul 2003 03:58:35 -0400 Original-Received: from lucy (postfix@lucy.is.informatik.uni-duisburg.de [134.91.35.216])h687wFcS820712; Tue, 8 Jul 2003 09:58:15 +0200 (CEST) Original-Received: by lucy (Postfix, from userid 1003) id 32258281BC; Tue, 8 Jul 2003 09:58:25 +0200 (CEST) Original-To: Stefan Monnier Mail-Copies-To: never In-Reply-To: <20030707234541.GC11786@schilling.ugcs.caltech.edu> (Michael A. Shulman's message of "Mon, 7 Jul 2003 16:45:41 -0700") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Original-cc: Richard Stallman Original-cc: mmm-mode-discuss@lists.sourceforge.net X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15480 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15480 "Michael A. Shulman" writes: > 3. Better support in the syntax parsing routines allowing the caller > to specify starting and ending positions and states. One of > our biggest problems is that submodes end up trying to parse their > syntax beyond the beginning of their region and getting confused, so > ideally we would be able to tell them where to start their parsing, > and what state to start parsing in. Sometimes the start state needs > to be a continuation of the end state of the previous region in that > mode (as with some literate programming, PHP, etc.), but sometimes > it ought to be an independent start for each region. Maybe it is sufficient to just allow for ignoring parts of the buffer. Let's say you are mixing modes A and B. Let's further say that each A chunk needs to be considered separately, and all the B chunks should be considered to be concatenated (as in the literate programming case). Then you would arrange things so that when point is in an A region all the rest of the buffer is ignored. And when point is in a B region then all A regions are ignored, but the other B regions are not ignored. The above is based on having a big buffer and to ignore some parts of it, depending on the state we're in. The complementary approach is to have many small buffers and do the editing there, but have one big buffer which serves as a view into the many small buffers. This approach has been suggested by Richard. I feel that it is promising -- it avoids having to tweak the individual modes. The user does C-x C-f mixedfile RET. Then mmm-mode divides the buffer into chunks and puts each chunk into its own buffer. The mixedfile buffer is set up such that all keys are bound to forwarding functions. That is, when you hit a key, mmm-mode figures out which buffer to go to. Then it goes to that chunk-buffer and executes the corresponding command. Then it looks at the changes in the chunk-buffer and propagates them back to the mixedfile buffer. That way, no troubles with syntax, no troubles with font-lock, no trouble with parsing states. When you want to start a new chunk, that might be a bit difficult. But mmm-mode could offer a command mmm-split-chunk or something like this. In the above I've used the term mmm-mode somewhat generically for the desired feature; I didn't mean the current implementation specifically. Kai -- ~/.signature