> But isn't that exactly the point of the post? The approach is nice for editors but unsuitable for IDEs. Yep. I'm just giving my thoughts on what it'd take to

> But isn't that exactly the point of the post? The approach is nice for editors but unsuitable for IDEs. Yep. I'm just giving my thoughts on what it'd take to extend LSP so it addresses the issues raised in the blog post. I think it's much harder than it might seem. > Seems to me LSP has the exact same problem with use-cases. By the description of the post, the goal seems to be to solve a fixed set of use-cases (highlighting, autocompletion, etc) for a flexible set of languages. If you want to add use-case n+1, you're faced with the same rewrite/hack conundrum. The difference is between "What does an editor need?" and "What is a faithful representation of an element of code in a programming language?" The former is easy (and it's what LSP does) even to do for 50 languages; the latter is way harder than the casual reader would expect.