How to configure it? I have LSP running in neovim, but Claude Code writes:
● LSP(operation: "goToDefinition", symbol: "mtz", in: "src/mtz.cpp") ⎿ No LSP server available for file type: .cpp
● No C++ LSP server is configured.
Claude Code gets native LSP support
331–340 of 352 posts
Re: Claude Code gets native LSP support
#332Seems like SCIP would be a better fit, although not as widely supported by languages I suppose.
It takse long to regen on big codebases, but yes
Re: Claude Code gets native LSP support
#333i think Kiro CLI added while ago and it does support diagnostics and rename symbol
Re: Claude Code gets native LSP support
#334[deleted]
Re: Claude Code gets native LSP support
#335Earlier quoted context omitted.
This is something I notice often when using these tools (if this is what you are referring too). Like they will grep entire code bases to search for a word rather than search by symbol. I suppose they don't care to fix these types of things as it all adds up to paid tokens in the end. We have 50 years worth of progress on top of grep and grep is one of the worse ways to refactor a system. Nice to see LLM companies ar…
> grep is one of the worse ways to refactor Hum? care to explain this?
Another poster mentioned using symbols and references, another way to refactor code programmatically is to make use of code mods. Code mods are very powerful and this is a use case where I find LLMs to shine as the various syntax and language ASTs are hard to remember (even if you do understand what you're doing).
Re: Claude Code gets native LSP support
#336Earlier quoted context omitted.
> grep is one of the worse ways to refactor Hum? care to explain this?
Using Grep or regex is textual refactoring. If you want to rename every reference to a type Foo, how do you is that without touching any variables named foo, or any classes named FooBar The answer is use tools that have semantic info to rename things.
I often want them to rename all the textual references too because otherwise you have bunch of variables using the old name as a reference.
Even though it has no semantic significance to the compiler, it does for all the human beings who will read it and get confused.
Re: Claude Code gets native LSP support
#337Earlier quoted context omitted.
Yes and no, GitKraken actually have a graphical interface for WSL (or Linux generally), but it is barely usable as the WSL-g does not really work well. It's blurry for Hi-Res screen and the performance is like hell. I would never try running any graphical stuff in WSL anymore, not worth it. VMWare with a graphical installation of any Linux system would be a preferred choice as I'm testing lately.
Or Proxmox or just virt-manager
Hmmm, is there a native virt-manager build on Windows? Though I suppose running it in WSL and connecting with an external SPICE client would work just as well. (I’m wondering if there’s a way to just run SPICE server in WSL.)
Re: Claude Code gets native LSP support
#338Earlier quoted context omitted.
What’s stopping you from using it in the terminal view of VSCode? Perhaps I’m misunderstanding your comment so please forgive me if I am. Maybe you’re saying that you wish VSCose itself was a TUI?
Yes the latter, that it did have a TUI option for its interface.
I think I’ve seen a project running vscode as a server (?) and rendering it in terminal, but I can’t find it now.
There’s a lot of decent TUI editors nowadays though, and with LSP they’re pretty on-par with vscode. Maybe try Micro? https://micro-editor.github.io/
Re: Claude Code gets native LSP support
#339Earlier quoted context omitted.
The commit workflow was what kept me locked in to the ecosystem for so long. LazyGit was so good that it convinced me I didn’t need JetBrains anymore. If you love the workflow with JB for commits check out LazyGit. It’s a TUI so you can use it in any editor without much friction.
I'm kinda reading this with disbelief. Are there people whose primary use case for IDE is... git gui?
I think you're thinking about git as a separate thing from the IDE.
I love using IJ + git because there are no seams in between edit and commit. For instance, with IJ, I could easily split every other line of a change into separate commits.
Maybe there's a way in git to stage only certain parts of a diff, but I'd have to go an learn another flag or command that I'm going to forget by the next time I need to do it again.
Also with IJ, I just glance at my main branch tab and the highlighting tells me what commits aren't in my checked out feature branch.
Two small examples but there are many more and it adds up.
Re: Claude Code gets native LSP support
#340Earlier quoted context omitted.
I'm kinda reading this with disbelief. Are there people whose primary use case for IDE is... git gui?
I think you're thinking about git as a separate thing from the IDE. I love using IJ + git because there are no seams in between edit and commit. For instance, with IJ, I could easily split every other line of a change into separate commits. Maybe there's a way in git to stage only certain parts of a diff, but I'd have to go an learn another flag or command that I'm going to forget by the next time I need to do it aga…
git add -i is the thing you'd have to learn.
I do that at the CLI most of the time and I'd say I'm quite experienced with it, but I still prefer IntelliJ when it gets complicated.