Hacker News Reader

I'm not sure your implication of LSPs existing, specifically for vim, or in general, for 20 years is actually true in order that your questioning of Julia's skills to actually make sense.

As a similar example, I could never be bothered to install and configure any LSPs even though I've been using vim for more than a decade. The friction of doing that was always just a little bit higher than installing a full blown IDE when the work actually requires high level LSP functionality.

ar_lan specifically mentioned Neovim distributions. Examples would be LazyVim and AstroNvim. These are packages you can install that provide Neovim in a pre-configured and opinionated way. They generally come with language servers, linting, and various other features out of the box, and have their own paradigms for configuration.

They can be easier to get started with than just installing Neovim from scratch. But they add their own complexities. First, you have to know that they exist, and pick one. Then you have to know how to configure them, they may have their own nuances about how things are done. Under the hood they're using all the same packages, so you'll need to learn how to configure those as well if you don't want the defaults.

I would say the distributions to make it extremely easy to get started with a functional IDE experience with LSP features. But they're not without their own learning curve.

The problem is that I must make these distributions fit within my well established configuration, which is not as easy as installing them on top of a blank one.

Also it might be the fact that vim was never my main programming tool when IDEs were available for the programming task at hand. I debug as much as I write code, so having the debugger in the same context is important to me.

These things may all sound like excuses, but what I'm trying to convey is that vim can be a tool with which someone is proficient, but it's not the main one for writing code, and as soon as friction gets higher, it gets disregarded in favour of something else.

I think you're using asterisk, maybe *vim, and it's italicizing your text until the next *vim. You'd have to escape it with backslash.

I'm trying to be careful to distinguish that this particular part seems odd to me, specifically because of Julia's other posts in which it seems their skill/knowledge is not much of a question.

If someone is new to vim, I 100% agree that it's easier to get started with VSCode/Jetbrains/etc.

But if someone has been using vim for a long time as their default editor, especially Neovim, and when LSP support came to Neovim about 4 years ago [0], it comes across as someone who isn't a power user if they didn't end up installing it. Which is fine, but the community has also started to build reasonable "batteries-included" distributions of Neovim (LunarVim is a great example) if someone didn't want to figure it out themselves but still wanted to use it.

It's one thing if someone just doesn't love the experience Neovim brings to them. That's reasonable, because it's subjective. But it is odd to use a tool for so long and not further investigate what it offers to fit your needs. Before LSP, there were libraries (CoC for example). And if it was never satisfactory, why not look at alternative editors which had their own flavors of indexing/code navigation?

--

[0]: (https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...)

Also been doing vim and now neovim for 20+ years. LSP just broke and several keybinds alongside it and just not looking forward to figuring out what happened (but will anyway). It's a huge mental block for me whenever I need to get into configuration. So to me this feels very relatable.

That is surprising. I didn't have much trouble getting LSP working either in og or neovim. My editor config is fairly barebones by preference, so its not like I spend a lot of time editing my configs either. I will say, Lua is a lot more ergonimic than vimscript for a lot of things, but I appreciate that I can still use the old ways at times. Like ALE isn't leaving my config unless I'm forced to remove it for some reason.

I hope they're happy using helix tho

I use a plugin[0] for LSP in vim and it's pretty easy to setup there too. Installing and configuring the lsp software itself take more time as I'm constantly moving between OS.

Also, Emacs and Vim is very much about making the tool your own. I don't mind shaving the yak every now and then, because once an inconvenience is solved, it stay solved.

[0]: https://github.com/prabirshrestha/vim-lsp

I've never used a distribution and LSPs are in my opinion easy to setup in Neovim and especially now with vim.lsp[0].

[0]: https://neovim.io/doc/user/lsp.html

Totally weird. LSP has been a neovim builtin for how long now? Two years?

4 years. https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...

I've noticed a number of moderately sized companies "standardizing" on vscode tooling. You can use other editors, but they'll have extra special support for vscode: default project format settings or special tooling for debug integration specifically in the form of vscode config, that sort of thing. Recommended plugin sets.

I also took pause at the claim that LSP was the issue. Neovim + treesitter + LSP feels... fairly solved at this point? It was definitely a bit rough 5 years ago, but it's pretty smoothed out now. Not sure where that opinion is coming from (and it feels at odds with everything else I've read from jvns, to be honest!)

When I worked with programming students we used VScode despite me, the professor, and most of the other grad students not liking it. It’s just so easy to download, has the “run” button, and, well, at least it isn’t Eclipse I guess.

Vim is better of course it’s just hopeless to get people to use it.

I think with Cursor choosing it as well, this will only continue to prevail. Professionally I've had to standardize on VSCode due to Cursor (there are a few plugins for Neovim but the experience is undoubtedly better in the first-class tool).

By the way - I actually generally think this is a good thing that companies standardize on something. I might not like the choice they standardize on, but the barrier to entry for new engineers is already high, so having an easy-to-use and familiar development setup that "just works" from the start is pretty reasonable for large companies.