shawncplus / phpcomplete.vim

Improved PHP omnicompletion
http://www.vim.org/scripts/script.php?script_id=3171
595 stars 110 forks source link

Multiple inheritance is not completing correctly #54

Closed weierophinney closed 9 years ago

weierophinney commented 9 years ago

I'm giving phpcomplete.vim a try with my phly/http library. That library depends on psr/http-message, which defines the following interface hierarchy:

Inside phly/http, I define:

I followed the instructions in the wiki for compiling ctags (question: does ctags-exuberant 5.9 include that patch? If so, you might want to note that), and then generated tags inside the project root according to the directions in the wiki. This created a tags file in the root.

I then edited test/ResponseTest.php of the project, and tried autocompletion on a Response instance. What I observed is that only methods that were defined in ResponseInterface showed possible completions; none inside MessageInterface could be completed.

Looking at my tags file, I can clearly see the inheritance chain:

Response    src/Response.php    /^class Response implements ResponseInterface$/;"   c   namespace:Phly\Http inherits:ResponseInterface
ResponseInterface   vendor/psr/http-message/src/ResponseInterface.php   /^interface ResponseInterface extends MessageInterface$/;"  i   namespace:Psr\Http\Message  inherits:MessageInterface

Is phpcomplete.vim unable to follow inherited interfaces? or is there a different combination of ctags flags I need to use to ensure it follows inheritance correctly?

complex857 commented 9 years ago

I've grabbed your project and took a look, it seems to me that the implemented interfaces are simply not considered (along with traits) when generating the completion options at this moment.

So what seems to happen is that it recognizes that it needs to complete for the class Phly\Http\Response then it checks for a parent class (something after an extends and find nothing, so returns the stuff found in the Response class itself, leaving out everything that could come from any implemented interface down the line. Now if your class (or one of it's parent class) does actually implements the things listed in the implemented interfaces then this would not matter but because you implement these with a trait - which is also unsupported at this moment - you end up with results you described.

So this is a missing feature and needs some work done before the plugin can handle it correctly.

complex857 commented 9 years ago

Oh, as for the question regarding ctags: I'm not sure when or if the next offical ctags will happen but, word is that the code accumulated in fishman's fork will be the core of the new release.

That repo already contains most of the patch I've included with the plugin (expect the docblock collecting) so I would say that it got good chances getting in.

complex857 commented 9 years ago

I've took a stab at implementing basic support for traits. As far as i can tell, the example should be working with the new master version now.

With that said, more work will be required to improve the completion answers in the context of the use keyword, because as it stands now the plugin can't tell if you are importing things in from a namespace or you are extending a class with a trait, and in the latter case you are not interested in classes and interfaces (which are now offered as completion).

Thanks for your nicely detailed example and for reminding me that traits are a thing now (i don't get to use them in my day-to-day work so i have forgotten about them).