From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: [MMM] Re: narrow-to-here-document Date: Thu, 10 Jul 2003 12:44:39 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: 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> <84ptklfpt5.fsf@lucy.is.informatik.uni-duisburg.de> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1057858724 17824 80.91.224.249 (10 Jul 2003 17:38:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 10 Jul 2003 17:38:44 +0000 (UTC) Cc: mmm-mode-discuss@lists.sourceforge.net, monnier+gnu/emacs@cs.yale.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Jul 10 19:38:40 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 19afMH-0004Vt-00 for ; Thu, 10 Jul 2003 19:37:29 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19afXg-0000SF-00 for ; Thu, 10 Jul 2003 19:49:16 +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 19aejE-0000VN-If for emacs-devel@quimby.gnus.org; Thu, 10 Jul 2003 12:57:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19aeg0-0000D3-5W for emacs-devel@gnu.org; Thu, 10 Jul 2003 12:53:48 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19aeXb-0006e6-M0 for emacs-devel@gnu.org; Thu, 10 Jul 2003 12:45:07 -0400 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19aeXB-0006RJ-8z for emacs-devel@gnu.org; Thu, 10 Jul 2003 12:44:41 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.20) id 19aeX9-0008MA-J4; Thu, 10 Jul 2003 12:44:39 -0400 Original-To: kai.grossjohann@gmx.net (=?iso-8859-1?q?Kai_Gro=DFjohann?=) In-reply-to: <84ptklfpt5.fsf@lucy.is.informatik.uni-duisburg.de> (kai.grossjohann@gmx.net) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15533 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15533 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 think I see a misunderstanding, because this is not what I meant to suggest. I suggested pseudo-indirect buffers as a way of being able to deal with the same text using different key bindings, different buffer-local values, different major modes. In effect, they are themes for bindings. They would all share the same text, just as user-visible indirect buffers do. The idea of splitting up the text into many small buffers which would be virtually concatenated is a completely different one. I think that idea is a non-starter because it would require changing nearly every Emacs primitive in a very complex way. 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. This has the merit that we could implement it for syntax parsing and font lock without changing most of Emacs at all.