Wrong highlighting with numeric entity in HTML

[flack]

If I have a line like this:

<?php echo "XXX"; ?><span>&#187;</span><?php echo 'XXX'; ?>

php-mode treats the # as a PHP comment and highlights the rest of the line in red. So it seems that it doesn't know that it's not in a PHP block

[ejmr]

Thanks for the bug report. It is true, php-mode has a poor understanding of anything outside of the <?php ... ?> tags. I have some concern about fixing each individual bug like this (and there are others) because I worry that they will build up into a collection of hacks, probably written around fragile regular expressions prone to breaking. I would like to avoid that and take a more comprehensive approach to making php-mode smarter about content beyond ?>, but I also have to admit that is not a change that will happen quickly.

Thanks again for the bug report because it will be a great test case to use. But realistically, and unfortunately, this probably will not be fixed soon because I have been unable to decide how I want to tackle these related problems. So that is my problem as the maintainer for holding up this area of php-mode as I brainstorm.

In the mean time I have heard great feedback from people using web-mode.el to handle content outside of PHP tags, so that hopefully that will be useful to you as well.

[flack]

No problem, there's no hurry. Fortunately, I don't stumble across this kind of code often, so it's no biggie anyways :)

I've looked into Emacs syntax highlighting capabilities myself a little, but they seem to be rather limited, from what I've seen at least. I was trying to come up with a patch for another problem that's a bit more frequent than this one: Constants are matched case-insensitively, so php-mode thinks that dir is the equivalent of DIR, while PHP will only recognize the all-caps version.

Do you think this could be fixed? If so, I would create another ticket for it, otherwise, I'll try to learn to live with it...

[ejmr]

No problem, there's no hurry. Fortunately, I don't stumble across this kind of code often, so it's no biggie anyways :)

That's good to hear. :)

Although the entire issue in general is still something I want to deal with in the near future.

I've looked into Emacs syntax highlighting capabilities myself a little, but they seem to be rather limited, from what I've seen at least.

Personally I think Emacs has a lot of capability when it comes to syntax highlighting, but it's methods are not the most intuitive. In php-mode you'll see we use regular expressions a lot. That works well for a lot of situations, but inevitably there is syntax where we either have to write something awful like "\\<\\(use\\)\\s-+\\(\\(?:\\sw\\|\\\\\\)+\\)\\s-+\\(as\\)\\s-+\\(\\(?:\\sw\\|\\\\\\)+\\)" or we have to drop 'simple' regular expressions altogether to take a logically more complex approach, e.g. the php-annotations-* code.

You can highlight a lot of syntax using regular expressions with font-lock, regexp-opt is a great help with that, for example. If you need to do something more complex then Emacs can do it, but it very quickly becomes cumbersome. In my opinion anyways.

Constants are matched case-insensitively, so php-mode thinks that dir is the equivalent of DIR, while PHP will only recognize the all-caps version.

Do you think this could be fixed? If so, I would create another ticket for it...

Yes, that can and should be fixed. Honestly I thought __dir__ was fine in PHP; the versions I have installed accept it in place of __DIR__. But there are other constants that php-mode incorrectly highlights such as directory_separator instead of only DIRECTORY_SEPARATOR.

[flack]

Hm, now that you mention it, __dir__ is indeed valid according to PHP documentation, in fact, all "magic constants" (i.e. the ones starting with two underscores) are, but all the rest, like PHP_VERSION, is case-sensitive, as are superglobals ($_SERVER, $_POST etc.). I'll summarize this is a new ticket