Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 19 2018 22:20
    ProfessorChill closed #115
  • Sep 13 2018 13:00
    Mte90 closed #113
  • Sep 13 2018 12:59
    Mte90 commented #113
  • Sep 13 2018 12:49
    Mte90 commented #115
  • Sep 13 2018 12:47
    Mte90 commented #113
  • Jun 06 2018 12:05
    deevus edited #116
  • Jun 06 2018 12:04
    deevus opened #116
  • Apr 10 2018 16:51
    halftan commented #115
  • Apr 10 2018 16:48
    halftan commented #115
  • Apr 10 2018 16:35
    ProfessorChill opened #115
  • Feb 19 2018 19:01
    mkusher commented #114
  • Feb 19 2018 18:36
    Mte90 commented #113
  • Feb 19 2018 18:35
    Mte90 commented #114
  • Feb 19 2018 18:34
    Mte90 opened #114
  • Jan 24 2018 11:55
    Mte90 commented #113
  • Jan 23 2018 21:44
    Mte90 commented #113
  • Jan 23 2018 19:49
    mkusher commented #113
  • Jan 23 2018 10:03
    Mte90 commented #113
  • Jan 23 2018 09:24
    mkusher commented #113
  • Jan 22 2018 18:23
    Mte90 commented #113
Aleh Kashnikau
@mkusher
good thing about NodeTypeResolver is it covered with unit tests)
Jan Mollowitz
@phux
Hey. It's cool to have a roadmap, but let's prioritize the points and/or classify them in terms of usefulness. This will make sure we will work on the most important ones and everybody sees what's next. For me for example the support for @mixin annotations has 0 value - due to the projects I am working on. Support for symbol information queries is IMO super important for basically everybody (go to definition, go to implementing classes).
Andy Zhang
@halftan
@phux can't agree more with that. The roadmap in wiki page is basically a detailed version of that in README.md without proper ordering, so it may be some kinda misleading. I've updated it by ordering in -IMPOV- priority.
Jan Mollowitz
@phux
Totally agree with the first points of the list.
So my next question is: did anybody here already start with the first point (Go to definition)? Is there some advice how to approach it? I did not look at the codebase in depth, so I would be thankful for any input/opinions.
Jan Mollowitz
@phux
Also there things in progress not appearing on the list like class name completion, padawan-php/padawan.php#82 which would provide nice value -> more users -> more contribution. These should be also prioritized, as effort has already been made.
Andy Zhang
@halftan
@phux you can take a look at the data structure of InMemoryIndex which contains all information needed to implement this feature.
I won't get my hands on it in the near future since I use phptag and Fzf to do this kind of job. It's also my recommended way
Andy Zhang
@halftan
of "go to definition" , because deoplete doesn't provide a unified interface like YCM.
If we implement this in pasawan
If we implement this in padawan, we have to implement the client side feature from scratch , which may lead to a lot of trivia
trivial codes.
Jan Mollowitz
@phux

@halftan thanks, InMemoryIndex is a perfect starting point for what I want.
By phptag & fzf you meant phpctags, right? If yes, it's not similar to what I mean, because you don't get context aware suggestions (only display tags for this or a parent class for example). If you've made this working with fzf, please share :)
I don't get your reference to deoplete. What I am thinking of is something like a php navigator. Like go to definition which works with inheritance, if the current class does not implement the method under cursor. Or goes to the corresponding class/interface if you are over a property. Or something like get implementations -> all classes which implement the current class/interface.

Maybe I am underestimating the effort, but for me it's just exposing the InMemoryIndex with a little logic added. Hacking together a simple plugin for vim which populates an implementation quickfix list or simply opens the returned definiton location should not be too complicated. Anyway, I'll give it a shot :)

Andy Zhang
@halftan
@phux yes, you are right. Phpctags doesn't give you semantic "go to definition", and there's no way to achieve this with out a sementic engine. It's not only about go to parent class or subclass list, but also means you need the ability to get the symbol type under cursor. Deoplete, the completion framework I'm currently using, only provides completion functions
Andy Zhang
@halftan
and exposes related API to underlying so called sources to language specific completion plugins. YCM, however, do expose GoToDefinition and GoToDeclaration API to language plugins, which makes it simple to write such functions, for you don't need to care about vim scripts like parsing server's response and pushing then into a quick fix list.
Andy Zhang
@halftan
Providing go to definition of parent class's method only is a good start. If you have questions, please feel free to ask.
Andy Zhang
@halftan
Ah, my bad english :(
I mean just focusing on finding method definition of the parent class will be a good choice.
Bother with complicated syntax analyzer mumbo jumbos is harder than I expected.
Jan Mollowitz
@phux
@halftan no problem, I understood what you mean :)
Please review and add whatever I might have missed: https://github.com/padawan-php/padawan.php/wiki/Proposal:-code-navigation-(WIP)
Note: I've written the api spec with vim in mind. No clue about sublime or other editors/IDEs.
Aleh Kashnikau
@mkusher
@halftan why do we need some support for go to definition/declaration in deoplete?
Andy Zhang
@halftan
YouCompleteMe and Language Server both have this feature support. I agree with the idea that the engine should provide this feature to users while expose an API to language sources. However deoplete's author said that he would not include this feature. So I guess we have to write a separate plugin to provide go to def/dec.
Jan Mollowitz
@phux
Maybe to clarify what I am proposing/actually doing:
  • alter Padawan to provide just an API for the features mentioned in the proposal
  • shamelessly stealing most parts of deoplete-padawan to provide a vim plugin wrapping padawans API and handling vim related stuff like rendering a buffer etc.
Jan Mollowitz
@phux
Current progress: implemented a poc of navigate to parent class/interfaces & list all implementing classes / interfaces of current class/file. Both features are available in neovim.
Neovim is a topic for itself as I have no experience with python or vimscript :)
Jan Mollowitz
@phux
My idea is to provide a standalone plugin for (neo)vim which only depends on a running Padawan server. Deoplete or whatever completion plugin should not be required for this functionality.
Paweł Bogut
@pbogut
You want that plugin to provide completion as well? We already have padawan.vim
Do you*
How about merging both plugins and make deoplete optional dependency? Then we could add "go to definition" and other stuff to that plugin.
Paweł Bogut
@pbogut
I honestly think that one plugin for padawan per editor should be enough, Instead of creating one for jumping, one for completion etc. Deoplete could be optional with fallback to omnifunc or something.
musou1500
@musou1500
@pbogut Does it means that merge deoplete-padawan and padawan.vim ?
Paweł Bogut
@pbogut
Maybe, thats just an idea. No sure what @mkusher thinks about it.
musou1500
@musou1500
I see...I 'm not familiar with vim. But I worry about compatibility aspect between vim/neovim.
Paweł Bogut
@pbogut
Well, some projects have already done this
for example ALE is working with vim and neovim
And it is using job / channels depends which one is available
Jan Mollowitz
@phux
@pbogut no i don't want to implement autocompletion, there is already deoplete-padawan which I am happy with.
I meant the navigation functionality should work although one decided not use deoplete-padawan or padawan.vim for completion.
While creating the neovim plugin I thought about the duplication of padawan.php related plugin code. A base plugin could be nice, for example "padawan-vim-connector". Deoplete-padawan, the navigation plugin and whatever could use that connector then to autostart a server/provide it's API.
But maybe this approach is too fine-grained, not sure.
Aleh Kashnikau
@mkusher
padawan.vim already provides omnifunc that can be used by users who don't want to use deoplete
maybe it's a good thing to merge padawan.vim and padawan-deoplete
Chitoku
@chitoku-k
@mkusher Hi, thank you for maintaining.
I made a pull request: padawan-php/padawan.php#108
Is the project still alive?
Aleh Kashnikau
@mkusher
@chitoku-k hi! thanks for the PR, saying honestly I don't have enough time now to work on padawan and also not sure about future, because there are few similar projects with more active development teams
Jan Mollowitz
@phux
@mkusher out of curiosity, what projects are you referring to? LSP?
Chitoku
@chitoku-k
@mkusher I think padawan.php has large extensibility and I am happy to implement some more features like listed in project description.
Aleh Kashnikau
@mkusher
@chitoku-k awesome PRs, I'm not active in gitter, but u can easily find me in telegram(@mkusher) or twitter. Also will try to check this chat more often :)
@phux I mean phan and phpstan, they do very similar things, but don't have completions right now. I haven't really tested LanguageServerProtocol for php, but it is good thing too