Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Built-in LSP Support #6856

Closed
wants to merge 63 commits into from
Closed

[RFC] Built-in LSP Support #6856

wants to merge 63 commits into from

Conversation

@tjdevries
Copy link
Contributor

@tjdevries tjdevries commented Jun 7, 2017

So, here's the very beginnings of LSP support in neovim.

It can currently, start a server, say that it has opened the file and request references from the server. It loads the references using setloclist.

Here's my vision (or at least a rough draft of it). It's too late for me right now to clean more of it up and I'm too excited not to finally at least put something as a WIP PR :)

Feedback welcome and appreciated.

Goals:

Registering callbacks

Should be something along the lines of

function lsp#request(request_name, arguments, use_default_callback, optional_callback)

as well as a lua function that has the same signature.

Where:

  • request_name
    • The name of the request that you want, i.e. 'textDocument/references'
    • This is specified in microsofts protocol.
  • arguments
    • If you want to hardcode in a value, pass in the values that you would like, the rest will be filled in with the default values
    • These default values would be grabbed programmatically, i.e. for Position, we would use line('.') and col('.')
    • This allows the functions to be tested or used outside of the LSP context
      • For example if you want to highlight all the references of something, but it's not the item under the cursor, you could pass in the location of that item to the function
  • use_default_callback
    • A boolean value to determine whether or not to use the default callback value
  • optional_callback
    • We will provide a default callback that will handle anything within the TUI
    • This will also use built-in neovim items (such as popupmnu, loclist, quickfix, etc.) so that if those are externalized by a GUI, they don't even have to do anything special.
    • Behavior could be to simply override the callback or to add it to a list of callbacks to call
      • Might want to use a list so that multiple hosts/clients of neovim could grab onto these events.
      • Probably don't want neovim to process the events though if the host/client override.
      • I'd just start with overriding to start with, since it is simple.

I imagine optional callbacks essentially allowing an even more extensive API, one that doesn't require Neovim explicit knowledge. So, to embed neovim in another editor, you could try and do lots of the information transfer with LSP callbacks.

From nvim
:call lsp#request('textDocument/references', [], v:false, custom_callback)

From remote
nvim.call_function('lsp#request', ['textDocument/references', [], false, custom_callback])

Creating default callbacks

function lsp#handle_response(request_name, response)
-> function lsp#response#textDocument.references(response)
-> function lsp#response#textDocument.hover(response)

Where:

  • response:
    • The response as specified by the protocol.
    • These should be made available so that people can use these as well to do more complicated tasks easily.
    • For example, could use the hover callback to create a simple hover pane that other hosts/clients/GUIs would understand.
@bfredl
Copy link
Member

@bfredl bfredl commented Jun 7, 2017

Nice! I hope to improve jobs/channels in lua #6844 (comment) to the extent this can just use them and don't need to use libuv directly.

@tjdevries
Copy link
Contributor Author

@tjdevries tjdevries commented Jun 7, 2017

@bfredl that sounds great! That would certainly ease some of the configuration for the client. I will try and watch out for that.

function! s:get_client() abort
if g:nvim_lsp_client == -1
lua << EOF
local client = require('runtime.lua.lsp.client')

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

This dedented block looks ugly, do not use <<EOF. Everything which does not fit into one line (lua require('lsp.client').get_client(), or, better, just return luaeval("require('lsp.client').get_client()") (move :if to lua to not split the logic)) should be in a required function.

Also should be require('lsp.client'), I do not know why #6789 still is not merged.

This comment has been minimized.

@tjdevries

tjdevries Jun 27, 2017
Author Contributor

Okay, I have removed many of them and rebased, so I can use the updates from #6789 . I will clean up the code as I go along. Still brainstorming a lot of ideas.


function! lsp#request#textdocument_references()
lua << EOF
print('TODO')

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

Same.

@@ -0,0 +1,383 @@
--
-- json.lua

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

Can you just use vim.api.nvim_call_function('json_…'? There already is a JSON parser in project, do not need to add a second one. If some features are missing they can be added.

This comment has been minimized.

@tjdevries

tjdevries Jun 7, 2017
Author Contributor

I didn't want to use the API to do it, since some of the json parsing might be done in a different thread I think. Unless it can work in another thread?

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

You are using luv to fork out different Neovim threads? I do not think this is a good idea, most of the code does not expect this and making sure that different shared resources (memory, file descriptors except for a small subset, etc) are not accessed through spawned threads is close to impossible. Generally: until there are Neovim own functions for creating threads or fork()ing don’t do this in core plugins, it risks producing nasty heizenbugs.


As to the question, though not exactly API, but JSON decoder could be easily edited to work with lua natively: most of code is parsing there, just need to abstract away creation of values (I would personally go with creating jsondecode.c.h macros-parametrized file for this purpose, should also be possible to do abstraction via struct with function references). Encoder is a separate issue, the “easy” way is to not touch it at all, but create duplicate lua -> VimL conversion functions which are exactly like existing ones, but do not put allocated lists and dictionaries into M&S GC double-linked list. In both cases you will spend more time creating the tests then adjusting the code.

This comment has been minimized.

@bfredl

bfredl Jun 8, 2017
Member

Luv won't spawn threads, but it can run callbacks at times which are not considered vimL-safe, though as long as GC won't be invoked in such a time (potentially, rooting might be incomplete), json_decode shouldn't be a problem.

This comment has been minimized.

@ZyX-I

ZyX-I Jun 8, 2017
Contributor

@bfredl Container allocation functions are not reentrant because they alter a linked list in a number of steps. So it is not safe to call callbacks at random times even without GC run (how, BTW? I do not know how uv is going to perform async read at unsafe time without either using SIGALARM (should probably mess up with our timers), or a separate thread, or a separate process), unless you edit C code of the parser to work with lua containers.

Why not use existing jobs in any case, this is going to be safe for sure? Just have a lambda which immediately calls lua.

This comment has been minimized.

@bfredl

bfredl Jun 8, 2017
Member

Not random times, just times the event loop is invoked. As previously this could be done in a way that queues all vimL until later, such spots could potentially be vimL GC unsafe. Can container allocation invoke GC or does that only happen at states?

The plan is indeed to improve jobs so they can be used here.


" TODO: Automatically open file if not opened already
function! LSP_References() abort
lua << EOF

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

lua lsp.client_references(), indented:

  1. Do not use ugly <<EOF blocks.
  2. All globals must be namespaced. This is not the only plugin using lua. I personally would prefer a single global per plugin or no globals at all (use lua require("…").func()).

This comment has been minimized.

@aktau

aktau Jun 20, 2017
Member

Just like on #6789, I would say that it is vastly preferable if we put some of these finer points in the help docs, where people are likely to find them.

endfunction

function! LSP_DidOpen() abort
lua << EOF

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

Same.

" TODO(tjdevries): Make sure this works correctly
" TODO(tjdevries): Figure out how to call a passed callback
function! LSP_Request(request, params, callback) abort
return luaeval('client_request(_A.request, _A.args)', {request: request, args: params})

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

Same (globals).

@@ -0,0 +1,28 @@
" TODO(tjdevries): Move this to autoload?

execute('luafile ' . expand('<sfile>:h') . '/../lua/lsp/plugin.lua')

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

Should be something like lua lsp = require('lsp.plugin').setup(). (Needs #6789 or you adding a path to package.path.)

@@ -0,0 +1,38 @@
local helpers = require('test.functional.helpers')(after_each)

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

I guess this should be test/functional/plugin/lsp/…: other runtime files are tested in plugin unless these are runtime files used from core in a special fashion (like providers which have corresponding C code). Applies to all test files here.

vim = vim or {}

util.echom = function(message)
vim.api.nvim_command('echom "' .. tostring(message) .. '"')

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

Just remove this function and use print(). And you have escaping issues here in any case.


function client:_on_error(level, err_message)
if type(level) ~= 'number' then
util.echom('we seem to have a not number' .. util.tostring(level))

This comment has been minimized.

@ZyX-I

ZyX-I Jun 7, 2017
Contributor

Message should start with a capital letter.


execute('luafile ' . expand('<sfile>:h') . '/../lua/lsp/plugin.lua')

function! LSP_Start() abort

This comment has been minimized.

@wsdjeg

wsdjeg Jun 8, 2017
Member

@tjdevries hi, I think maybe some people like autoload function more. for example

function! lsp#start() abort

and I have read most of vim's runtime file, the file in runtime/plugin/ do not definde func with capital letter.

This comment has been minimized.

@tjdevries

tjdevries Jun 27, 2017
Author Contributor

I have changed them to autoload. Thanks :)

@@ -0,0 +1,304 @@
local uv = require('luv')

This comment has been minimized.

@aktau

aktau Jun 20, 2017
Member

Is luv already included by default?

For me, inside of nvim:

:lua print(package.searchpath('luv', package.cpath))
/home/aktau/github/neovim/neovim/.deps/usr/lib/lua/5.1/luv.so
:lua print(package.cpath)
./?.so;/usr/local/lib/lua/5.1/?.so;/home/aktau/github/neovim/neovim/.deps/usr/lib/lua/5.1/?.so;/usr/local/lib/
lua/5.1/loadall.so

Or:

$ nvim -u NONE +'lua io.stderr:write(package.cpath)' +'lua os.exit()'
./?.so;/usr/local/lib/lua/5.1/?.so;/home/aktau/github/neovim/neovim/.deps/usr/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so%                                                                                                            

It appears my build folder is in my package.cpath, this is the default package path from the LuaJIT compiled into nvim, but it can be overridden if the user sets their own path. This should be made much more robust. It is also not guaranteed that a user has the neovim .deps folder on their machine. We should attempt to not rely on optional libraries (especially those that need to be compiled, like luv).

This comment has been minimized.

@tjdevries

tjdevries Jun 27, 2017
Author Contributor

I'm hoping to not have to use luv soon. Once we get the jobs update (which I assume will happen before I finish this :) ) then I will use nvim's included job functionality, rather than a hacked together interpretation.

@tjdevries tjdevries force-pushed the tjdevries:lsp branch from a7089f7 to 7ebadae Jun 27, 2017
@tjdevries
Copy link
Contributor Author

@tjdevries tjdevries commented Jun 27, 2017

@ZyX-I Is there a preferred way to get rid of the luacheck errors about referencing "global vim" without declaring it?

Should I just set local vim = vim or {}? Or change my luacheck config?

@justinmk
Copy link
Member

@justinmk justinmk commented Jun 28, 2017

Instead of callbacks why not publish RPC notifications?

@bfredl
Copy link
Member

@bfredl bfredl commented Jun 28, 2017

Then we need to be able to subscribe to them from vimL and Lua. Which we probably want anyway.

@ZyX-I
Copy link
Contributor

@ZyX-I ZyX-I commented Jun 28, 2017

@tjdevries Tell luacheck that there is global vim. CMakeLists.txt already does just that for vim.lua.

@tjdevries
Copy link
Contributor Author

@tjdevries tjdevries commented Jun 28, 2017

@justinmk I think RPC notifications would work as well. Originally I was thinking of callbacks because I thought GUIs/plugins/etc. might want to add their own callback or remove the default callback to extend behavior. But I think RPC would work well for that too.

I never got around to implementing an async rpcrequest though. So whenever I send an LSP request, it would block, correct? Or are you saying after a request message is sent back, do rpcnotify(0, 'lsp/textDocument/references', ...)?

@justinmk
Copy link
Member

@justinmk justinmk commented Jun 29, 2017

If the callbacks aren't needed then my suggestion is moot. My suggestion is only relevant under that assumption.

@euclio
Copy link
Contributor

@euclio euclio commented Aug 16, 2017

What's the status of this?

@tjdevries
Copy link
Contributor Author

@tjdevries tjdevries commented Aug 16, 2017

I'm waiting on a few PRs to get merged to ease development of this.

I'm also working on a few different projects right now, so I haven't had a lot of time to work on this. I would recommend using one of the other plugins that provides the functionality for now.

I'm still planning on finishing this though :)

@balta2ar
Copy link

@balta2ar balta2ar commented Aug 16, 2017

I'm waiting on a few PRs to get merged to ease development of this

For those who are curious, could you name them, please?

@tjdevries
Copy link
Contributor Author

@tjdevries tjdevries commented Aug 16, 2017

There's some work being planned for job_control to be added into Lua, being able to cancel stuck loops in lua, and perhaps more lua integration with the vim.api module.

Primarily the job_control items, since that could effect the structure of the support within neovim.

@justinmk justinmk added the lsp label Aug 22, 2017
@jvican
Copy link

@jvican jvican commented Sep 28, 2017

Could we set up a BountySource for this to motivate @tjdevries get this through the finish line? I would be happy to donate some money to have native LSP support in neovim.

@blueyed
Copy link
Member

@blueyed blueyed commented Sep 28, 2017

@tjdevries tjdevries force-pushed the tjdevries:lsp branch from f6c183e to 05ae150 Sep 29, 2017
@tjdevries
Copy link
Contributor Author

@tjdevries tjdevries commented Sep 29, 2017

Hi everyone 😄

Sorry for the long pause in dev, been working on some personal projects and practicing lua and lua within nvim.

@blueyed It currently compares to the language client as not as many features and its broken 😄. The idea however is that if this ships with neovim, people will be able to contribute more effectively, since it will be an "official" implementation. Also, it won't require any dependencies (so you won't have to install python and set up neovim-python) as the Lua will all run with whatever neovim ships with. I have lots of other ideas, but I should really finish the basic implementation first :)

I imagine there will still be other plugins around that integrate the core features built here to interact with other plugins. I can imagine sources for deoplete that use the builtin lsp#request(...) to get completion options. Maybe we will also implement some async api calls to interface with lsp as well. As I said, lots of ideas.

@jvican Not sure how that would work. If you're interested in using LSP in the mean-time, I would really recommend the implementation @blueyed linked. That way you could use most of the up-side of LSP and not have to spend money :)

@KillTheMule
Copy link
Contributor

@KillTheMule KillTheMule commented Dec 18, 2017

I'm currently using https://github.com/autozimu/LanguageClient-neovim with the RLS. If you're at a point where you'd want someone to test this, let me know :)

@tjdevries
Copy link
Contributor Author

@tjdevries tjdevries commented Dec 19, 2017

@KillTheMule I'll let you know :D Thanks for the offer.

@tjdevries tjdevries force-pushed the tjdevries:lsp branch 2 times, most recently from 88a04a0 to a950255 Dec 22, 2017
@Shougo
Copy link
Contributor

@Shougo Shougo commented Jan 23, 2019

Hi. The branch uses autoload/lsp.vim as for Vim script API.
But it conflicts with vim-lsp.

vim-lsp also uses autoload/lsp.vim.

@andreypopp
Copy link
Contributor

@andreypopp andreypopp commented Jan 23, 2019

Maybe neovim could only expose Lua API for LSP? Seeing how much effort is being put in user space to support LSP it would be unfair to discard it (and especially given that such effort has value both for vim and neovim users). That way neovim would provide backing API on which underlying user space implementations could rely when run on neovim.

@justinmk
Copy link
Member

@justinmk justinmk commented Jan 23, 2019

vim-lsp also uses autoload/lsp.vim

Maybe neovim could only expose Lua API for LSP?

Somewhere in the comment cloud above, we discussed minimizing and, ideally, eliminating the VimL wrapper for this, so lsp.vim definitely isn't a hard requirement. It can be renamed for now, and revisited later.

@mcepl
Copy link
Contributor

@mcepl mcepl commented Jan 23, 2019

Hi. The branch uses autoload/lsp.vim as for Vim script API.
But it conflicts with vim-lsp.

I understand, you were first, but if this gets built-in to Neovim, then I am afraid it should get a precedence, shouldn't it?

@bfredl
Copy link
Member

@bfredl bfredl commented Jan 23, 2019

@mcepl but as said above this will be trivially solved by renaming the file.

Alternatively, as I might already have said in the hidden 170 comments, we should change the init.vim definitions to be in the form let g:lsp_some_good_var_name = { server definitons }, so no autoload calls will be needed from vimL.

@mcepl
Copy link
Contributor

@mcepl mcepl commented Jan 23, 2019

@bfredl certainly, and it is not a big deal. Actually, eliminating autoload seems to me like a good idea.

@mcepl
Copy link
Contributor

@mcepl mcepl commented Feb 15, 2019

It is extremely easy to add support for renaming of symbols (thank you!):

function! LSPRename()
    let s:newName = input('Enter new name: ', expand('<cword>'))
    call lsp#request_async('textDocument/rename',
        \ {'newName': s:newName})
endfunction

au FileType lua,sh,c,python
    \ noremap <silent> <buffer> <F2> :call LSPRename()<CR>

but there is a bug somewhere. Whenever I run this command, I get one more EOL in the end of the file.

@Piping

This comment was marked as off-topic.

@KillTheMule
Copy link
Contributor

@KillTheMule KillTheMule commented Mar 2, 2019

@tjdevries I've made nvim into a fake languageserver and used it for a test here. I'm planing to extend this a bit, seems to be a good way to test this.

Generally, though, what's you're plan, do you think you'll find time to work on this? I offer my help, up to the point of bringing it over the finish line.

@Piping

This comment was marked as off-topic.

@mcepl

This comment has been hidden.

@Piping

This comment was marked as off-topic.

@tjdevries
Copy link
Contributor Author

@tjdevries tjdevries commented Mar 7, 2019

@KillTheMule I have my last day of work at my current company on Friday and then have a week off after that. If I don't make any progress during that week, it'd be great if you could take this PR to the finish line for me. I'd be happy to hop on gitter more often if you need to bounce ideas around or try and figure out what I was doing during parts of the PR.

Thanks for following up and offering your help.

@KillTheMule
Copy link
Contributor

@KillTheMule KillTheMule commented Mar 7, 2019

That's good to hear. Let me throw out some questions that occured to me during writing the integration test. Feel free to discard any of my thoughts, but I think I should at least mention them :) Talking on gitter would be fine, too :)

  1. Right now, you're sending Notifications as Requests. The spec has them different, in that at Notification does not have an id field, and needs no response. Are you planning to make a difference here? That would also make my life easier for the integration test :D From reports, things seem to be working, so servers don't seem to mind, but I guess going with the spec would be a good thing.
  2. Sync requests don't return the response, but use callbacks. I found that pretty unintuitive, and I think it brings quite a bit of procedure to clients using this code. Wouldn't it make sense to simply return the response? Async requests would of course still need a callback...
  3. Sync requests are async requests with a (busy?) waiting loop. You're waiting 100ms in each step... isn't that much too much?
  4. From my pov, this PR provides two things: An lsp-lib that can be used for clients, and a simple client. Would it make sense to separate those more? I found it a bit surprising that potential other clients have to unregister the default handlers, for example. Also, I see a lot of code that already handles things in a specific way, which befits a client, but not a lib. Not sure how important that is, but I'd separate those things :)
  5. I did not yet dive into that, but generally I found that user autocommands are inadequate because they can't carry arguments, i.e. you can't distinguish from which buffer they originated. Might that pose a problem when someone has several clients running? Or do you have a way to transport that information?
  6. Not a question, but please consider doing this.

@mcepl
Copy link
Contributor

@mcepl mcepl commented Jun 9, 2019

@tjdevries @KillTheMule ping? This LSP client is accused of being a cause of #10167.

@KillTheMule
Copy link
Contributor

@KillTheMule KillTheMule commented Jun 10, 2019

Hey, my latest info was that tj was working on a larger refactoring, but I haven't heard from him since. I'm pressed for time these days, so I did not push this.

@h-michael
Copy link
Member

@h-michael h-michael commented Jun 11, 2019

@KillTheMule @tjdevries Can I take over this PR?

@bfredl
Copy link
Member

@bfredl bfredl commented Jun 11, 2019

@h-michael Sure, open a new PR with your changes.

@KillTheMule
Copy link
Contributor

@KillTheMule KillTheMule commented Jun 11, 2019

@h-michael Sure, open a new PR with your changes.

Definitely. I'll keep track and try to help out, let me know if there's something particular you'd like me to do. In particular, I could extend my "nvim as a fake language server" approach for testing :)

@h-michael h-michael mentioned this pull request Jun 14, 2019
20 tasks done
@h-michael
Copy link
Member

@h-michael h-michael commented Jun 14, 2019

I open the PR #10222. And I would like to discuss where to set the fish line. :)

@mcepl
Copy link
Contributor

@mcepl mcepl commented Sep 16, 2019

Shouldn’t this PR be closed? The story is no longer here.

@justinmk justinmk closed this Sep 22, 2019
@neovim neovim locked as resolved and limited conversation to collaborators Sep 22, 2019
@justinmk
Copy link
Member

@justinmk justinmk commented Sep 22, 2019

Resolution/Summary

Continued at #10222 .


Locked to keep the summary visible. You can always chat or open a ticket if you have new information/topics to discuss.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet