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

Remove some refactoring commands #419

Open
liquidz opened this issue Jun 28, 2022 · 4 comments
Open

Remove some refactoring commands #419

liquidz opened this issue Jun 28, 2022 · 4 comments
Labels
breaking Breaking changes

Comments

@liquidz
Copy link
Owner

liquidz commented Jun 28, 2022

It is enough to use clojure-lsp.

@liquidz liquidz added the breaking Breaking changes label Jun 28, 2022
@sheluchin
Copy link

Interesting move. There is quite a bit of overlap between clojure-lsp functionality and nrepl. My understanding is the biggest difference is LSP uses static analysis while nrepl works by looking at evaluated code. I guess there is a tradeoff.

Do you have an opinion on suggesting LSP use for other functionality like formatting, jumping to definition, finding references, etc.?

@liquidz
Copy link
Owner Author

liquidz commented Jun 29, 2022

@sheluchin

Do you have an opinion on suggesting LSP use for other functionality like formatting, jumping to definition, finding references, etc.?

During development, code locations change dynamically.
When codes are evaluated without saving, code locations are known only by nREPL, so I think it is better to use nREPL's functionality for jumping to definitions and finding references.

Ideally, formatting codes should be handled statically, but I do not plan to turn it off since it is an essential feature during development.
I do not intend to make users impossible to develop without LSP.

Features now I plan to turn it off are:

  • Features that are not essential for development, but would be nice to have
  • && Features that should be handled statically and do not require nrepl
  • && Features for which clojure-lsp already has a more sophisticated implementation

vim-iced does not intend to compete with clojure-lsp, but to complement each other.

@sheluchin
Copy link

@liquidz thank you for the insight into your thought process. I think what you explained makes sense and helps me understand vim-iced a little better.

One of the challenges that myself and other vim+clojure users talk about is that there are often many competing solutions for doing some thing. It's a balance between power and simplicity. The way I look at vim-iced is as a tool that brings together many other tools to create a comprehensive development tool.

Do you prefer to point users to using clojure-lsp with some other plugin like coc-clojure, vim-lsp, etc., or are you thinking about adding LSP options to vim-iced's menus? I'd be happy to help out with some of the docs if I can.

@liquidz
Copy link
Owner Author

liquidz commented Jul 5, 2022

@sheluchin

Do you prefer to point users to using clojure-lsp with some other plugin like coc-clojure, vim-lsp, etc.,

Yes.
In my opinion, using clojure-lsp has advantages but no disadvantages.

or are you thinking about adding LSP options to vim-iced's menus?

Currently no.
As you know, there are several LSP clients in vim/nvim, and it is difficult to cover them as vim-iced options.
Also having an LSP client on the vim-iced side is too wasteful, so I wanted to leave the LSP configuration to users for now.

I'd be happy to help out with some of the docs if I can.

PR is very welcomed :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking Breaking changes
Projects
None yet
Development

No branches or pull requests

2 participants