From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.devel Subject: Re: multi-mode editing, including literate Haskell and noweb Date: Tue, 04 Jan 2005 23:36:28 +0000 Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1104881900 30171 80.91.229.6 (4 Jan 2005 23:38:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 Jan 2005 23:38:20 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 05 00:38:10 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 1ClyFd-0004ab-00 for ; Wed, 05 Jan 2005 00:38:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClyQr-00079C-Dg for ged-emacs-devel@m.gmane.org; Tue, 04 Jan 2005 18:49:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClyQf-00078x-9u for emacs-devel@gnu.org; Tue, 04 Jan 2005 18:49:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClyQe-00078Y-CQ for emacs-devel@gnu.org; Tue, 04 Jan 2005 18:49:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClyQe-00078D-6m for emacs-devel@gnu.org; Tue, 04 Jan 2005 18:49:32 -0500 Original-Received: from [148.79.80.138] (helo=mserv7.dl.ac.uk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ClyE3-0001xd-B2; Tue, 04 Jan 2005 18:36:31 -0500 X-DL-MFrom: X-DL-Connect: Original-Received: from albion.dl.ac.uk (albion.dl.ac.uk [148.79.80.39]) by mserv7.dl.ac.uk (8.12.10/8.12.8/[ref postmaster@dl.ac.uk]) with ESMTP id j04NaSv4001800; Tue, 4 Jan 2005 23:36:28 GMT Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.35 #1 (Debian)) id 1ClyE0-0001cZ-00; Tue, 04 Jan 2005 23:36:28 +0000 Original-To: rms@gnu.org User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.2 (gnu/linux) X-CCLRC-SPAM-report: 0 : X-Scanned-By: MIMEDefang 2.37 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:31851 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31851 Richard Stallman writes: > A year after you posted it, I finally read the source code of install.el. I assume that means multi-mode.el. > It looks like a plausible approach, I think so after a bit of use. There's another package out there (mmm-mode?) and at least one specialized mode (the old one for noweb) that work by executing the major mode functions when you change regions. That works better in some respects, worse in others, but I can't remember off-hand what all the issues are and what changes to Emacs I though would help with using indirect buffers. [One useful feature for such things might be to give relevant primitives an optional arg for the buffer to work on without having to select the buffer. XEmacs does that, but not consistently as far as I remember. I guess in some cases (`point'?) it might have a significant performance hit.] > 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. That would be better and would probably fix current bugs, such as killing the buffer when you use C-x C-v. I'm not sure you could reliably determine what to swap, though it's probably worth trying. I think that was part of the reason for not trying to do something like that originally, but I don't remember now. I was also thinking of overlays, at least, and how you need to be in the right buffer for them. Something I wondered was whether a buffer could be made somehow to appear discontinuous, similar to having multiple gaps. Such pseudo-gaps would correspond to regions in different modes. That might avoid having to map things like font-lock over regions in Lisp, explicitly for each such feature. I suspect it wouldn't fly, though. > 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. (You have to be careful of things like `buffer-file-coding-system'.) It's worth trying, at least, but I was told there was a feature freeze on. Has that been dropped, as it appears? > * 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. Right. It was partly for test purposes. I don't remember whether I expected real uses. > 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. That's actually what I did in the couple of serious uses I made (literate programming). > * 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. I don't have an opinion on how best to do it. > * multi-with-ignored-fn is very unclean and should not be installed. I'm sure it would be better to avoid it if possible, but I don't think it would look unclean if I'd just used the equivalent `flet'. > * 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. Yes, the functions can behave in an arbitrary way. Normally they will just do a regex search, but I didn't think that was general enough. I can't remember what cases I had in mind. It may bear explaining better; I remember I had to remind myself how it worked last time I wanted to use it. > Have you done any work on this since a year ago? Do you want to do > more? I made a few tweaks, I think, but nothing fundamental. The current version is at . The noweb and haskell modes that use it are in the same directory. (You could install haskell.el from there for simple haskell support on its own.) I can't contribute, though I could advise. I'd rather see all the installed stuff I've worked on released first, though.