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: multi-mode editing, including literate Haskell and noweb Date: Sun, 02 Jan 2005 11:06:24 -0500 Message-ID: References: Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1104682450 29933 80.91.229.6 (2 Jan 2005 16:14:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Jan 2005 16:14:10 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 02 17:14:04 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cl8Ml-0003bA-00 for ; Sun, 02 Jan 2005 17:14:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cl8Xr-0005q1-5N for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2005 11:25:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cl8Xd-0005nC-Kr for emacs-devel@gnu.org; Sun, 02 Jan 2005 11:25:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cl8Xc-0005mC-8Y for emacs-devel@gnu.org; Sun, 02 Jan 2005 11:25:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cl8Xc-0005m4-5D for emacs-devel@gnu.org; Sun, 02 Jan 2005 11:25:16 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cl8LT-0001mI-3Y for emacs-devel@gnu.org; Sun, 02 Jan 2005 11:12:43 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Cl8FM-0007I2-Ru; Sun, 02 Jan 2005 11:06:25 -0500 Original-To: Dave Love In-reply-to: (message from Dave Love on Mon, 05 Jan 2004 19:35:07 +0000) 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: main.gmane.org gmane.emacs.devel:31692 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31692 A year after you posted it, I finally read the source code of install.el. (I was far too backlogged to read source code last January.) It looks like a plausible approach, and it suggested to me an idea that could make matters simpler. The idea is to add a facility to swap certain buffer-local information between a given indirect buffer and its base buffer. By using this instead of selecting one of the indirect buffers, it would be possible to do more or less what you've done, but always keeping the base buffer selected. I think a good first approximation to the set of buffer-local information to swap would be all buffer-local variables that are not permanent locals. However, it would be necessary to think about each of the built-in buffer slots to decide whether to swap it or not. Aside from that, here are some other comments on where the code could use work. * There is a good reason why `multi-mode-alist' would be considered an unsafe local variable. This usage *is* unsafe; the value contains functions to call. These combinations cannot be defined through a local variable list. Anything that would enable that would also enable viruses. Each multi-mode combination needs to have an explicit definition with Lisp code. * The hack used to avoid processing the `mode' local variable is unclean; it needs to be done differently. One easy way would be to add a new argument to hack-local-variables, NO-MODES. However, I think a cleaner idea is to record a list of what was in the file's local variables list. Then multi-mode could go through it and process it in the appropriate way. * multi-with-ignored-fn is very unclean and should not be installed. * The doc string of multi-chunk-fns doesn't clearly say how the values of the various functions are used in order to decide on a chunk. Looking at multi-find-mode-at, that seems to be nontrivial. Have you done any work on this since a year ago? Do you want to do more?