Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code gets native LSP support

github.com

Post reply on HN
Print view View original

101–110 of 352 posts

Re: Claude Code gets native LSP support

#101

Post by eterm »

atmosx wrote: post #93
eterm wrote: post #85

Earlier quoted context omitted.

I completely agree. Likewise I'm amazed Microsoft hasn't done it themselves for Roslyn and Copilot. Roslyn analyzers are so incredibly powerful, and it's being ignored. An explainer for others: Not only can analyzers act as basic linters, but transformations are built right in to them. Every time claude does search-and-replace to add a parameter I want to cry a little, this has been a solved science. Agents + Roslyn…

Is Roslyn available only for .NET?

Yes it's the name of the .NET compiler API.

It was code-named to disambiguate it from the old compiler. But Roslyn is almost 15 years old now, so I can't call it new, but it's newer than the really legacy stuff.

It essentially lets you operate on the abstract snytax tree itself, so there is background compilation that powers inspection and transformation.

Instant renaming is an obvious benefit, but you can do more powerful transformations, such as removing redundant code or transforming one syntax style into another, e.g. tranforming from a Fluent API into a procedural one or vice-versa.

Re: Claude Code gets native LSP support

#102

Post by BeetleB »

anthonypasq wrote: post #48

I find it so weird that people are so bullish on the CLI form factor when they are literally just adding functionality that IDE based agents get for free. Stuff like improved diff tools and LSP support in the terminal instead of idk... just using a GUI/IDE? Pretty sure Cursor has had this for a while.

For many of us, the plus of the CLI form factor is it doesn't tie us to a particular IDE.

Re: Claude Code gets native LSP support

#103

Post by dist-epoch »

reactordev wrote: post #91
spullara wrote: post #31

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…

When you become complacent and your ego isn’t checked, you think you have the hottest thing. Hubris is hard. They had a pretty big moat that they let vscode eat away at. I don’t think they saw any of this coming and are struggling to make sense of it.

They are trying now to create an agent-first IDE. I think they are too big to move on this.

https://blog.jetbrains.com/fleet/2025/12/the-future-of-fleet...

Re: Claude Code gets native LSP support

#104

Post by imiric »

NitpickLawyer wrote: post #90
imiric wrote: post #87

Earlier quoted context omitted.

The idea that this technology isn't useful is as ignorant as thinking that there is no "AI" bubble. Of course there is a bubble. We can see it whenever these companies tell us this tech is going to cure diseases, end world hunger, and bring global prosperity; whenever they tell us it's "thinking", can "learn skills", or is "intelligent", for that matter. Companies will absolutely devalue and the market will crash whe…

> This is why we're seeing the bulk of gains from things like MCP and, now, "agents". This is objectively not true. The models have improved a ton (with data from "tools" and "agentic loops", but it's still the models that become more capable). Check out [1] a 100 LoC "LLM in a loop with just terminal access", it is now above last year's heavily harnessed SotA. > Gemini 3 Pro reaches 74% on SWE-bench verified with mi…

I don't understand. You're highlighting a project that implements an "agent" as a counterargument to my claim that the bulk of improvements are from "agents"?

Sure, the models themselves have improved, but not by the same margins from a couple of years ago. E.g. the jump from GPT-3 to GPT-4 was far greater than the jump from GPT-4 to GPT-5. Currently we're seeing moderate improvements between each release, with "agents" taking up center stage. Only corporations like Google are still able to squeeze value out of hyperscale, while everyone else is more focused on engineering.

Re: Claude Code gets native LSP support

#105

Post by bakies »

anthonypasq wrote: post #48

I find it so weird that people are so bullish on the CLI form factor when they are literally just adding functionality that IDE based agents get for free. Stuff like improved diff tools and LSP support in the terminal instead of idk... just using a GUI/IDE? Pretty sure Cursor has had this for a while.

Well my editor is in the terminal, so is my chatbot. I dont really want to change to an IDE to use a desktop app and a chatbot that both have half-baked UIs trying to complement each other.

Re: Claude Code gets native LSP support

#106

Post by BeetleB »

1123581321 wrote: post #6

This is an ignorant question, but, what is the benefit of this if you also have your project open in an editor or IDE (presuming they integrate language server?) If you're vibe coding without an editor, would this have any benefits to code quality over a test suite and the standard linter for a language?

As part of a bigger refactor, you want to rename some variables. With an LSP hook, the LLM can make the change (more) reliably.

The LLM wants to see the definition of a function. More reliable than grepping.

Re: Claude Code gets native LSP support

#107

Post by edelhans »

dist-epoch wrote: post #103
reactordev wrote: post #91

Earlier quoted context omitted.

When you become complacent and your ego isn’t checked, you think you have the hottest thing. Hubris is hard. They had a pretty big moat that they let vscode eat away at. I don’t think they saw any of this coming and are struggling to make sense of it.

They are trying now to create an agent-first IDE. I think they are too big to move on this. https://blog.jetbrains.com/fleet/2025/12/the-future-of-fleet...

They just announced the end of their fleet editor

Re: Claude Code gets native LSP support

#108

Post by dionian »

shermantanktop wrote: post #61
anthonypasq wrote: post #42

Earlier quoted context omitted.

there is a jetbrains MCP server that gives Claude Code access to this sort of thing, but I think its still fairly jank and bloats context.

I never got it to work, but in the process of trying it became obvious that it’s an under-resourced feature.

it would hang for me half the time , the last time i tried it (3-4months ago?). when it worked, it seemed really good. but it hung often. time to try again

Re: Claude Code gets native LSP support

#109

Post by 3836293648 »

oofbey wrote: post #69

I should know this, but what's LSP? Language Server Protocol - I can read. But what's that?

It's the protocol that VSC made to speak to programs that do code analysis and is the basis of goto definition, autocomplete, refactorings etc.

It's used by most smaller editors so they can backpack off of the efforts languages make to be usable in VSC. (Vim, Emacs, Zed, etc)

Re: Claude Code gets native LSP support

#110

Post by zingar »

anthonypasq wrote: post #48

I find it so weird that people are so bullish on the CLI form factor when they are literally just adding functionality that IDE based agents get for free. Stuff like improved diff tools and LSP support in the terminal instead of idk... just using a GUI/IDE? Pretty sure Cursor has had this for a while.

IDEs have LSP support because they have a plugin that connects to an LSP server. The plugin is a very small piece of code compared to the language server. Creating a new client is not reinventing the wheel. In fact the entire philosophy of LSP is: one server to many different clients.

CLIs can also have a small piece of code that connects to an LSP server. I don’t see why IDEs should be the sole beneficiary of LSP just because they were the first clients imagined by the LSP creators.

Post reply on HN