Become LSP Provider

[xdavidel]

I'm really glad I was able to find this awesome plugin! I was just doing some searching before writing my own solution to this problem.

My way of thinking led me to think about creating an LSP server for cscope DBs so it can be use alongside clangd or some other provider.

Would you be interested in this kind of change?

Either way - this is a cool solution and I'm definitely using it from now on.

[dhananjaylatkar]

hey @xdavidel I'm not familiar with creating LSP server. Can you elaborate your idea? do you mean something like #23?

[xdavidel]

An LSP is somewhat different than an autocomplete provider.

It actually has to implement the features of the protocol - so the end result might give both results from clangd and cscope if both of them are attach. That way we can use the built-in vim.lsp.buf.references with no worries.

Also about making the server - I thought it might be possible to use an approach like none-ls and hook into the LSP features instead of writing a server.

I realize this could take a lot and and your solution works perfectly (actually started using it today), but I was crious to hear if this sounds like something worth investing into.

[dhananjaylatkar]

Thanks.

Didn't they stop null-ls because it was getting hard to manage?

Anyway I'll look into it and see if it's feasible.

[kqvanity]

I second this approach as well. I think not only would it allow us to use the same conventional LSP mappings, but also allow faster & more concentrated navigation because cscope sounds more like conventional copen with grep, except for the speed of course.

[dhananjaylatkar]

Hi @xdavidel / @xquilt cscope_lsp can only support following actions if implemented -

vim.lsp.buf.incoming_calls()  [callHierarchy/incomingCalls]
vim.lsp.buf.outgoing_calls()  [callHierarchy/outgoingCalls]
vim.lsp.buf.definition()      [textDocument/definition]
vim.lsp.buf.references()      [textDocument/references]

Would that be enough to call it "lsp"?

[xdavidel]

Hi @xdavidel / @xquilt cscope_lsp can only support following actions if implemented -

vim.lsp.buf.incoming_calls()  [callHierarchy/incomingCalls]
vim.lsp.buf.outgoing_calls()  [callHierarchy/outgoingCalls]
vim.lsp.buf.definition()      [textDocument/definition]
vim.lsp.buf.references()      [textDocument/references]

Would that be enough to call it "lsp"?

Well, according to the capabilities documentation I would argue Yes.

Seems to me other capabilities can be achieve using some work and combine with clangd / ccls / etc. we will have a complete solution.

[dhananjaylatkar]

cool. i'll start the implementation

[dhananjaylatkar]

@xdavidel / @xquilt

I have implemented definition support.

Try it out and provide feedback

https://github.com/dhananjaylatkar/cscope_lsp

[xdavidel]

@xdavidel / @xquilt

I have implemented definition support.

Try it out and provide feedback

https://github.com/dhananjaylatkar/cscope_lsp

That was quick. Will try that ASAP.

P.S: kudos for using TJs starting point for LSP

[kqvanity]

@dhananjaylatkar Thanks for the work. I've tested it on a dir composed of multiple Android projects and it does work, but there are a couple of gotcha

• It won't return definitions if the symbol doesn't have an import directive within the same file
• Definitions aren't confined to the project's root dir

I was wondering if go is your language of choice or if is it just because of the skeleton project by TJ. If you can consider Rust, I'd love to contribute to the project

[dhananjaylatkar]

@xquilt

Thanks for testing.

Can you open issues on cscope_lsp repo? We can discuss there.

Yeah, this is the first time I'm writing a "big" golang project. But also I've been looking for an opportunity to write golang so it works out for me.

I don't see any upside of moving to Rust and I prefer the simplicity of golang so, I won't be doing rewrite in Rust anytime soon.

[dhananjaylatkar]

Closing this issue.

See https://github.com/dhananjaylatkar/cscope_lsp