Automatically handle PHP

[mcandre]

The Emacs Wiki shows a working snippet for configuring mmm-mode for PHP code. Could we incorporate this into the default behavior for mmm-mode? As a PHP coder, it would be nice to have PHP working out of the box.

http://www.emacswiki.org/emacs/HtmlModeDeluxe

[dgutov]

There are classes for PHP in mmm-sample: html-php-output and html-php-code. Are they not good enough?

[mcandre]

@dgutov Those sample classes look good. Could mmm-mode turn them on by default?

[dgutov]

But, erm, it doesn't do that for any classes and languages. The README tells the user to put a call to `mmm-add-mode-ext-class' (or several) into their init file.

Should PHP be different?

[mcandre]

@dgutov I suppose not. That's a decent way for mmm-mode to behave, it's just... sometimes it seems like endless configuration before Emacs can sensibly edit some code.

[dgutov]

I hear you. I think not enabling any classes by default is a good thing (no possible conflicts with classes defined by the user), but I guess we could provide a new feature called, for instance, mmm-defaults that would include full setup for the most popular templating languages. The user would still have to require it, though.

[mcandre]

Now you've whet my appetite. mmm-defaults would be great. I don't know if there's a practical limit to what could be shoved in there, but my wishlist is:

• php
• css
• js
• erb
• ejs

[dgutov]

Ok, I'll take a look at that.

[dgutov]

@mcandre Do you think the new file should include this bit from mmm-erb?

 (setq mmm-submode-decoration-level 2
       mmm-parse-when-idle t)

[dgutov]

And a couple questions on your config.

• What's this embedded-css class? Does it work?
• Don't you think we should only enable mmm-mode for .html.php files, not all .php files?

[mcandre]

@dgutov I think we should enable mmm-mode for all .php files. A lot of regular .php code also outputs HTML.

[purcell]

I think it would be incorrect to assume that the chunks between PHP blocks in a .php file are HTML. I've seen plenty of PHP files which generate other content types.

[mcandre]

@purcell Fair point!

What if mmm assumed that .php blocks were HTML, unless specified in the file extension prefix (.html.php, .json.php, ...)?

[dgutov]

Sounds fine to me. I've seen the same with ERB and Sinatra template file naming convention (example).

Updated.

[dgutov]

As I see it, the main problem left is that php-mode also adds an auto-mode-alist entry in its autoloads (and in the package file itself), for "\\.php[s345t]?\\'".

Either someone has to persuade @ejmr not to do that, or the users will need to be careful about which file is loaded last.

[ejmr]

This issue came up almost a year ago:

emacs-php/php-mode#32

For a few months I've had it on my todo list to do something like make PHP Mode check auto-mode-alist first for any existing associations instead of overwritting them. But personally the problem doesn't affect me and chat about it died down quickly, and so I naturally and unfortunately let the issue fall off my radar. Now that the issue has resurfaced I am thinking what would be the best way to handle the situation where an existing mode has already staked a claim on *.php files. I'm not sure what would be the best course of action for PHP Mode, but i've long been pursuaed that it's a conflict that needs to be resolved.

[dgutov]

I guess the hard way to fix that would be along the lines of skeeto/skewer-mode#22.

The easy way: just passing t as third argument to add-to-list (append) in php-mode.el should do it. Then any user customization (usually performed as prepend) will prevail.

[purcell]

+1 for @dgutov's suggestion. No point doing anything more involved.

[ejmr]

I will modify add-to-list accordingly in the next day or two at the very latest.

[ejmr]

Hope this helps: emacs-php/php-mode@2d0c722

[dgutov]

@ejmr Works fine for me, thanks!

[dgutov]

I believe this is fixed now.