4 ms·

So I would say rust-analyzer works quite well, while Rust RLS is terrible. However that seems to be a non-LSP issue. The F# ionide plugin also works really well

by carlmr 5y ago

So I would say rust-analyzer works quite well, while Rust RLS is terrible. However that seems to be a non-LSP issue. The F# ionide plugin also works really well, it's also LSP based? Most issues with the VSCode plugins I have is that they don't report errors to the user properly. It's really hard to find out _why_ something is failing. So when everything is configured correctly, the LSP works great. When you have a misconfiguration you need to play detective. Plenty of plugins hang forever, fail silently, or they give you very generic error messages. But this seems to be a VSCode issue.

hsn915 5y ago
The only "LSP" plugins that work well with VSCode in my experience are those developed by Microsoft (likely by the same team that developed VSCode). But even then, not all of them are great. For example, the Python plugin is of questionable quality, but that is probably because Python does not amend itself well to intellisense, even when you add type hints to the picture. > Most issues with the VSCode plugins I have is that they don't report errors to the user properly. It's really hard to find out _why_ something is failing. So when everything is configured correctly, the LSP works great. When you have a misconfiguration you need to play detective. Good observation. This is not just a "feature" of LSPs. It's a feature of all distributed systems developed with the unix mindset. For example, Docker suffers the same problem. Someone gives you a docker image, it works great! For a while. But when something breaks, it really breaks, and it doesn't tell you why. It prints some superfluous error message; one that does not help you understand what's going on.
- carlmr 5y ago
  >It's a feature of all distributed systems developed with the unix mindset. That is also a good observation. It's hard to create a good UX with a system where you don't somehow handle all of the failures of the subsystem in a central manner. My problem here with VSCode is that it often doesn't even expose the failure of the subsystem, essentially not even giving you the information you need to find out the issue. If my corporate proxy fails, the extension store will say "XHR failed", and before it used to just hang forever. But as a user, what is XHR? Why does this hang forever now? There could be many reasons. At least tell me that you had a failure while downloading something.
  - hsn915 5y ago
    > That is also a good observation. It's hard to create a good UX with a system where you don't somehow handle all of the failures of the subsystem in a central manner. It's one of the reasons why the Linux UX will always be subpar. Apple's macOS is based on unix underpinnings, but they take ownership of the whole thing and this is why they can beat it into shape.
- Dayshine 5y ago
  As someone who has worked on two of them (paradox interactive scripting and f#): I think both work well...
matklad 5y ago
> But this seems to be a VSCode issue. That’s a protocol issue! While LSP has a method to report a transient (edge triggered) error, it doesn’t have a way to report a persistent (level triggered) status. And to solve configuration problem, you really want a “status” concept - you need an LSP health indicator which is either red or green, and which you can click on to get info about what the server thinks the project is. There’s no such feature in LSP at the moment. https://github.com/microsoft/language-server-protocol/issues/511#issuecomment-652549272 https://github.com/microsoft/language-server-protocol/issues...
- deleted 5y ago
  [deleted]

by carlmr 5y ago

hsn915 5y ago

The only "LSP" plugins that work well with VSCode in my experience are those developed by Microsoft (likely by the same team that developed VSCode). But even then, not all of them are great. For example, the Python plugin is of questionable quality, but that is probably because Python does not amend itself well to intellisense, even when you add type hints to the picture. > Most issues with the VSCode plugins I have is that they don't report errors to the user properly. It's really hard to find out _why_ something is failing. So when everything is configured correctly, the LSP works great. When you have a misconfiguration you need to play detective. Good observation. This is not just a "feature" of LSPs. It's a feature of all distributed systems developed with the unix mindset. For example, Docker suffers the same problem. Someone gives you a docker image, it works great! For a while. But when something breaks, it really breaks, and it doesn't tell you why. It prints some superfluous error message; one that does not help you understand what's going on.

carlmr 5y ago
>It's a feature of all distributed systems developed with the unix mindset. That is also a good observation. It's hard to create a good UX with a system where you don't somehow handle all of the failures of the subsystem in a central manner. My problem here with VSCode is that it often doesn't even expose the failure of the subsystem, essentially not even giving you the information you need to find out the issue. If my corporate proxy fails, the extension store will say "XHR failed", and before it used to just hang forever. But as a user, what is XHR? Why does this hang forever now? There could be many reasons. At least tell me that you had a failure while downloading something.
- hsn915 5y ago
  > That is also a good observation. It's hard to create a good UX with a system where you don't somehow handle all of the failures of the subsystem in a central manner. It's one of the reasons why the Linux UX will always be subpar. Apple's macOS is based on unix underpinnings, but they take ownership of the whole thing and this is why they can beat it into shape.
Dayshine 5y ago
As someone who has worked on two of them (paradox interactive scripting and f#): I think both work well...

matklad 5y ago

> But this seems to be a VSCode issue. That’s a protocol issue! While LSP has a method to report a transient (edge triggered) error, it doesn’t have a way to report a persistent (level triggered) status. And to solve configuration problem, you really want a “status” concept - you need an LSP health indicator which is either red or green, and which you can click on to get info about what the server thinks the project is. There’s no such feature in LSP at the moment. https://github.com/microsoft/language-server-protocol/issues/511#issuecomment-652549272 https://github.com/microsoft/language-server-protocol/issues...

deleted 5y ago
[deleted]