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

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

[Richard Stallman]

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?

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

[Dave Love]

Richard Stallman <rms@gnu.org> 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.

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

[Richard Stallman]

    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 we could.

      I was also thinking of
    overlays, at least, and how you need to be in the right buffer for
    them.

We could swap the overlays too.  I wonder, is that hard?

I see that each indirect buffer has its own marker chain, and the
marker therefore specifies one.  The overlays contain markers, and
these specify a buffer too.  To convert each overlay to the other
buffer would not be complex as regards the code.  It might take
noticeable time, if there are lots of overlays, but since the
user is typing it is probably not a problem.

    (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?

No, it has not been dropped.  We are not installing new features now.

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

[Miles Bader]

> We are not installing new features now.

Could have fooled me ... quite a few "new features" seemed to have
showed up in CVS lately, and some of them seem pretty buggy too.

[Examples of buggy new features: escape sequence highlighting,
search-replace match highlighting.]

-Miles

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

[Richard Stallman]

    Could have fooled me ... quite a few "new features" seemed to have
    showed up in CVS lately, and some of them seem pretty buggy too.

These are very minor and localized features.  So when people installed
them, I didn't insist on taking them out.

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

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     Could have fooled me ... quite a few "new features" seemed to have
>     showed up in CVS lately, and some of them seem pretty buggy too.
>
> These are very minor and localized features.  So when people installed
> them, I didn't insist on taking them out.

I guess it's 21.1 over again :-(.  Reported bugs are often not getting
fixed as well.

By the way, on the topic of the subject, I'd put a junk version of
multi-mode.el up for ftp recently -- it lost in modes whose local maps
bind TAB.  I've replaced it.  Sorry for any confusion.

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

[Richard Stallman]

    > * 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'.

It would be just as unclean with flet.  I discourage use of flet.

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

[David Hansen]

On Sun, 02 Jan 2005 11:06:24 -0500 Richard Stallman wrote:

[multi-mode.el]

> It looks like a plausible approach,

In some cases one major mode needs more than the current chunk to
do proper indentation, e.g. in mixed HTML and C like code:

/* ... */
{
  for (i=0; i<N; ++i) {
%>
     <td><%= f(i) %></td>
<%
  }
%>

With multi-mode.el the last closing brace is indented to column 0
and not `c-basic-offset'.

David

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

[Richard Stallman]

    With multi-mode.el the last closing brace is indented to column 0
    and not `c-basic-offset'.

Can you see if it could be extended to handle this case right?

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

[David Hansen]

On Tue, 18 Jan 2005 06:05:08 -0500 Richard Stallman wrote:

>     With multi-mode.el the last closing brace is indented to column 0
>     and not `c-basic-offset'.
>
> Can you see if it could be extended to handle this case right?

I don't think there is an easy solution to handle such cases.
How far the major mode has to look back heavily depends on the
syntactic state of your code at point (and of course how the
major mode deals with it).

Worst case may be that all chunks from the beginning of the
buffer up to point are needed.  This is kind of inconsistent with
the `narrow-to-region' approach.

David

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

[Richard Stallman]

    I don't think there is an easy solution to handle such cases.
    How far the major mode has to look back heavily depends on the
    syntactic state of your code at point (and of course how the
    major mode deals with it).

That is sometimes true.  It means those indentation functions that are
used in multi-mode context would need to be modified to cope with the
presence of interpolated text of other kinds.  They could use the
multi-mode mechanism to find the previous block of text that is of the
same kind, and continue the scan there.

    Worst case may be that all chunks from the beginning of the
    buffer up to point are needed.

Sometimes that will happen.

				    This is kind of inconsistent with
    the `narrow-to-region' approach.

That's just an approach, not an absolute rule of using multi-mode.
So I think this is a real issue, but not a fatal problem.