Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How LSP could have been better

matklad.github.io

Post reply on HN
Print view View original

161–170 of 229 posts

Re: How LSP could have been better

#161

Post by rw-access »

kps wrote: post #159
grumpyprole wrote: post #75

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.

LSP is still (last I checked) missing one nice feature that cscope had 30 years ago: distinguishing between read and write references to a variable. Unfortunately it (as mlcscope) didn't keep up with C++ and ultimately vanished.

That's part of the protocol with a Document highlight request. Basically if you click on a symbol in the client, it'll send the server side request where it can find all references and mark which ones are read and which are write. The client will then highlight those references with one color for read, one for write, and one for other textual occurrences.

https://microsoft.github.io/language-server-protocol/specifi...

Re: How LSP could have been better

#162

Post by rw-access »

ww520 wrote: post #60
bumbledraven wrote: post #25

Jonathan Blow criticized the performance and complexity of LSP in his talk at DevGAMM 2019 titled "Preventing the Collapse of Civilization" (timestamp 42m26s; https://youtu.be/pW-SOdj4Kkk?t=2546 ): > In the programming language world, there's this thing called Language Server Protocol that is pretty much the worst thing I've ever heard of. There are proponents of this all over, building systems for it right now that…

He was wrong on this issue. LSP reduces the MxN problem to Mx1 1xN, i.e. to M+N.

Assuming the MxN claim was accurate, yeah. The author of this post wrote a prior one [1], challenging whether MxN was truly the problem LSP was solving. It's also a good read!

https://matklad.github.io/2022/04/25/why-lsp.html

Re: How LSP could have been better

#163

Post by TacticalCoder »

duped wrote: post #47
kstrauser wrote: post #33

Earlier quoted context omitted.

That’s exactly the kind of thing LSP deals with. You have to get those settings into the server somehow, and the main methods are for the editor to send them to the server, or for the server to load them from somewhere in the filesystem or similar. A lot of those settings (like line length) are configured in the editor by the user. It makes a lot more sense to have a mechanism to communicate them over the same protoc…

LSP is a protocol for answering queries about the language model behind the text, not controlling anything about the text itself (expect for auto formatting, but that's a bit special). Those configurations seem to be in scope for the text editor, not the language server. In fact LSP is mostly configuration agnostic. It might use configuration for a particular query like autoformatting, but it's still request/response…

> LSP is a protocol for answering queries about the language model behind the text, not controlling anything about the text itself (expect for auto formatting, but that's a bit special)

LSP supports refactoring with "Code Action Request":

https://microsoft.github.io/language-server-protocol/specifi...

That's more than simply answering queries about the model.

Re: How LSP could have been better

#164

Post by __MatrixMan__ »

globular-toast wrote: post #87
akhosravian wrote: post #64

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 suppose there must be some data in the serialized program which marks the start and end of a function body. But rather than having the semantics of that marker be:

> This is indentation whitespace, display it how you like

It should be

> This is a function body, display it how you like

Not only should readers be able to differ about how much whitespace is shown. They should be able to differ about whether it's whitespace that is used at all. Maybe they want something crazy like it makes a different kind if sound when you look at it, or appears in a different color or font. Whatever it is, it's no business of whoever is writing the program--they ought to be able to have an entirely different experience while still kicking out the same program.

Re: How LSP could have been better

#165

Post by pawelmurias »

fiddlerwoaroof wrote: post #86
zarzavat wrote: post #71

Earlier quoted context omitted.

> I want the editor to look at temporary buffers served up from the language server and have the code be “written” by sending the temporary buffer back to the language server which handles writing it out to files itself. I don’t think any editor would want to accept this workflow. The biggest issue is that writing is reputation-critical, if the editor writes to the wrong place, or it fails to write when it should hav…

I want a system more like Bank Python[1] or Unison[2] or Pharo Smalltalk[3] that gets us beyond the idea of "code in files". And I have plans to build this on top of Common Lisp + SLIME [1]: https://calpaterson.com/bank-python.html [2]: https://www.unison-lang.org [3]: https://pharo.org

Loads of people absolutely hate having to use a weird custom IDE just to try a language. That's why all the smalltalk like things are doomed for failure unless they are enforced by a platform.

Re: How LSP could have been better

#166

Post by layer8 »

chrismorgan wrote: post #151
layer8 wrote: post #148

Earlier quoted context omitted.

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.

Because if the server and client both use UTF-8 internally, they can get better performance by agreeing to use UTF-8.

The question is if the performance gains are noticeable enough to warrant the added implementation complexity and the added integration testing needed. It seems doubtful to me, given the general protocol overhead.

Re: How LSP could have been better

#167

Post by NoGravitas »

jhoechtl wrote: post #81
raincole wrote: 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 wonder if this is still the case as most comments petered out end of March. There was a nasty bug discovered in Emacs JSONRPC-Library, which did cause spurious LSP connect errors and likely other issues in LSP server communication https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8bf4c... Do note that many users might have not been aware of this issue. The fixed library is part of Emacs 29. If you are not on E…

Personally, I have never seen this desynchronization issue between eglot and corfu. I suspect it somewhat depends on the particular LSP server, and I only really heavily use eglot for C# (OmniSharp).

Re: How LSP could have been better

#169

Post by vidarh »

BaculumMeumEst wrote: post #144
gilcot wrote: post #141

Earlier quoted context omitted.

supreme blasphemy. Emacs

you just have a call to (stockholm-syndrome) buried somewhere in your 1200 line init file

The amount of Emacs configuration I had was what drove me to the insanity of writing my own editor....

Re: How LSP could have been better

#170

Post by NoGravitas »

b5n wrote: post #40
raincole wrote: 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'm curious to know what `company` does differently here than `corfu`. As a longtime user I couldn't be happier: https://company-mode.github.io/

It appears to be a cache-busting issue, if I understand the bug discussion correctly. company-capf always busts the completion-in-region cache, corfu never does unless you wrap your completion function in a cache-buster function.
Post reply on HN