Live data from Hacker News

How LSP could have been better

matklad.github.io

181–190 of 229 posts

Re: How LSP could have been better

#181
post #15

One thing that has annoyed me with some personal implementation work is why does DAP use a cosmetically similar but not following spec version of JSONRPC? Why not just use JSONRPC especially considering LSP already does?

This post explains the reasons https://github.com/microsoft/vscode-debugadapter-node/issues...

Re: How LSP could have been better

#182

Earlier quoted context omitted.

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…

The features of LSP are exactly the features of VS Code. So if you create a different editor, it will only support what VS Code does. (Unless you put in per-language effort like the olden days). If you create an LSP, it will work best in VS Code. As well, Microsoft is building a wealth of VS Code-only features and LSPs (locking out VSCodium), by the end, they will have taken from open source and not given anything ba…

> The features of LSP are exactly the features of VS Code. So if you create a different editor, it will only support what VS Code does.

This is not true since LSPs can add extensions to the existing API. For example: https://github.com/rust-lang/rust-analyzer/blob/master/docs/...

> If you create an LSP, it will work best in VS Code.

Any editor can work just as well as (or even better than) VS Code.

Re: How LSP could have been better

#183

Earlier quoted context omitted.

Tabs vs spaces has been a viewer setting for decades for tab users.

Exactly! A tab is literally "1 level of indentation". You can render that one level any way you like. Unfortunately, though, everyone who has used tabs got bitten by stupid text editors that don't make it obvious whether you've used a tab or a space and substitute a tab for any run of 8 spaces. So if you're aligning an argument list you'll get a mixture of tabs and spaces. Everyone got bitten by this once back in the…

I don't understand the appeal of pretty alignment of arguments with the last character of the function name in the row above. What's wrong with just using one more standard indentation level, like Black does in Python?

Re: How LSP could have been better

#184

Earlier quoted context omitted.

I do! The one here is BBEdit which you can extend by writing - ready for this? - command line programs. It didn’t come with a built-in JavaScript formatted, so I wrote a shell script that runs Prettier on its input, and told BBEdit to run that script when I hit F1. Voila. JavaScript formatting. It’s also incredibly fast and responsive. If I can’t get it working to write Python the way I want, I’m going back to Emacs.…

I've been down that path with both Acme and Kakoune, although I went with separate formatting scripts based on whatever seemed to work best for each language. But I started to go a little insane trying to extend those editors, because I realized that I hate working with the shell and prefer to avoid working with it at all cost. And so back to Emacs I went. And now I oscillate between repeatedly poking my config with…

I switched from Emacs to VSCode for a while, but couldn’t stick with it. It’s soooo easy to set up and start using, and it does the right thing 99% of the time. However, that 1% drove me nuts. I don’t remember the specifics, just that there were a few things that bugged the everliving hell out of me, and they couldn’t be changed without doing some significant work inside VSCode itself and then in its extensions.

The worst thing about Emacs is how it absolutely spoils everything else. Yes, it’s a pain in the neck at times, but you can change anything you want.

That said, BBEdit got far closer to my platonic ideal editor than VSCode ever did, and it’s nice enough in other ways to win me over.

Re: How LSP could have been better

#185
post #136
post #83

Earlier quoted context omitted.

Wait, does that feature mean what is sounds like? That sounds too basic to be fundamentally beyond LSP.

Yeah, it sounds like it should support it. Traditionally though OCaml editor integrations have also supported not only asking just the type of a symbol, but of an expression. I wonder if LSP can do that, because that function needs some interactive scoping of the query, not just a single point, or I suppose it can work if hovering over parenthesis but if precedency needs to be accounted for, it would be difficult to…

That's doable in LSP - the server knows about the selection, not just the cursor position. E.g. if I use rust-analyzer (in Helix, so there aren't any protocol extension in play), select an expression and request hover info, rust-analyzer shows the expression's type.

Re: How LSP could have been better

#186
post #7

Recently I stumbled upon this issue: https://github.com/joaotavora/eglot/discussions/1127 I don't know enough about emacs and LSP to see the full picture, but it seems that both eglot's and corfu's maintainers, assumably very competent programmers, can't find a solution for this. I only skimmed the thread. My understanding is that LSP dumps a long list of completion candidates at once and they can't decide a cache st…

I read the almost the whole thread and it does not seem to be an LSP issue. As far as I can tell, the issue is purely corfu and eglot disagreeing about the semantics of internal emacs completion hooks they use to communicate and whether corfu should cache on its side or should rely on eglot. Company does not have this impedance mismatch with elgot so it works fine.

There are actually two separate issues in the thread:

1. The issue you identified which is about caching. It seems you can work around this issue by using a cache busting hook from cape.

2. An unsolved issue where eglot and LSP get out of sync which seems strongly correlated with using corfu. I've been experiencing this a lot with eglot+corfu+rust-analyzer. I'd estimate about once per hour I'll notice that things are just wrong, as in red underlines in nonsense places with nonsense error messages and completion no longer working or working incorrectly. Running a M-x eglot-reconnect "solves" the issue for another ~1 hour.

The way these two issues were related is the author of eglot states that they have sunk considerable time investigating issue #2 with no success, and they argue that it is not worth their limited time to continue investigating #2 when corfu is broken by design[^] w.r.t. #1.

And yes, I'd agree that this doesn't seem to be an LSP issue but rather an issue solely on the client side.

[^] https://github.com/joaotavora/eglot/discussions/1127#discuss...

Re: How LSP could have been better

#187

Earlier quoted context omitted.

I've been down that path with both Acme and Kakoune, although I went with separate formatting scripts based on whatever seemed to work best for each language. But I started to go a little insane trying to extend those editors, because I realized that I hate working with the shell and prefer to avoid working with it at all cost. And so back to Emacs I went. And now I oscillate between repeatedly poking my config with…

I switched from Emacs to VSCode for a while, but couldn’t stick with it. It’s soooo easy to set up and start using, and it does the right thing 99% of the time. However, that 1% drove me nuts. I don’t remember the specifics, just that there were a few things that bugged the everliving hell out of me, and they couldn’t be changed without doing some significant work inside VSCode itself and then in its extensions. The…

Haha, yes, virtually all of that has been my experience as well, except substituting BBEdit for Sublime. I'm still convinced that just sucking it up and sticking with VS Code is the way to go, I just can't make it stick.

But Emacs is still alluring enough that I spent like 4 hours over the last few days trying to get clangd to work in a project that involves cross compiling C++ in a way where generating compile_commands.json does not seem possible, with no success, even with the help of clangd contributors, where VS code somehow is able to just work with minimal configuration of the C/C++ extension. Someday I will stop doing this to myself, hopefully.

Re: How LSP could have been better

#188

Earlier quoted context omitted.

Tabs vs spaces has been a viewer setting for decades for tab users.

Exactly! A tab is literally "1 level of indentation". You can render that one level any way you like. Unfortunately, though, everyone who has used tabs got bitten by stupid text editors that don't make it obvious whether you've used a tab or a space and substitute a tab for any run of 8 spaces. So if you're aligning an argument list you'll get a mixture of tabs and spaces. Everyone got bitten by this once back in the…

Elastic tab stops would be the Right Thing if they were implemented anywhere at all https://nickgravgaard.com/elastic-tabstops/

Re: How LSP could have been better

#189

Earlier quoted context omitted.

Exactly! A tab is literally "1 level of indentation". You can render that one level any way you like. Unfortunately, though, everyone who has used tabs got bitten by stupid text editors that don't make it obvious whether you've used a tab or a space and substitute a tab for any run of 8 spaces. So if you're aligning an argument list you'll get a mixture of tabs and spaces. Everyone got bitten by this once back in the…

I don't understand the appeal of pretty alignment of arguments with the last character of the function name in the row above. What's wrong with just using one more standard indentation level, like Black does in Python?

Black uses more lines. PEP-8 is generally more compact.

I'm more than happy to let something like Black handle formatting for me, though. Sure, there are some occasions where my own formatting would have been better, but the benefits far outweigh the (very small) costs here.

The silly thing is with tools like Black etc. it should be possible to use tabs again. If the only reason against tabs is people fuck it up, there's really no reason to use spaces in an auto-formatted project.

Re: How LSP could have been better

#190

Earlier quoted context omitted.

You can say a lot about Microsoft the company. You can even take digs at Visual Studio Code and its "telemetry reporting". But LSP is one of the best things that's come out of that whole ordeal. It's far from perfect. But as a Vim user, we've had nothing this good until now. I used TernJS for JavaScript and some other handy plugins for other language specific stuff... and it was such a pain. LSP made things far more…

I agree. I primarily use(d) Emacs, and while it’s had good support for certain languages for decades, now it handles younger languages like TypeScript and Rust exactly as well as Microsoft’s editors do. That’s freaking magical.

Microsoft does not use LSP for its own language TypeScript. They have something that works better for VSCode: tsserver. When TypeScript evolves, Microsoft updates tsserver and VSCode as needed. To get the updates to Emacs, someone needs to make the respective changes to a third-party TypeScript LSP first. And it won't work as well because LSP isn't as good.
Post reply on HN