GoTo Definition (etc.) support

[jhossbach]

Hey,
I love the project and would like to eventually switch to ruff-lsp for my daily use. To do that, I'd like to contribute more functionality to the LSP, such as GoToDefinition, hover functionality etc.
It would be cool to have some kind of roadmap for the planned features for the LSP.

[pythops]

@charliermarsh
This is a really essential feature for ruff-lsp to be used as an lsp server 🙏

[rassie]

What would GoToDefinition and hover look like in context of ruff-lsp? It's not a generic Python LSP server after all, it's just a linter. I'm using it as a secondary server to python-lsp-server, which provides all the usual perks of language servers -- maybe such setup would suit you better?

[charliermarsh]

Right now, the intent is for ruff-lsp to be used alongside another Python LSP, to provide behaviors like GoTo Definition. ruff-lsp is really focused on enabling in-editor usages of Ruff -- so taking Ruff's functionality and exposing it to various clients. As I expand Ruff, ruff-lsp should benefit too, sometimes "automatically" (by way of introducing new checks), and sometimes explicitly (by way of introducing new actions).

So at present, the roadmap for improving the LSP is mostly a subset of the roadmap for improving Ruff.

Here are a few things that are on my mind:

• Improving the autofix messages, which are far too generic (Add custom messages to the Fix API ruff#1454).
• Adding autofix for more rules, like unused variables (Add autofix for "unused variable" ruff#1460).
• Adding more editor-friendly rules, like flake8-simplify (Implement flake8-simplify ruff#998).

I would love help with any and all of those!

Beyond these items, I do want to expand Ruff into a general autoformatter. I'll write more about that soon.

[charliermarsh]

I guess the other option would be to look into leveraging another tool (like Jedi) to power some LSP capabilities and bundle them into Ruff -- @tsugumi-sys looked into that a bit here: #47.

[rchl]

I'm not sure we need another jedi-based python lsp server. Jedi is the main bottleneck of servers based on it and pyright, for example, has dramatically better performance because it's not based on jedi (not even using the same language).

So unless there is plan to re-implement Jedi-like functionality in Rust, maybe let's keep ruff lean, fast and focused on linting? :)

[jfcherng]

Same. Even it's implemented, presuming my PC has Node.js always available, I don't see the reason why I would use it while pyright (imho) outperforms jedi in "Go to Definition". And maybe soon someone will ask for type checking as well. I don't need a big average Swiss knife but I am looking for champions in their own major field.

But as long as it's optional, I don't really care.

[charliermarsh]

Yeah I feel similarly. If we add support for these features, it would be by way of writing a first-class autocompletion and language server in Rust, as opposed to bolting on something else.