Re: multi-mode editing, including literate Haskell and noweb

[Dave Love]

Richard Stallman <address@hidden> 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 <URL:ftp://dlpx1.dl.ac.uk/fx/emacs/multi-mode.el>.  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.