upvote

points

by duttish6 hours ago |
comments
upvoteby packetlost6 hours ago|
next
[-]
Well for one I wouldn't design it so both the LSP and the editor need a synchronized view of the underlying file.
reply
upvoteby kuschku1 hours ago|
prev|
next
[-]
One of the largest issues of LSP is that each language implementation needs to do everything separately, and that means each language will work differently.

Imagine if all the editing tools in microsoft word were specific to the language you used, and if you mixed German and English, each had different tooling.

Now if you mix Rust, HTML, JS, and CSS, they'll all have separate tooling, seperate "go to definition", and separate refactoring. Worst of all, none of them can see the definitions of the other ones.

So what you'd actually want to do is parse each language into your AST, with proper annotations as to what is what, and have all the "go to definition", the UI rendering, highlighting, refactoring, etc all done generically by the IDE ontop.

Which is much much closer to how Jetbrains IntelliJ does it, and why their tooling can handle "find usages" on an HTML element to find matching querySelector in .js files and matching selectors in .css

And if you subscribe to the AI stuff, you'd also want your AI to operate on this AST so it can learn skills that generalize across all languages.

reply
upvoteby lenkite2 hours ago|
prev|
next
[-]
Wouldn't a normalized protocol based on AST vocabulary and tree operations make more sense ?
reply
upvoteby mitxela6 hours ago|
prev|
[-]
Start with synchronous function calls instead of JSON. Microsoft knows how to do that - they invented COM and OLE. Function calls enable whatever data sharing is necessary to maintain a coherent view. Imagine trying to do OLE with JSON - just wouldn't work. (Does OLE still exist?)
reply
upvoteby jcranmer4 hours ago|
parent|
next
[-]
That doesn't really fix anything. The filesystem is fundamentally a racy shared data structure. If you made the entrypoint API synchronous, any half-way decent editor would shove the LSP queries to the synchronous API into a different thread, because "Do Not Block the UI Thread" is a fundamental principle of good UI programming.

Once you get past that, JSON-over-TCP is just another kind of asynchronous RPC mechanism, one that has the advantage that you can build it in just about any language with out-of-the-box tools. Trying to make a plugin system or a COM or CORBA or OLE based system really cuts out the ability to build language servers in most languages, because you have to be able to build the code in just the right way.

reply
upvoteby rspeele4 hours ago|
parent|
prev|
next
[-]
I feel like MS actually learned their lesson with synchronously integrating the language intelligence into the IDE. Old versions of VS would hang or crash based on bugs in the language tooling trying to provide intellisense. You'd restart and it'd work fine till you hit some other weird edge case. Generally this settled to a level of rare-bugginess where you were happy enough with the advantages not to go back to Emacs/VIM, but still annoyed at the occasional restart needed.

In no way does this mean LSP is a perfect solution, but anything synchronous would be a step backwards.

reply
upvoteby pjmlp4 hours ago|
parent|
prev|
next
[-]
Actually, COM is inspired by DCE/RPC and the initial versions had some similarities.

Parallel to that, IBM had SOM on OS/2, which was even better allowing for metaclasses and proper class inheritance, it was the key mechanism between Smalltalk and C++ on OS/2, where Smalltalk enjoyed a role similar to .NET on Windows nowadays.

OLE naturally still exists when using Office natively on Windows, other vendors seem to have forgotten about it.

COM's role on Windows has grown since Vista, and the Windows team redid many of the Longhorn ideas originally implemented in .NET into COM/C++, with WinRT being an evolution of COM.

reply
upvoteby mamp3 hours ago|
parent|
[-]
I've never heard of anyone calling SOM 'better' at anything this century. I came across it when it was the foundation for OpenDoc at Apple, your comment brought back many bad memories
reply
upvoteby pjmlp2 hours ago|
parent|
[-]
Compared with COM's design, it was much better.
reply
upvoteby throwaway73561 hours ago|
parent|
prev|
next
[-]
> Start with synchronous function calls instead of JSON.

LSP is a function call protocol. So that is already done?

reply
upvoteby cyberax5 hours ago|
parent|
prev|
next
[-]
Moreover, it's not just stupid, it also does not actually solve _anything_.

A synchronous function can also have obsolete indexing information if it races with the code updates.

reply
upvoteby cyberax5 hours ago|
parent|
prev|
[-]
Stupid idea.

So the LSP crashes and/or goes into a runaway memory consumption loop. And your main application dies with it.

Or what if you want, you know, to be able to use the same LSP from TWO different applications at the same time?

Never mind issues with other managed runtimes not expecting to deal with something else in their address space.

reply