Using ede-php-autoload with PHP-mode
metaturso opened this issue · 14 comments
ede-php-autoload is a fantastic package that enables Emacs to understand the dependencies of PHP projects, the most immediate benefit of this is that Emacs can translate class names into files, for example allowing you to jump to the definition of a third-party package with the flick of a button.
The package provides PSR-0 and PSR-4 autoload capabilities to the SemanticDB Emacs subsystem and it can be either used as part of the Semantic parsing system, or with some customisation as a standalone package that doesn't require semantic-mode to be active on your php buffers.
Since ede-php-autoload is by nature designed to work in conjunction with semantic PHP parsers, here's a couple of implementations that's worth knowing about:
- @jorissteyn's EDEP package is being updated to work in tandem with
ede-php-autoload. - @stevenremot has originally written
ede-php-autoloadas part of his work to update the CEDET contrib PHP parser to suit the updated PHP syntax, so it's inherently designed to work with it. Here's a version of the CEDET Contrib PHP parser that works withede-php-autoloadand the built-in CEDET version shipped with Emacs 24 and 25.
I personally am using ede-php-autoload without semantic-mode so I've hacked a function that uses it to jump to the declaration of a class imported with use.
(defun ofc/tags-find-at-point ()
"Finds the definitions of the symbol at point using a tag file."
(interactive)
(xref-find-definitions (thing-at-point 'sexp)))
(defun ofc/visit-class-file-at-point ()
"Maps a FQN into a file name using PHP autoload resolution."
(interactive)
(let* ((class-name (replace-regexp-in-string "^\\\\" "" (thing-at-point 'sexp)))
(class-file (ede-php-autoload-find-class-def-file (ede-current-project) class-name)))
(when class-file
(xref-push-marker-stack)
(find-file class-file))))
(defun ofc/php-tags-find-at-point ()
"When called on a FQN, it resolves its name and jumps to the file where it's defined.
When called on anything else it forwards the call to a tag search function."
(interactive)
(unless (ofc/visit-class-file-at-point)
(ofc/tags-find-at-point)))
(global-ede-mode 1)
(add-hook 'php-mode-hook #'ede-php-autoload-mode)
(define-key php-mode-map (kbd "M-.") 'ofc/php-tags-find-at-point)I would be interested in knowing how @jorissteyn and @stevenremot are using it.
Hi Andrea,
ede-php-autoload is indeed fantastic :). I like the way you're using it, clean and simple. But what does xref-find-definitions do? How can that work for PHP? If I remember correctly it's somewhat like symref but better? Can't find it on (M)ELPA for emacs 24.
@jorissteyn's EDEP package is being updated to work in tandem with ede-php-autoload.
Yes and no. I'm actually working on splitting the phptags semanticdb and symref backends from EDEP as well as create a separate repository for semantic-php (which is now embedded in EDEP), making EDEP obsolete.
I did make an experimental branch in the EDEP repository to see how we can combine ede-php-autoload with the phptags backends. I just pushed it but there's no benefit in getting it up and running yourself. I won't be using it either, but it's a good lesson to use in semantic-php.
I would be interested in knowing how @jorissteyn and @stevenremot are using it.
I'm not using it in any workflow at the moment, but did try it out like you did in Stevens CEDET fork. I also (succesfully) tried replacing phptags with ede-php-autoload in EDEP master, before I created the experimental branch I mentioned. I keep getting better at creating half-broken haphazard implementations :)
What I do use when I use Emacs but not develop for Emacs, is the master branch of EDEP to browse repositories. That works great with the phptags backend because it doesn't care about project structure. The control-click (ia-fast-jump) behaviour together with helm completion on all project functions or classes is very helpful too. I cannot do that with the other wisent-phps. The downside is completion in the master branch is completely broken (well, not implemented), I didn't try but in a limited way that might work better in Stevens fork. In the clean-analyze-context branch of edep this works a lot better, but it has so many rough edges I don't think it's useful for anyone.
Hi,
ede-php-autoload is always enabled at my work. I get auto-completion and accurate jump to definition on the part of my work's project that uses PSR-0 style with underscores, but this is not that good on PSR-4 namespaces, mainly because of my poor implementation of namespaces and use statements in my CEDET fork.
I'm happy you can find interesting ways to use ede-php-autoload @trashofmasters , actually I did not expect it!
@stevenremot the codebases I work with can really take a toll on both EDEP and wisent-php parsers and make my Emacs experience almost unbearable. But I really enjoyed class-sensitive autocompletion when using your enhanced wisent-php grammar.
I really like ede-php-autoload as it's now enabled me to jump to most of my imported classes.
Oddly enough I still can't get it to work consistently all classes, for example I still can't resolve the PHP_Unit_Framework_TestCase class definition file, go figure.
This is how it looks w/o semantic-mode and with the functions I shown in my previous comment:
A minor but very effective improvement would be using looking-at to move one characted backwards before getting the sexp at point, or avoiding doing the search when it's empty.
@jorissteyn AFAIK find-tag has been deprecated in Emacs 25 in favour of the more generalised cross referencing system xref as a frontend to etags
The tags are generated with the good enough version of Exuberant Ctags for PHP 5.4.
In particular the function xref-find-definitions immediately jumps to a candidate or shows a buffer *xref* with a list of possible selection grouped by path. I didn't get xref-find-references to work yet tho.
And here's the (still quite confusing) *xref* candidate selection buffer, I wonder if helm doesn't have a candidate display function for it...
ede-php-autoload is indeed fantastic :). I like the way you're using it, clean and simple.
@jorissteyn ahaha thanks!
Truth to be told is that I'm to dumb to actually understand how to use it correctly. Even after spending the entire afternoon chatting to Steven about using the thing! So I had to hack something away as not to waste his time :)
@ejmr @jorissteyn @trashofmasters @stevenremot
Guys, how about to create github organization? To collect all related things in one place. Something like «EmacsPHP».
BTW, thank you all for emacs and php related work.
@vyazovoi I'm in favor of creating and joining such a GitHub organization if everyone else thinks it would be useful.
+1. While I don't think we do formally need an organisation, this would certainly help us centralise all of our efforts and code, as well as keep us from using the bug-tracker as a discussion board/wiki.
Recently I was searching for all efforts to support PHP in Emacs, and it was not easy. Therefore I propose to gather them in one place.
I don't see how migrating the repositories (lets say php-mode, semantic-php and ede-php-) to a group-owned github account will help. We'd still have to discuss topics in the issue trackers of repositories right? Or is there more to a github organisation?
What if we create an "emacs-php" mailing list on google? That would make it easier to keep track the different development efforts. And keep the noise out of the issue trackers.
@jorissteyn I see where you are coming from. I think the suggestion was to move just php-mode contributions for Semantic php to a organisation, not actually change ownership of php-mode from Eric to an hypothetical EmacsPHP org.
Besides team access to repositories I don't know if organisations offer much over a individual account.
The only benefit I can think of would be the greater degree of freedom in terms of creating or changing wiki articles when required and provided we actually need to write any article.
To conclude, the organisation can definitely wait, but a mailing list would surely be more useful to keep the noise down here.
To conclude, the organisation can definitely wait, but a mailing list would surely be more useful to keep the noise down here.
I agree with both you and @jorissteyn re. the usefulness of a mailing list. Personally I'd also like to put such a list on http://gmane.org/
Good idea. I created a mailing list called "emacs-php" on google groups:
And it should be up on http://dir.gmane.org/gmane.emacs.php once that is approved.
Spread the word! :)
@jorissteyn Thanks!
I've also added the mailing list links to the README so that hopefully more people will see them. And tweeted about it as well to spread the word.