151–160 of 229 posts
Earlier quoted context omitted.
You don’t need to; UTF-16 is mandatory (ugh), but support for other encodings is negotiated (see ClientCapabilities.positionEncoding and ServerCapabilities.positionEncoding).
This seems somewhat pointless, because for compatibility you need to support UTF-16 anyway, so why bother implementing any of the other encodings in addition.
Earlier quoted context omitted.
Exactly! There is such a shift in paradigm that needs to happen here and the only project I know of that is moving in this direction is Unison. I don't want to edit a "file", I want to edit these two functions that exist in some module(s), why can't I just see those two? I constantly jump between many different languages and the cognitive load is noticeable: was it "!=", "/=" or "~="? Why am I writing/viewing ascii a…
> If I am most comfortable/fluent viewing python, why can't I view a javascript source as python? Because they are not isomorphic. At all. Even if you just consider the languages themselves, and ignore their ecosystems, which, in practice, you cannot.
The way a language server should work, imo, is it holds all the code and serves projections of the code on the fly to the editor. The user of the editor makes changes to the code and commits it back, at which point the language server parses the code and integrates it into the codebase, pretty-printing it to files as necessary for source control. But, the file layout should be an implementation detail that the editor…
Earlier quoted context omitted.
What we are seeing now could fit a timeline where Microsoft is doing EEE again, as well as a timeline where Microsoft is trying to change its ways. Building VSCode, LSP and Typescript could still prove to be the Embrace and Extend phase. There are some worrying signs, e.g. many VSCode extensions built by MS don't work on open-source VSCode builds like code-server and VSCodium. From a business perspective, this makes…
By this logic, they are also currently Embracing and Extending Windows, Office, etc. This doesn't make sense to me. It's their original products, not something they embraced and plan on extinguishing.
They are not extinguishing their own products, but using their products to extinguish alternatives. The example I mentioned actually fits the wikipedia definition quite well in my opinion.
Hopefully LSP specification can evolve over time and incorporate some of these ideas!
I do not follow the argumentation. LSPs are created for text editors. They are focused on lightweight text editor presentation. If you want to expose AST, you either start implementing clients again (defeating the original purpose) or you start being 3-7 levels down the abstraction madness. You can do that and projecting ASTs instead of representing text (looking at you JetBrains MPS) but even the best IDE companies…
It makes the (probably reasonable) assumption that all development happens in file-based text editors, and imposes the text editor model. That's fine, but there are other ways to organize code objects, and the LSP ecosystem is mainly useless to them.
Which is frustrating for the people working in or on that model, but maybe of no concern to others and probably no reason VSCode etc would want to have focused on the possibilities of that alternative.
But it means people doing the heterodox will have to reinvent the wheel completely instead of partially.
I hope we're nearing the end of the era where we're editing text in a bubble of tooling that understands ASTs but has to map everything back to text. I look forward making tabs vs spaces a viewer setting and not an author choice.
It's just the lowest common denominator, and it will always be that. Revision control tools, editors, compilers, the entire world is built around this. And there's no single alternative that could take its place.
The reality is that systems like a Smalltalk image or stored procedures in a database, or a fancy IDE, or whatever are just going to have to bundle tools for good interop with filesystems at that level, and that's just how it goes.
In the end what we have in text files is a mediocre, but universal, interop system.
The biggest problem with LSP is that it's a lowest common denominator solution. If I try to edit OCaml using an LSP solution, I don't get features like "query type of symbol", presumably because JavaScript doesn't need it.
Earlier quoted context omitted.
That’s the part I vehemently disagree with. There are servers written in a whole lot of languages. I’d bet there are Java servers written in Java. How are you going to link that into an editor written in C? What if the server’s written in Python? A shell script (crazy but legal!)? And even if you solve all of those for C, what if you want to write an editor in Swift. Now you have to implement all those shared library…
Frankly, if your language can't compile a .so/.dll that can interact with the rest of the system in a sane way, use a better language. I used to disagree with Blow on this point, as stdin/stdout communication really has the arguable advantage that you can write your Brainfuck LSP in Brainfuck, but I've spent way more time than I find reasonable over the last few years dealing with the consequences of the LSP model -…