PHP mode and mmm-mode

["Michael Shulman" <shulman@math.uchicago.edu>]

(I don't normally read this list, but Lennart kindly alerted me to this thread.)

To preface this with a disclaimer: it's been some years since I wrote
the first version of mmm-mode (which was itself based, at least
conceptually, on an earlier and much smaller package called mmm.el by
Gongquan Chen).  Since then I've become busy with other things and
mostly neglected it, so I'm not entirely on top of how things stand
now.  I should also add a disclaimer that I don't have a huge amount
of programming experience, so it's quite possible that my thoughts and
impressions are very wrong.  However, here are my two cents anyway;
feel free to ignore them or tell me what's wrong with them.

mmm-mode is a hack.  Actually, a collection of many hacks.  That it
more or less works, much of the time, is, I believe, a testament to
the flexibility and extensibility of Emacs.  However, it has many
flaws, and there are certain situations that I've never been able to
make it handle smoothly, so I would not really suggest including it in
Emacs.  For example, in certain modes (which I don't remember off the
top of my head) indentation in submode regions is broken, while in
others, quotation marks in one place can adversely affect the
font-locking somewhere where they really shouldn't.

It's quite possible that someone with a better understanding of the
internals of Emacs' syntax-parsing and font-lock systems could make
mmm-mode do a better job.  However, my current feeling is that a
different approach entirely might produce better results.

I came to believe while working on mmm-mode that in an ideal world,
the major-mode architecture would be designed to support being told to
manage only parts of a buffer.  Then when a mode is specifying its
syntax, it could specify that certain delimiters are to be used to
block off chunks of a buffer and hand them off to some other mode to
be processed.  Flags could specify whether these chunks should be
considered as sections of the same file, or unrelated code snippets,
or more generally which should be which.  Then the syntax-parsing,
indentation, and font-lock code would automatically hand those chunks
off to the other mode, which would parse them all together as required
and treat all the text in between, which it isn't handling, as a
string, or ignore it entirely, depending.  Moreover, that sub-mode
could in turn specify nested submodes, and the whole thing would Just
Work.

Then one could design, say a php-mode which would hand parts of the
buffer off to, respectively, an html-mode, xml-mode, or whatever
(depending perhaps on the beginning of the file, a local variable, or
on the file name), and a php-code-mode (or it might handle the code
itself).  The html-mode could then in turn be designed to hand chunks
of its section of the file off to javascript-mode or css-mode.  And so
on.  There are all sorts of templating tools in common use today (e.g.
ASP, JSP, Mason, Zope, etc.) which intersperse various kinds of code
with various kinds of text, so I feel that a general system for
combining major modes, like mmm-mode but more reliable, would be
significantly better and more useful than just "a PHP mode."

Now, a rewrite of all the major modes to support a design change like
this seems quite unlikely; certainly in the near future.  But it's
possible that such a system might be implemented "on top of" the
existing system, the way mmm-mode is, but in a different way.  For
instance, mmm-mode uses overlays to keep track of which text should be
in which mode.  This is fine as far as it goes, but it makes it hard
to completely conceal extraneous parts of the buffer from modes that
should not be paying attention to them, producing the above-mentioned
problems with font-lock and indentation.  Perhaps an approach based on
narrowing, or the creation of auxiliary buffers, might work better; I
haven't really explored these possibilities.  I would be interested to
hear if others have.

Michael

On 5/1/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
> Lars Magne Ingebrigtsen wrote:
> > Richard Stallman <rms@gnu.org> writes:
> >
> >
> >> I do not know PHP.  All I can say is that I would welcome addition of
> >> a good PHP mode.
> >>
> >
> > Has the inclusion of mmm-mode (written by Michael Shulman and others)
> > been discussed previously?  It looks like the approach taken to this
> > problem (multi-mode programming languages) is promising.
> >
> I do not know whether it has been discussed, but it seems to me there
> are currently unfortunately problems with this approach. I believe a
> number of things have to be addressed in Emacs before something like
> mm-mode can work for all modes. But I am not sure, it is quite complex.
> Below are however my thoughts about it.
>
> I think the idea of having different modes in different regions in a
> buffer is very good. So I tried it with nxml-mode (actually
> nxhtml-mode), but without any real success. Dean Scarff says he had some
> success, but still problems with that nxml-mode re-fontifies region that
> has another submode (see
> http://www.emacswiki.org/cgi-bin/wiki/NxmlModeForXHTML). This is also
> what I found.
>
> I can really see no way to stop different modes from stomping at each
> other with mmm-mode. And I can not see that it is possible to do that
> with Emacs (even the CVS version) today. To do that there must be some
> way to tell a mode only to care about a region or a list of regions and
> I can not see how to do that now. (Maybe some more things are required,
> but this is a minimum.)
>
> For the moment I would therefore suggest either html-script.el or
> html-inlined.el. They use narrowing and changes the buffers major mode
> temporarily during narrowing.
>
> For the future I would sugges investigating ways to do what mm-mode
> tries to do.
>