unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: multi-mode editing, including literate Haskell and noweb
Date: Sun, 02 Jan 2005 11:06:24 -0500	[thread overview]
Message-ID: <E1Cl8FM-0007I2-Ru@fencepost.gnu.org> (raw)
In-Reply-To: <rzqk74689zo.fsf@albion.dl.ac.uk> (message from Dave Love on Mon,  05 Jan 2004 19:35:07 +0000)

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?

       reply	other threads:[~2005-01-02 16:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <rzqk74689zo.fsf@albion.dl.ac.uk>
2005-01-02 16:06 ` Richard Stallman [this message]
2005-01-04 23:36   ` multi-mode editing, including literate Haskell and noweb Dave Love
2005-01-05 20:07     ` Richard Stallman
2005-01-06  1:13       ` Miles Bader
2005-01-06 19:56         ` Richard Stallman
2005-01-17 22:56           ` Dave Love
2005-01-05 20:07     ` Richard Stallman
2005-01-17 11:57   ` David Hansen
2005-01-18 11:05     ` Richard Stallman
2005-01-18 18:00       ` David Hansen
2005-01-20  2:14         ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1Cl8FM-0007I2-Ru@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).