Earlier quoted context omitted.
Lumpy Space Princess https://en.wikipedia.org/wiki/List_of_Adventure_Time_charact...
Article title: How Lumpy Space Princess could have been better Article content in full: She couldn’t.
Can't improve on perfection.
How LSP could have been better
121–130 of 229 posts
Re: How LSP could have been better
#122I’m fighting with it right now. LSP specifies several configuration mechanisms but there isn’t a “blessed” one. This is a pain point because: I want to write Python. There’s one FOSS language server (pylsp) that’s a better fit for my needs than the other Python servers. I want to use a certain commercial editor. The editor and the language server don’t share a common configuration method. Ergo, I can’t use the editor…
people actually like their editor? blasphemy. you must be using either sublime or kakoune
Re: How LSP could have been better
#123Earlier quoted context omitted.
I don't care how many credentials Jonathan Blow has, this take is pure bs. "we're spending all this time overcomplicating stuff that we used to be able to do in 1960", yet he takes the time to explain "tricks" on how to rename variables [1], while modern tools (not necessarily LSP) let you fly through the code [2]. This is just an "old man rants at cloud" take. 1. https://youtu.be/2J-HIh3kXCQ 2. https://youtu.be/AxxN…
The environments we work in shape our biases and what we find good and bad. Game programmers spend their careers writing C++ where, yes, you really need tricks like this to rename the variable, as the language is so fucking insane that ALL tooling gets it wrong - and the consequences of getting it wrong can be disastrous. The most widely used options for C++ are VS's IntelliSense and clangd. IntelliSense is utter gar…
> clangd is better but can still get things wrong if your build process is complicated your compile_commands.json doesn't perfectly reflect it.
Yes, clangd is accurate but when you have different build variants only one is reflected in the current compilation database. clangd will be perfectly accurate for this current variant, but blind to others.
Would clangd support a merge of several compilation DB into one? If a file appears several times with different options (typically include paths and defines), would clangd handle all variants in parallel or just pick one (first or last)? I haven't tried (yet ;).
It's manageable, and sometimes I'm reverting to pure "text level" changes or searches to work around this.
Re: How LSP could have been better
#124The 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…
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…
You might find https://www.jetbrains.com/mps/ interesting. MPS is a sort of AST-oriented IDE.
Re: How LSP could have been better
#125Re: How LSP could have been better
#126I've read a bunch of articles about LSP, and some of the docs, but still not entirely sure what it is. I mean, abstractly I understand, but to truly understand what it's capable of doing and when I might need to use it... Does anyone have any good pointers?
For a more succinct answer, I use it for three things: jumping to the definition of a symbol, auto completion of symbols and keywords and showing documentation. None of this is new. We've had TAGS tables forever. Certain editors would provide the rest for certain languages in language-specific ways. LSP is just a general solution to the any editor/any language problem. It seems to work at least as good and often bett…
> It seems to work at least as good and often better than the custom solutions before.
The standardization that LSP brings is nice, but from a user's point of view it's pretty terrible compared to existing custom solutions. At least for the few languages I tried; Scala and Haskell. The feature set supported was very small compared to what existing integrated editors supported, it was slower and less reliable.
Re: How LSP could have been better
#127Very interesting article and comments!
Re: How LSP could have been better
#128LSP is just Microsoft's EEE[0] into the open source space, as they've done with a number of things (including Typescript and buying GitHub/NPM, WSL, etc). Visual Studio was a meme for a long time because it was so heavy and enterprisey, so to capture more market share they made the cool new shiny version VS Code, and wanted to compete with e.g. Atom whilst still having their grip on the ecosystem as a whole. So LSP w…
What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I…
To be cynical, I guess we're at the "embrace and extend" part; "extinguish" hasn't happened yet, but it could. Microsoft controls the LSP and VS Code is very popular; thus Microsoft has all the leverage in the LSP space. I'm not sure what "going rogue" would look like, on Microsoft's part, but with all the power, it could do so without adversely affecting itself.
Re: How LSP could have been better
#129LSP is just Microsoft's EEE[0] into the open source space, as they've done with a number of things (including Typescript and buying GitHub/NPM, WSL, etc). Visual Studio was a meme for a long time because it was so heavy and enterprisey, so to capture more market share they made the cool new shiny version VS Code, and wanted to compete with e.g. Atom whilst still having their grip on the ecosystem as a whole. So LSP w…
What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I…
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 sense, as GitHub Codespaces and vscode.dev now have features that are difficult to get in competitors. Maybe at some point they will try to Extinguish all local development and push everyone to use a cloud version of VSCode? (See e.g. Python integration in Excel)
The truth is probably a lot more complex, but we can't rule out anything yet.
Re: How LSP could have been better
#130Earlier quoted context omitted.
LSP stands for Language Server Protocol. It's a communication protocol between the clients (text editors, debuggers, source viewers, etc) and the language servers. Typically a language compiler runs over the source files and terminates once it's done. All the compilation states are gone. The language server is the compiler itself running for a long time; its aim is to maintain the compiled states of the source files…
Thanks for the very clear explanation! Where does the language server typically run? Does it run on some remote server or as a separate process next to your editor on your local machine?
Honestly, you should read some of the docs [0] if these are the sorts of questions you're asking.