Feature Request: Jump to definition

[sonthonaxrk]

It would be really useful if there was an option to jump to the definition of a class or function, as you can already do this in vim-jedi

[tweekmonster]

@rollokb I'll see how @zchee feels about adding other features provided by Jedi's API. My opinion is that I'd like to focus on asynchronous completions since the other features are already well tested in vim-jedi. You can use vim-jedi's other features in tandem with deoplete-jedi by disabling its completions:

let g:jedi#completions_enabled = 0

You may also find this useful for getting rid of the __doc__ buffer vim-jedi creates:

autocmd BufWinEnter '__doc__' setlocal bufhidden=delete

[zhou13]

What i hope is that we can have a unified interface for goto definition/ declaration and reflection just like completion rather than defining map for every lamguage manually. Integration with the completion plugins like deoplete looks good to me as it may about save computing resource.

[zchee]

@rollokb @tweekmonster @zhou13 I'm planning a remote plugin that specializes in GoTo. similar to deoplete.nvim.

I think desirable to that sources can be written in each language because seems to be difficult than the word completion. GoTo the plugin must know more AST information of the each language. e.g. In Go, gocode is almost provided the perfect completion, but guru sometimes can not GoTo (guru is despite being developed by the Golang core committer). In Python, jedi is almost provided the perfect completion, but GoTo is not perfect.

...Oh, Sorry. It's off topic.

anyway, deoplete.nvim is completion framework, also deoplete-jedi is completion source for python. vim-jedi is IDE for Python, but deoplete-jedi is not IDE. I think implementation of GoTo feature are overkill.

WDYT?

[zhou13]

Hi zchee, I am looking forward to your new project. It is not clear to me how a Goto source looks like. Do they just define several functions such as GotoDeclaration and GotoDefinition?

[zchee]

@zhou13 oh, sorry late reply. are you still interested?

[zchee]

and yes. like deogoto.nvim I want to, core code written in Python, but each sources can write each language. but it's concept is too difficult... make the goto for python plugin is easy(than that concept) also C because I known jedi and libclang API, but it's not scalable.

[zhou13]

Hi zchee, Yes, I am still interested. Providing an interface for "goto definition", "goto declaration", "find all reference", and maybe code refactoring could be nice. Could you elaborate what does "it's concept is too difficult" mean? Do you worry about how to extend the code jumping feature to other language where a decent parsing library does not exist? If so, I think that you don't need to be anxious about this since we can always use some coarse regex to get it work in 80% cases.

[zchee]

@zhou13 oh,

it's concept is too difficult

I mean, e.g. go to for Python code deogoto source is goto.py, for Rust is goto.rs, for Ruby is goto.rb.

Now, deoplete.nvim source are if target language does not provide python API, need subprocess module. e.g. deoplete-go, deoplete-termjs. https://github.com/zchee/deoplete-go/blob/master/rplugin/python3/deoplete/sources/deoplete_go.py#L193 https://github.com/carlitux/deoplete-ternjs/blob/master/rplugin/python3/deoplete/sources/ternjs.py#L100

So, I think If deogoto.nvim core using the subprocess to call the source, implementation is simple and that source can be written in each language.

and, deoplete is completion engine. It requires a very fast speed of operation because it's called each time when you type a character. So deoplete's sources can write only in python is good approach and makes sense.

But deogoto are only when a user runs the DeoGoto(example) command. It does not require the same operating speed as the deoplete.nvim. so deogoto.nvim's sources can write each language is better.

but implementation of that interface is too difficult. that's I said too difficult means. Did you understand?

Provide an interface for "goto definition", "goto declaration", "find all reference" and code refactoring

find all reference is show documents like pydoc? and code refactoring meaning of like rename any function name? If so, I think it's overkill. I'm planning goto definition only. because you said behavior is maybe possible, but deogoto code will be complexity.

Also, What difference of the definition and declaration? It's go to other files function and go to define a variable point in the current buffer? If so, it's operation depends on the writing of the source. I'm going to show multiple results if there is a need. like jedi's goto are using quickfix or location-list window.

Sorry long sentence!

[zchee]

since we can always use some coarse regex to get it work in 80% cases.

I make it because it is hate \o/ lol

[vext01]

Hi @zhou13, @Shougo.

I just wanted to register interest for this feature.

I've just switched from vim to neovim, and in doing so replaced jedi-vim with deoplete-jedi. I used jedi-vim solely for \d (jump to definition)! I have actually disabled completions, as they were too slow, although it looks like deoplete's a-synchronous calls have fixed this nicely.

[tarasmatsyk]

Add me to the list of interested users 👍

[viniarck]

I'm interested too. +1

[zchee]

@vext01 @tarasmatsyk @viniciusarcanjo OK, thanks for interested my project.

To be clear, I do not plan to implement GoTo in deoplete-jedi. Sorry.

---

BTW, My current state is below.

Now I am developing https://github.com/zchee/clang-server. That's for deoplete-clang completion server. But I planned also implements C/C++ GoTo or etc features. Also, that passing over the msgpack-rpc or gRPC(or support both protocols). After finished clang-server, I'll start to develop deogoto(now tentative name). That is similar deoplete plugin feature, but server/client architecture over the msgpack-rpc or gRPC(or support both protocols). So, maybe each languages sources can write native languages.

It implements might overlap the deoplete completion sources, but I want to write each GoTo source with native language.(like for python's GoTo written in Python, etc) So I(we) adopted that architecture.

Also recently, Microsoft's langserver protocol is also active. We should consider compatibility.

We still have a long way to go. but I will do my best. Please wait a moment, and looks forward it.

[blueyed]

FWIW: you can still use jedi-vim for this functionality in parallel.

[zchee]

@blueyed Oh, sorry, in other words? Or, this reply is not for me?

[blueyed]

@zchee Not directly for you: I just wanted to point out that jedi-vim and deoplete-jedi can be used in parallel: I am using the goto functionality from jedi-vim, too.

My jedi-vim settings (but might be missing something, my vimrc is a mess - pick what you need):

  let g:jedi#auto_vim_configuration = 0
  let g:jedi#goto_assignments_command = ''  " dynamically done for ft=python.
  let g:jedi#goto_definitions_command = ''  " dynamically done for ft=python.
  let g:jedi#use_tabs_not_buffers = 0  " current default is 1.
  let g:jedi#rename_command = '<Leader>gR'
  let g:jedi#usages_command = '<Leader>gu'
  let g:jedi#completions_enabled = 0
  let g:jedi#smart_auto_mappings = 1

  " Unite/ref and pydoc are more useful.
  let g:jedi#documentation_command = '<Leader>_K'
  let g:jedi#auto_close_doc = 1

[viniarck]

Ok @zchee. @blueyed thanks for letting me know. Awesome!

[zhou13]

@zchee Maybe this is not a correct place to ask but I find your clang-server very interesting. For some complex C++ source (e.g. #include <boost/xxx.hpp>), it may took several seconds to get the popup. Could clang-server dramatically improve the performance of completion in deoplete-clang in these cases?

[sangaline]

I'm trying to use jedi-vim and deoplete-jedi in parallel as @blueyed describes, but the documentation command always gives me an error like

No Python documentation found for 'whatever_thing'.                                                               
Use help() to get the interactive help utility.                                                                        
Use help(str) for help on the str class. 

even though the scratch window that pops up from deoplete-jedi can find the documentation successfully. Is there a way to bind that to a command so that it can be opened manually?

[manyids2]

I have the same behaviour as @sangaline. It doesn't look for (a)>> pydoc lib.module.method , but instead just (b)>> pydoc 'method' where (a) returns the proper documentation from the terminal

[Shougo]

I think it should be implemented by LSP plugin side. It is not deoplete source work.