From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Michael Shulman" Newsgroups: gmane.emacs.devel Subject: PHP mode and mmm-mode Date: Mon, 1 May 2006 23:24:41 -0500 Message-ID: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1146543906 9006 80.91.229.2 (2 May 2006 04:25:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 2 May 2006 04:25:06 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 02 06:25:04 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FamRZ-0004BM-Jq for ged-emacs-devel@m.gmane.org; Tue, 02 May 2006 06:25:02 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FamRZ-0002l6-2m for ged-emacs-devel@m.gmane.org; Tue, 02 May 2006 00:25:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FamRM-0002l0-W7 for emacs-devel@gnu.org; Tue, 02 May 2006 00:24:49 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FamRH-0002jN-F9 for emacs-devel@gnu.org; Tue, 02 May 2006 00:24:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FamRH-0002jG-7U for emacs-devel@gnu.org; Tue, 02 May 2006 00:24:43 -0400 Original-Received: from [64.233.162.200] (helo=nz-out-0102.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FamRL-0002pX-NP for emacs-devel@gnu.org; Tue, 02 May 2006 00:24:48 -0400 Original-Received: by nz-out-0102.google.com with SMTP id q3so891963nzb for ; Mon, 01 May 2006 21:24:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=se1koFNg3YOu6q/wZqLo3FyokxYUCiIiJYyGzvFuTCdBnHTWNHRUAndFitNKMKh2HHDdlw7y0uJxXV4ue09/dAyPhObN07eVo8Pfxu3w0YLUochePRA2YmNDSwJjxycp6KLEiszfGd41tuI1qpofpNG3WygoouH7YEhaFqepjMc= Original-Received: by 10.36.67.16 with SMTP id p16mr177372nza; Mon, 01 May 2006 21:24:41 -0700 (PDT) Original-Received: by 10.36.58.6 with HTTP; Mon, 1 May 2006 21:24:41 -0700 (PDT) Original-To: "Lennart Borgman" Content-Disposition: inline X-Google-Sender-Auth: 928f4616c3661bf8 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: news.gmane.org gmane.emacs.devel:53761 Archived-At: (I don't normally read this list, but Lennart kindly alerted me to this thr= ead.) 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 wrote: > Lars Magne Ingebrigtsen wrote: > > Richard Stallman 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. >