Live data from Hacker News

Claude Code gets native LSP support

github.com

341–350 of 352 posts

Re: Claude Code gets native LSP support

#341
Seems like a great feature but am I the only one that still regularly sees the totally broken scrolling bug in CC?

I have churned from CC in favor of codex until the scrolling bug is fixed. There is no set of features that will convince me to switch back until they fix their broken UI.

I haven’t dug into the JS code base but I imagine they will have a hard time matching the performance of the rust based codex.

Re: Claude Code gets native LSP support

#343

Earlier quoted context omitted.

The same reason you want an LSP in your editor: so you get inline docs and error messages, autocomplete, jump to definition, refactoring actions etc.

But what is the benefit for Claude Code? You don't write code in Claude Code so why would I need autocomplete or jump to definition? Does Claude itself use them instead of e.g. grepping? Struggling to understand how it helps.

Yes, it's for Claude itself.

Re: Claude Code gets native LSP support

#344
post #274
post #233

Earlier quoted context omitted.

Fleet is cancelled, see the link above

Kind of figures, they were trying to compete with VS Code but they were not even able to create a stable release in all that time.

That’s a bit of an uncharitable take.

Fleet was very stable to use , it just never successfully turned into a product which they address in their link as well why that happened

Re: Claude Code gets native LSP support

#345
post #344
post #274

Earlier quoted context omitted.

Kind of figures, they were trying to compete with VS Code but they were not even able to create a stable release in all that time.

That’s a bit of an uncharitable take. Fleet was very stable to use , it just never successfully turned into a product which they address in their link as well why that happened

It never left the preview stage, so they did not feel confident calling it stable enough for their users and I don't use preview versions for products where there are already 10 production grade competitors.

Uncharitable but yeah, reality isn't always charitable.

Re: Claude Code gets native LSP support

#346
post #340

Earlier quoted context omitted.

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.

I felt really silly that the answer is just adding a "-i".

But then I tried it and...WHAT?! Git is an endless rabbit hole of complexity.

Re: Claude Code gets native LSP support

#347

I really can't understand why JetBrains hasn't integrated its refactoring tools into the AI system. Really missed the boat on making their platform transformational for AI coding. Imagine how much smaller the context would be for a tool that renames a function than editing hundreds of files. This LSP support is a good start but without the mutation functions it is still pretty lackluster. Plus LSPs aren't as good as…

Fortunately, Serena has recently been extended to use JetBrains instead of LSP (via a plugin), solving exactly this issue. LSP will never be as good as JetBrains' parsers.

https://github.com/oraios/serena#the-serena-jetbrains-plugin

Re: Claude Code gets native LSP support

#348

Earlier quoted context omitted.

I'm kinda reading this with disbelief. Are there people whose primary use case for IDE is... git gui?

Remember this when you're thinking about the average commenter's opinion on anything technical.

Remember this type of comment. Never let yourself fall into this type of thinking when trying to understand what your users want.

Instead of passing judgement on why someone values something, why not ask?

For example, if you were to ask me why I chose to keep using an IDE that I had spent years of my life building muscle memory using perhaps you would get a better understanding of the specific part of the lifecycle I was at when paying for software.

It's not that the git gui was the reason why I signed up for the software in the first place. The git gui was the last reason for me to not jump ship when switching to something like neovim or helix. This was during a time where LSP was becoming popular so refactoring tools and intellisense were finally getting better adoption outside of the JetBrains tooling. Most of this was achievable with editor du jour + lsp plugins, but the git ui was the one piece I hadn't personally solved outside of the JetBrains ecosystem.

Re: Claude Code gets native LSP support

#349
post #175

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

That's not the only reason I was using the tooling at the time. Specifically everything else regarding the JetBrains ecosystem kept me hooked, but when I was looking to replace what I liked in JetBrains with other tooling the last piece of the puzzle was replacing the git workflow.
Post reply on HN