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?
How LSP could have been better
171–180 of 229 posts
Re: How LSP could have been better
#172Earlier 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?
Re: How LSP could have been better
#173Earlier 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'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
#174The 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…
Re: How LSP could have been better
#175I’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
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
#176Earlier 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.
Re: How LSP could have been better
#177LSP 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…
Re: How LSP could have been better
#178Wow. 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."
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
#179Earlier 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.…
Re: How LSP could have been better
#180Wow. 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) :)
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.