How can I identify PHP unused variables (in Emacs)?

Is it somehow possible to identify unused variables in a PHP file in Emacs?

With other languages, this is possible by using tools such as Flymake.

I've already enabled Flymake to show syntax errors for my PHP files on the fly, but still it's frustrating that PHP logic errors are sometimes due to situations like:

<?php
    $foo = whatever();
    $bar = something($fo);
    ...

Note the typo on $foo that will contribute to the developer's headache and to his/her exorbitant use of coffee.

After the hints by Pascal and viam0Zah, I set this in my php.ini file:

error_reporting = E_ALL | E_STRICT

When I run php from the command line, I'm now able to see the notice about the undefined variable (with or without the -l option):

php -r '$foo = 3; echo $fo;'

PHP Notice:  Undefined variable: fo in Command line code on line 1

php -r '$foo = 3; echo $fo;' -l

PHP Notice:  Undefined variable: fo in Command line code on line 1

This is what I'm currently using in my .emacs file. It works perfectly fine with parse errors, but I'm still not able to match on the notices, though :(

;; Flymake for PHP
(require 'flymake)

    (defun flymake-php-init ()
      "Use php to check the syntax of the current file."
      (let* ((temp (flymake-init-create-temp-buffer-copy 'flymake-create-temp-inplace))
          (local (file-relative-name temp (file-name-directory buffer-file-name))))
        (list "php" (list "-f" local "-l"))))

    (add-to-list 'flymake-err-line-patterns
                 '("\\(Parse\\|Fatal\\) error: +\\(.*?\\) in \\(.*?\\) on line \\([0-9]+\\)$" 3 4 nil 2))

    (add-to-list 'flymake-err-line-patterns
                   '("Notice: \\(.*\\) in \\(.*\\) on line \\([0-9]+\\)" 2 3 nil 1))

    (add-to-list 'flymake-allowed-file-name-masks '("\\.php$" flymake-php-init))

I've also tried Gabor's configuration, but with the same result. It is fine with errors, but bad with notices.

Please note that from the command line, parse errors look like:

php -r '$fo o = 3; echo $fo;' -l

PHP Parse error:  syntax error, unexpected T_STRING in Command line code on line 1

I don't get why Notices are not matched. I've tried the regular expression separately and it seems to match correctly:

(search-forward-regexp "Notice: \\(.*\\) in \\(.*\\) on line \\([0-9]+\\)")

PHP Notice:  Undefined variable: fo in Command line code on line 1

(C-x C-e will jump to the end of the lines).

Finally, I disabled Xdebug for now, since the notices were originally reported as:

PHP Notice:  Undefined variable: fo in Command line code on line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0

So, I guess I should slightly change the regexp to match the multiline errors. Any hint about this?

Since Flymake uses the php binary's syntax check option (-l) for highlighting parse errors, there is no obvious way to catch notices and other errors without running or lexical parsing the code. If it's not a problem to not only lint but execute your script, then you can do the following.

Unfortunately, flymake-php defines error line patterns as constant (at least in the bundle shipped with Emacs Starter Kit), and even the flymake command is hard-coded. There is a few ways to achieve our goal and each is a pain. May be it's a quick and not so dirty solution to define our flymake-php-init function based on the original one.

(defun my-flymake-php-init ()
  ;; add a new error pattern to catch notices
  (add-to-list 'flymake-err-line-patterns
               '("\\(Notice\\): \\(.*\\) in \\(.*\\) on line \\([0-9]+\\)"
                 3 4 nil 2))
  (let* ((temp-file (flymake-init-create-temp-buffer-copy
                     'flymake-create-temp-inplace))
         (local-file  (file-relative-name
                       temp-file
                       (file-name-directory buffer-file-name))))
    ;; here we removed the "-l" switch
    (list "php" (list "-f" local-file))))

Then customize flymake-allowed-php-file-name-masks to use my-flymake-php-init function for initializing flymake-php instead of the original one. And so it works:

_{(source: flickr.com)}