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

Open
wants to merge 60 commits into
base: master
from

Conversation

Projects
None yet
@tjdevries
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@bfredl

bfredl Jun 7, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Jun 7, 2017

Contributor

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

Contributor

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.

Show outdated Hide outdated runtime/autoload/lsp/request.vim Outdated
Show outdated Hide outdated runtime/autoload/lsp/request.vim Outdated
Show outdated Hide outdated runtime/lua/json.lua Outdated
Show outdated Hide outdated runtime/plugin/lsp.vim Outdated
Show outdated Hide outdated runtime/plugin/lsp.vim Outdated
Show outdated Hide outdated runtime/plugin/lsp.vim Outdated
Show outdated Hide outdated runtime/plugin/lsp.vim Outdated
Show outdated Hide outdated test/functional/lsp/callbacks/textDocument.lua Outdated
Show outdated Hide outdated runtime/lua/util.lua Outdated
Show outdated Hide outdated runtime/lua/lsp/client.lua Outdated
Show outdated Hide outdated runtime/plugin/lsp.vim Outdated
Show outdated Hide outdated runtime/lua/lsp/client.lua Outdated
@tjdevries

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Jun 27, 2017

Contributor

@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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jun 28, 2017

Member

Instead of callbacks why not publish RPC notifications?

Member

justinmk commented Jun 28, 2017

Instead of callbacks why not publish RPC notifications?

@bfredl

This comment has been minimized.

Show comment
Hide comment
@bfredl

bfredl Jun 28, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Jun 28, 2017

Contributor

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

Contributor

ZyX-I commented Jun 28, 2017

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

@tjdevries

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Jun 28, 2017

Contributor

@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', ...)?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Jun 29, 2017

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@euclio

euclio Aug 16, 2017

Contributor

What's the status of this?

Contributor

euclio commented Aug 16, 2017

What's the status of this?

@tjdevries

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Aug 16, 2017

Contributor

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 :)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@balta2ar

balta2ar 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?

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

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Aug 16, 2017

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jvican

jvican 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.

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

This comment has been minimized.

Show comment
Hide comment
@blueyed
Contributor

blueyed commented Sep 28, 2017

@tjdevries

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Sep 29, 2017

Contributor

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 :)

Contributor

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 :)

@bfredl bfredl referenced this pull request Oct 13, 2017

Merged

[RFC] News #153

@KillTheMule

This comment has been minimized.

Show comment
Hide comment
@KillTheMule

KillTheMule Dec 18, 2017

Contributor

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 :)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Dec 19, 2017

Contributor

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

Contributor

tjdevries commented Dec 19, 2017

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

local json = {}
-- TODO: Use the FFI module to decode and encode items, since that should be faster

This comment has been minimized.

@justinmk

justinmk Dec 28, 2017

Member

If you still plan to do this, please wait until a separate PR. It will probably involve changes to the build process, dependencies, etc. And I suspect the performance won't actually matter.

@justinmk

justinmk Dec 28, 2017

Member

If you still plan to do this, please wait until a separate PR. It will probably involve changes to the build process, dependencies, etc. And I suspect the performance won't actually matter.

This comment has been minimized.

@tjdevries

tjdevries Dec 28, 2017

Contributor

Before marking ready for review, I'll try and make sure this is true, but I plan on having it be: plain-old TODO: ... comments are things that are out of the scope of this PR but could be cool/nice. I'll try and change the TODOs I want to get to into TODO(tjdevries): ...

@tjdevries

tjdevries Dec 28, 2017

Contributor

Before marking ready for review, I'll try and make sure this is true, but I plan on having it be: plain-old TODO: ... comments are things that are out of the scope of this PR but could be cool/nice. I'll try and change the TODOs I want to get to into TODO(tjdevries): ...

@TrySound

This comment has been minimized.

Show comment
Hide comment
@TrySound

TrySound Dec 29, 2017

Is this PR still very much WIP?

TrySound commented Dec 29, 2017

Is this PR still very much WIP?

@tjdevries

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Dec 29, 2017

Contributor

@TrySound it does work for some of the requests, such as "textDocument/definition" or "textDocument/hover", but I made some changes today that broke regular requests, so you'd have to use async requests (call lsp#request_async('textDocument/hover')) to get them to work.

I'm hoping to finish up some usability type items in the next couple days/weeks, add some tests, and then declare it "reviewable" :)

Contributor

tjdevries commented Dec 29, 2017

@TrySound it does work for some of the requests, such as "textDocument/definition" or "textDocument/hover", but I made some changes today that broke regular requests, so you'd have to use async requests (call lsp#request_async('textDocument/hover')) to get them to work.

I'm hoping to finish up some usability type items in the next couple days/weeks, add some tests, and then declare it "reviewable" :)

@mcepl

This comment has been minimized.

Show comment
Hide comment
@mcepl

mcepl Oct 1, 2018

Contributor

You would have to compile 5.2 in compatibility mode (there is a compile-time flag for it).

@teto

  1. it is Lua 5.3.4 actually (using LInux distribution openSUSE/Tumbleweed makes me use the very latest versions of most packages)

  2. "compile 5.2" means compiling Lua or compiling neovim? I would prefer not to do the former and continue to use Lua from the standard distro packages.

Contributor

mcepl commented Oct 1, 2018

You would have to compile 5.2 in compatibility mode (there is a compile-time flag for it).

@teto

  1. it is Lua 5.3.4 actually (using LInux distribution openSUSE/Tumbleweed makes me use the very latest versions of most packages)

  2. "compile 5.2" means compiling Lua or compiling neovim? I would prefer not to do the former and continue to use Lua from the standard distro packages.

@teto

This comment has been minimized.

Show comment
Hide comment
@teto

teto Oct 1, 2018

Contributor

It meant recompile lua. I don't know if the compatibility flag is still available in 5.3. Otherwise you can just modify the PR to either set unpack = table.unpack or replace occurences of unpack by table.unpack.

Contributor

teto commented Oct 1, 2018

It meant recompile lua. I don't know if the compatibility flag is still available in 5.3. Otherwise you can just modify the PR to either set unpack = table.unpack or replace occurences of unpack by table.unpack.

Show resolved Hide resolved runtime/lua/lsp/autocmds.lua Outdated
@bfredl

This comment has been minimized.

Show comment
Hide comment
@bfredl

bfredl Oct 1, 2018

Member

It would be great to standardize the set of lua versions core and third-party lua plugins are expected to support. Some level of compatibility could perhaps be provided by our own prelude, like defining unpack = table.unpack and similar in versions it is missing.

More specifically about this PR, it would be good to document a simple standard way to feature detect the presence of the this plugin. Currently I do this in my init.vim:

runtime autoload/lsp.vim
runtime autoload/lsp/server.vim
if exists("*lsp#server#add")
    call lsp#server#add(['c', 'c++'], ['clangd'], {})
endif

as plain exists("*") unfortunately doesn't work with autoload functions.

Member

bfredl commented Oct 1, 2018

It would be great to standardize the set of lua versions core and third-party lua plugins are expected to support. Some level of compatibility could perhaps be provided by our own prelude, like defining unpack = table.unpack and similar in versions it is missing.

More specifically about this PR, it would be good to document a simple standard way to feature detect the presence of the this plugin. Currently I do this in my init.vim:

runtime autoload/lsp.vim
runtime autoload/lsp/server.vim
if exists("*lsp#server#add")
    call lsp#server#add(['c', 'c++'], ['clangd'], {})
endif

as plain exists("*") unfortunately doesn't work with autoload functions.

@mcepl

This comment has been minimized.

Show comment
Hide comment
@mcepl

mcepl Oct 1, 2018

Contributor

This patch seems to make this pull request work.

Also, is there some function which could be set as omnifunc?
When I set

au FileType python setlocal omnifunc=lsp#completion#omni

it kind of works, but not completely. When the cursor is on the end of os.pa pressing <Ctrl>-x,<Ctrl-o> doesn't complete os.path, but it presents all children of os module starting with os.abc. Pressing Ctrl-n (which calls lsp#completion#complete()) works correctly.

Contributor

mcepl commented Oct 1, 2018

This patch seems to make this pull request work.

Also, is there some function which could be set as omnifunc?
When I set

au FileType python setlocal omnifunc=lsp#completion#omni

it kind of works, but not completely. When the cursor is on the end of os.pa pressing <Ctrl>-x,<Ctrl-o> doesn't complete os.path, but it presents all children of os module starting with os.abc. Pressing Ctrl-n (which calls lsp#completion#complete()) works correctly.

@jamessan

This comment has been minimized.

Show comment
Hide comment
@jamessan

jamessan Oct 1, 2018

Member

It would be great to standardize the set of lua versions core and third-party lua plugins are expected to support.

Isn't that the same as nvim -- LuaJIT or Lua 5.1? Due to Lua's (lack of) compatibility guarantees across versions, there shouldn't be any expectation about other Lua versions working unless people have done the necessary compatibility work.

Member

jamessan commented Oct 1, 2018

It would be great to standardize the set of lua versions core and third-party lua plugins are expected to support.

Isn't that the same as nvim -- LuaJIT or Lua 5.1? Due to Lua's (lack of) compatibility guarantees across versions, there shouldn't be any expectation about other Lua versions working unless people have done the necessary compatibility work.

@mcepl

This comment has been minimized.

Show comment
Hide comment
@mcepl

mcepl Oct 1, 2018

Contributor

Isn't that the same as nvim -- LuaJIT or Lua 5.1?

Can I explain why Lua 5.1 at all? According to https://www.lua.org/versions.html#numbering

The last release was Lua 5.1.5, released on 17 Feb 2012.

What am I missing? Why is it such a deal to support version of Lua which has been EOSed six years ago?

Contributor

mcepl commented Oct 1, 2018

Isn't that the same as nvim -- LuaJIT or Lua 5.1?

Can I explain why Lua 5.1 at all? According to https://www.lua.org/versions.html#numbering

The last release was Lua 5.1.5, released on 17 Feb 2012.

What am I missing? Why is it such a deal to support version of Lua which has been EOSed six years ago?

@bfredl

This comment has been minimized.

Show comment
Hide comment
@bfredl

bfredl Oct 1, 2018

Member

Isn't that the same as nvim -- LuaJIT or Lua 5.1?

It doesn't seem to be standardised enough if nvim compiles without any error/warning with lua 5.3. Or did OPENSUSE patch our build to use lua 5.3 despite such a restriction?

Member

bfredl commented Oct 1, 2018

Isn't that the same as nvim -- LuaJIT or Lua 5.1?

It doesn't seem to be standardised enough if nvim compiles without any error/warning with lua 5.3. Or did OPENSUSE patch our build to use lua 5.3 despite such a restriction?

@bfredl

This comment has been minimized.

Show comment
Hide comment
@bfredl

bfredl Oct 1, 2018

Member

What am I missing? Why is it such a deal to support version of Lua which has been EOSed six years ago?

The deal is rather to support luajit, which supports lua 5.1 plus some conservative extensions, but not all of 5.2 or 5.3. luajit 2.1-beta claims to support "various extension from Lua 5.2/5.3", but I don't know which extensions (nor when 2.1 stable will be released).

Member

bfredl commented Oct 1, 2018

What am I missing? Why is it such a deal to support version of Lua which has been EOSed six years ago?

The deal is rather to support luajit, which supports lua 5.1 plus some conservative extensions, but not all of 5.2 or 5.3. luajit 2.1-beta claims to support "various extension from Lua 5.2/5.3", but I don't know which extensions (nor when 2.1 stable will be released).

@jamessan

This comment has been minimized.

Show comment
Hide comment
@jamessan

jamessan Oct 1, 2018

Member

Can I explain why Lua 5.1 at all?

LuaJIT is explicitly compatible with Lua 5.1. There are no guarantees it will work with Lua constructs from newer versions of Lua.

It doesn't seem to be standardised enough if nvim compiles without any error/warning with lua 5.3.

We may not be using anything that differs between Lua 5.1 and Lua 5.2/5.3 yet. We could certainly make the Lua checks stricter about that. As long as we support LuaJIT, I'm not sure there's much else we can do. we'll either need to do that or be willing to make conditionally-enabled code for newer Lua versions that we want to support.

Since different Lua versions aren't ABI compatible (but share an API surface), we would be safe as long as the third-party code is built against the same Lua version.

Member

jamessan commented Oct 1, 2018

Can I explain why Lua 5.1 at all?

LuaJIT is explicitly compatible with Lua 5.1. There are no guarantees it will work with Lua constructs from newer versions of Lua.

It doesn't seem to be standardised enough if nvim compiles without any error/warning with lua 5.3.

We may not be using anything that differs between Lua 5.1 and Lua 5.2/5.3 yet. We could certainly make the Lua checks stricter about that. As long as we support LuaJIT, I'm not sure there's much else we can do. we'll either need to do that or be willing to make conditionally-enabled code for newer Lua versions that we want to support.

Since different Lua versions aren't ABI compatible (but share an API surface), we would be safe as long as the third-party code is built against the same Lua version.

@bfredl

This comment has been minimized.

Show comment
Hide comment
@bfredl

bfredl Oct 1, 2018

Member

We may not be using anything that differs between Lua 5.1 and Lua 5.2/5.3 yet. We could certainly make the Lua checks stricter about that.

I was thinking of some explicit check in our makefiles or test suite or similar, or at least some clear communication to distros that lua 5.2 or 5.3 is not supported.

Member

bfredl commented Oct 1, 2018

We may not be using anything that differs between Lua 5.1 and Lua 5.2/5.3 yet. We could certainly make the Lua checks stricter about that.

I was thinking of some explicit check in our makefiles or test suite or similar, or at least some clear communication to distros that lua 5.2 or 5.3 is not supported.

@jamessan

This comment has been minimized.

Show comment
Hide comment
@jamessan

jamessan Oct 1, 2018

Member

at least some clear communication to distros that lua 5.2 or 5.3 is not supported.

I thought that was handled by the LuaJIT support, but I guess that knowledge isn't as well known as I thought.

Member

jamessan commented Oct 1, 2018

at least some clear communication to distros that lua 5.2 or 5.3 is not supported.

I thought that was handled by the LuaJIT support, but I guess that knowledge isn't as well known as I thought.

@Shougo

This comment has been minimized.

Show comment
Hide comment
@Shougo

Shougo Oct 1, 2018

Contributor

I have tested the branch, it works.

But some questions are available.

@tjdevries

Here's an example of it working in Neovim using the cquery language server: https://asciinema.org/a/199714

I have tested cquery, but the completion does not work.
Can you share the configuration?

go-langserver requires "initialization" request to configure.
The feature is supported?

I want to test "Hover" and "Goto definition" features.
Can you share the configuration?
I think it should be documented.

Contributor

Shougo commented Oct 1, 2018

I have tested the branch, it works.

But some questions are available.

@tjdevries

Here's an example of it working in Neovim using the cquery language server: https://asciinema.org/a/199714

I have tested cquery, but the completion does not work.
Can you share the configuration?

go-langserver requires "initialization" request to configure.
The feature is supported?

I want to test "Hover" and "Goto definition" features.
Can you share the configuration?
I think it should be documented.

Show resolved Hide resolved runtime/lua/lsp/structures.lua Outdated
@mcepl

This comment has been minimized.

Show comment
Hide comment
@mcepl

mcepl Oct 2, 2018

Contributor

I thought that was handled by the LuaJIT support, but I guess that knowledge isn't as well known as I thought.

@jamessan Thanks, I have switched my build for SUSE/Fedora/RHEL to LuaJIT, where possible.

Contributor

mcepl commented Oct 2, 2018

I thought that was handled by the LuaJIT support, but I guess that knowledge isn't as well known as I thought.

@jamessan Thanks, I have switched my build for SUSE/Fedora/RHEL to LuaJIT, where possible.

@mcepl

This comment has been minimized.

Show comment
Hide comment
@mcepl

mcepl Oct 2, 2018

Contributor

When I set

au FileType python setlocal omnifunc=lsp#completion#omni

it kind of works, but not completely. When the cursor is on the end of os.pa pressing <Ctrl>-x,<Ctrl-o> doesn't complete os.path, but it presents all children of os module starting with os.abc. Pressing Ctrl-n (which calls lsp#completion#complete()) works correctly.

Any reponse on this one?

Contributor

mcepl commented Oct 2, 2018

When I set

au FileType python setlocal omnifunc=lsp#completion#omni

it kind of works, but not completely. When the cursor is on the end of os.pa pressing <Ctrl>-x,<Ctrl-o> doesn't complete os.path, but it presents all children of os module starting with os.abc. Pressing Ctrl-n (which calls lsp#completion#complete()) works correctly.

Any reponse on this one?

@tjdevries

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Oct 7, 2018

Contributor

@mcepl I believe that I messed something up in the omni-completion part of the plugin. The complete() function was what I had gotten working and then I think I forgot to finish the rest.

Contributor

tjdevries commented Oct 7, 2018

@mcepl I believe that I messed something up in the omni-completion part of the plugin. The complete() function was what I had gotten working and then I think I forgot to finish the rest.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Oct 8, 2018

Member

(Sorry for late response: extremely slow (15 kb/s) connection in recent weeks.)

Hey @justinmk, I was wondering what exactly we're looking for to get this merged in (or at least part 1 merged in, with several subsequent PRs).

@tjdevries Nothing blocking it as long as the public API is minimal (e.g., can it be listed in fewer than 10 lines? :).

I would prefer much less granularity/hierarchy in the way things are organized internally, but this isn't a blocker:

  • If the VimL part needs more than one VimL file, there's too much VimL. It should be a small (preferably non-existent: we should try to make Lua easier to work with directly, rather than adding these VimL wrapper functions everywhere) handful of public functions calling Lua internals.

What am I missing? Why is it such a deal to support version of Lua which has been EOSed six years ago?

@mcepl Lua 5.1 is a different language than 5.3. Lua org makes breaking changes with every new version, so even if we hauled our butts to 5.3 we gain nothing when they create the next new language in 5.4, 5.5, etc. And we lose LuaJit, which is far more valuable than Lua 5.3+.

Lua 5.1 is a complete language. To "upgrade" it, just add libraries, not syntax. Nvim itself already is a pretty good "stdlib" for Lua, and we can continue to grow that.

Added to FAQ.

Member

justinmk commented Oct 8, 2018

(Sorry for late response: extremely slow (15 kb/s) connection in recent weeks.)

Hey @justinmk, I was wondering what exactly we're looking for to get this merged in (or at least part 1 merged in, with several subsequent PRs).

@tjdevries Nothing blocking it as long as the public API is minimal (e.g., can it be listed in fewer than 10 lines? :).

I would prefer much less granularity/hierarchy in the way things are organized internally, but this isn't a blocker:

  • If the VimL part needs more than one VimL file, there's too much VimL. It should be a small (preferably non-existent: we should try to make Lua easier to work with directly, rather than adding these VimL wrapper functions everywhere) handful of public functions calling Lua internals.

What am I missing? Why is it such a deal to support version of Lua which has been EOSed six years ago?

@mcepl Lua 5.1 is a different language than 5.3. Lua org makes breaking changes with every new version, so even if we hauled our butts to 5.3 we gain nothing when they create the next new language in 5.4, 5.5, etc. And we lose LuaJit, which is far more valuable than Lua 5.3+.

Lua 5.1 is a complete language. To "upgrade" it, just add libraries, not syntax. Nvim itself already is a pretty good "stdlib" for Lua, and we can continue to grow that.

Added to FAQ.

@justinmk justinmk changed the title from [WIP] Built-in LSP Support to [RFC] Built-in LSP Support Oct 8, 2018

Show resolved Hide resolved runtime/autoload/lsp/util.vim Outdated
@@ -0,0 +1,14 @@
local autocmds = require('lsp.autocmds')

This comment has been minimized.

@justinmk

justinmk Oct 8, 2018

Member

lsp/config/autocmds.lua is too much nesting. lsp/config.lua should be enough--if it gets too big that suggests we didn't factor out enough common utilities into nvim stdlib.

(But really, I secretly advocate going further: lsp.lua should be enough! If it gets too big, it must have lots of utilities that should be in the nvim stdlib.)

@justinmk

justinmk Oct 8, 2018

Member

lsp/config/autocmds.lua is too much nesting. lsp/config.lua should be enough--if it gets too big that suggests we didn't factor out enough common utilities into nvim stdlib.

(But really, I secretly advocate going further: lsp.lua should be enough! If it gets too big, it must have lots of utilities that should be in the nvim stdlib.)

@marvim marvim added RFC and removed WIP labels Oct 8, 2018

@bfredl

This comment has been minimized.

Show comment
Hide comment
@bfredl

bfredl Oct 15, 2018

Member

Adding to what @justinmk said, a way to reduce API surface of the initial merge, is to remove autoload wrappers and focus mainly on the lua interface. Especially if justinmk's suggestion of reducing nesting of lua namespaces is followed, then

call lsp#request(...)

can be replaced by just

lua require'lsp'.request(...)

Also, encouraging plugins that build on top of this to be written in lua seems like a good idea.

Member

bfredl commented Oct 15, 2018

Adding to what @justinmk said, a way to reduce API surface of the initial merge, is to remove autoload wrappers and focus mainly on the lua interface. Especially if justinmk's suggestion of reducing nesting of lua namespaces is followed, then

call lsp#request(...)

can be replaced by just

lua require'lsp'.request(...)

Also, encouraging plugins that build on top of this to be written in lua seems like a good idea.

@mcepl

This comment has been minimized.

Show comment
Hide comment
@mcepl

mcepl Oct 17, 2018

Contributor

@tjdevries I have in https://github.com/mcepl/neovim/tree/lsp-support your lsp branch rebased on the current https://github.com/neovim/neovim/tree/master with one more additional commit mcepl@73ed482 (trying to understand why lsp#completion#omni doesn't work, but I am not much successful at the moment). This is what I build my openSUSE/Fedora packages.

Contributor

mcepl commented Oct 17, 2018

@tjdevries I have in https://github.com/mcepl/neovim/tree/lsp-support your lsp branch rebased on the current https://github.com/neovim/neovim/tree/master with one more additional commit mcepl@73ed482 (trying to understand why lsp#completion#omni doesn't work, but I am not much successful at the moment). This is what I build my openSUSE/Fedora packages.

@tjdevries

This comment has been minimized.

Show comment
Hide comment
@tjdevries

tjdevries Oct 18, 2018

Contributor

@mcepl fixing the completion is next on my list for this PR

Contributor

tjdevries commented Oct 18, 2018

@mcepl fixing the completion is next on my list for this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment