Live data from Hacker News

How LSP could have been better

matklad.github.io

171–180 of 229 posts

Re: How LSP could have been better

#171
post #114
post #67

Earlier quoted context omitted.

Have you opened an issue against https://github.com/python-lsp/python-lsp-server ? I'm an occasional contributor for easy fixes; if your fix is easy chances are it would get picked up.

Perhaps unrelated but Ive been meaning to ask and I couldn't find - what's the deal with python-lsp-server and virtualenvs? It seems like it has to be installed in the virtualenv to provide completions, etc. Is that right?

[deleted]

Re: How LSP could have been better

#172
post #114
post #67

Earlier quoted context omitted.

Have you opened an issue against https://github.com/python-lsp/python-lsp-server ? I'm an occasional contributor for easy fixes; if your fix is easy chances are it would get picked up.

Perhaps unrelated but Ive been meaning to ask and I couldn't find - what's the deal with python-lsp-server and virtualenvs? It seems like it has to be installed in the virtualenv to provide completions, etc. Is that right?

No. The editor sends information about the environment to the server. That was a mystery to me, too, for a while.

Re: How LSP could have been better

#173

Earlier quoted context omitted.

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…

> I don't want to edit a "file", I want to edit these two functions that exist in some module(s) That shift happened like 20 (?) years ago. That's how Eclipse displays your Java stuff. It goes to a great length to pretend that there aren't files. Instead there are packages. Seeing noobies and experienced programmers struggle with it for years, my conclusion is that this is a bad idea. Most problematically it creates…

I agree with all of this.

I'd only add that well before Eclipse and its ilk, Java started down this path with the deep filesystem paths that made it painful to work with from the filesystem without the kind of multi-level collapsing Github does. It was a choice that pushed people towards seeing the filesystem hierarchy as a nuisance, and laying the groundwork for encouraging people to obscure it in IDEs.

Re: How LSP could have been better

#174

The 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…

That's basically a subset of image-based development, as seen in Smalltalk and Lisp since forever.

Re: How LSP could have been better

#175

I’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

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. It’s not a “native” Mac app, but doesn’t fall into the uncanny valley the way things like VSCode do.

Re: How LSP could have been better

#176

Earlier quoted context omitted.

> 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.

Yeah, I should have added for some languages . For me, Python is better with LSP than it was with Elpy, the custom Python support for Emacs. But it's certainly not going to beat something lime SLIME for Common Lisp and obviously not editing Emacs Lisp within Emacs.

Yeah, I was going to come say something like this. LSP is much better than the status quo for most languages, but SLIME is so much better there's just no comparison.

Re: How LSP could have been better

#177
post #115

LSP 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…

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.

Re: How LSP could have been better

#178
post #113

Wow. There was a tiny typo. I found myself thinking, someone who reasons like this should have a protocol for fixing typos, if they eat their own dog food. I was floored to see the "fix typo" link at the bottom. Submitted. I now wonder if the typo was on purpose.

This is a strange position to take. "Someone who uses logic and reasoning should churn out pristine, flawless work."

You misunderstand me. I am amazed by the author's attention to robust protocol design. No one wants to be "that person" who observes a missing space before an open parenthesis, so usually smoothing out flawless work is not a collaborative process.

I found myself daydreaming how blogs would work if the author turned their brilliant attention to the process of blogging itself. They would solve such a problem, to encourage collaboration.

I was therefore stunned to see a "Fix Typo" link at the bottom. Perhaps this has become widespread, but I'd never noticed it before, and the logic of having this author provide such a link amazed me.

Part of what we do in comments is appreciate various aspects of a work. I was appreciating this aspect of this work.

Re: How LSP could have been better

#179

Earlier quoted context omitted.

people actually like their editor? blasphemy. you must be using either sublime or kakoune

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 a stick, and trying to force myself to migrate to VS Code.

Re: How LSP could have been better

#180

Wow. There was a tiny typo. I found myself thinking, someone who reasons like this should have a protocol for fixing typos, if they eat their own dog food. I was floored to see the "fix typo" link at the bottom. Submitted. I now wonder if the typo was on purpose.

No, I am just spelling-impaired (even in my mother tongue) :)

I was expressing amazement that you took the time to provide a "fix typo" mechanism.

In the real world, many of us would take the time to fix a splinter in a well-traveled floor. I love that your appreciation for robust protocol includes a mechanism for moving the digital world in that direction.

Post reply on HN