| ▲ | _verandaguy 4 hours ago | |
It is a fact that some useful things in the software world are a pain in the ass to learn, and that they could be better on that front. LSP is one of those things, or at least it has been, for a while. LSP is also something that's not necessary to writing quality code; it's absolutely a major quality-of-life boost, but before rewriting my configs after switching to Rust, my LSP usage was limited to being a slightly faster autocomplete engine more than anything. I didn't have keybinds set up for going to definitions, implementations, or references of symbols. I still put out what I think was decent code. I'm also better off now that I've adopted a more useful config. IMO it's an important part of this industry (among others) to let developers have whatever workflow they want, within reason. If someone decides they want to invest the time into setting up LSP with their editor, that's their prerogative. If not, that's fine too. I don't know who among my present or past coworkers use LSP outside of occasionally chatting about editor configs with one or two of them, because they've usually figured out a workflow that lets them produce respectable code, and I've never had to question their tooling before questioning their methodology. | ||
| ▲ | nickelpro 2 hours ago | parent [-] | |
The context is a user adopting an editor that has LSP integration and is relying on the language server. That's why I said "it's a tool you use every single day". If your tool is TextMate, you should learn how TextMate grammars work. If your tool is vi, you should learn how modal editing works. If your tool is Ed, you don't need to learn anything because "Ed is the standard text editor".[1] | ||