Live data from Hacker News

LazyVim

lazyvim.org

341–350 of 537 posts

Re: LazyVim

#341
post #78

I've been using vim for years, switched to neovim, and at this point I'm ready to throw in the towel and just use vscode for anything beyond simple text editing. The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to sp…

> I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert.

Personally I've started paying for intellij and using it with it's vim emulation. I know it doesn't solve the problem of being clunky on older laptops, but it is an amazing experience to use. I get the best of both worlds, I get really good vim emulation so I don't have to relearn editor shortcuts, I get the benefits of a modern full fledged IDE with many useful features that work out of the box with basically 0 configuration (debugger, git, tasks, etc.)

Re: LazyVim

#342

Earlier quoted context omitted.

Setting up vim with IDE features takes an hour maximum + 2 minutes per additional language. If that is too much for you, you could have used any of the various vim/nvim distributions with the features already there. You could have even used Doom Emacs with vim keys . If you don't want to use vim, I do not mind whatsoever, but if you put in a bit of effort the solution to your problems would appear.

That's simply not the case because you will, very quickly, run into problems. One example I had with vim recently was that two different plugins both tried to format the same code and actually send each other into some sort of hell loop and crashed vim entirely because they called something in a circular fashion. That's absolutely representative of the kind of errors vim and neovim configurations have, because it's a…

You’re absolutely right that this can happen, but wrong that it is representative. Let’s take all the serious vim users in the world. How many have this kind of plugin hell experience? A tiny percentage.

Serious vim users don’t try to create a kitchen sink IDE. They start with a vanilla base and with their way up, including just the features that are important to them.

Starting with something like LazyVim is fine too. Then you get a rich set of plugins that have been configured for you. Lovely! And now just be thoughtful about what you later on top.

Re: LazyVim

#343
post #78

I've been using vim for years, switched to neovim, and at this point I'm ready to throw in the towel and just use vscode for anything beyond simple text editing. The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to sp…

I use vim for years, too but also I keep my .vimrc and, more recently, .vim in a git repo (using bare repos for dot files discussed here: https://www.atlassian.com/git/tutorials/dotfiles). So, getting a functional environment on a new system is close to running `git pull` once.

I don’t update plugins too often, because they work, but I also don’t use too many. Based on my git history, I last updated a vim plug-in 11 months ago.

Re: LazyVim

#344
post #266

Earlier quoted context omitted.

I do roughly this too, except my vimrc is about 8 lines. I type it out from memory every time I use a new machine.

Would you mind sharing it? Im just getting to grips with vim so any pointers towards some simple improvements would be much appreciated.

Take a look at the vim-sensible plugin. No need to install it, just see what the generally agreed sensible settings are.

Re: LazyVim

#345
post #321

Earlier quoted context omitted.

As if there are "studies" backing the claim that arrow keys are easier to use for navigation than the home row keys... Personally I don't want to move my hands from where I'm writing to the other side of they keyboard just to move the cursor.

I take it you've never played a fast game with keyboard controls? :-) They could have laid out the arrow keys WASD style. One up, one mid-down, two to the sides. Nobody said they had to use dedicated arrow keys. Just lay them out like a normal human being. Whatever key for up should be up, whatever key for down should be down, whatever key for left should be to the left, whatever key for right should be to the right.…

In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perform linewise vertical motions (compared to a standard WASD "grip"). Navigating within a line using left and right is uncommon when using vi bindings, since there are usually better ways to jump between locations within a line, so it makes more sense to pay the cost of having to move your fingers in this case.

Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.).

As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better.

That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.

Re: LazyVim

#346
post #160

Earlier quoted context omitted.

I'm playing into the joke here, but on most terminals, alt + will actually be sent to the program as + key. You can use this to avoid pressing escape in Neovim.

Interesting tip too! Need to find the right combination however, I noticed that Alt-L might be a good one (no side effect it seems).

That will move your cursor to the right by one character after exiting insert mode.

Re: LazyVim

#347

Earlier quoted context omitted.

Setting up vim with IDE features takes an hour maximum + 2 minutes per additional language. If that is too much for you, you could have used any of the various vim/nvim distributions with the features already there. You could have even used Doom Emacs with vim keys . If you don't want to use vim, I do not mind whatsoever, but if you put in a bit of effort the solution to your problems would appear.

Sure, it's one hour if you did that already 20 times and you know the ecosystem. An hour is barely enough to go through the vimtutor which itself is pretty basic (aka you won't get far with it, so you need to keep learning and practicing). If you are a vim newbie, it takes a lot of time to figure out you need plugins, then figure out how to install plugins, then what's the difference between plugin installers, findin…

I am not talking about learning vim. Of course, that is a huge time investment and you have to make your own judgement if that is worth it (for me it absolutely was, but I was in University with few obligations and lots of time).

I am talking purely about going from a vim without IDE-like tooling to one including it. That can be done in an hour.

Re: LazyVim

#348
post #156
post #78

I've been using vim for years, switched to neovim, and at this point I'm ready to throw in the towel and just use vscode for anything beyond simple text editing. The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to sp…

>The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to spend precious hours fixing obscure issues in Lu Can't agree with this at all. I don't think I've spent more than an hour in total setting up my vim config back in…

I’ve plugging away at NeoVim in my spare time trying to get it working and it took me a weeks before I just gave up and directly ripped someone else’s LazyVim config to finally get things working in a state I’m happy with.

Never mind that in order to get modern syntax highlighting and code completion you need LSP-Server, Mason, and Null-ls. The first which has per language dependencies and the 3rd is about to be archived.

Also I don’t know what world you live in but a tool a verbose and powerful as NeoVim you can spend hours just reading the documentation and getting a handle on the basics let alone configuring things to your liking

Re: LazyVim

#349
post #78

I've been using vim for years, switched to neovim, and at this point I'm ready to throw in the towel and just use vscode for anything beyond simple text editing. The amount of work needed to get a basic IDE up and running for your languages of choice, even for commonly used languages such as Python or Javascript, is far too much for someone who wants to get on with their day job or hobby coding and doesn't want to sp…

> I don't particularly like vscode. It's heavy and slow and janky, particularly on older laptops. I don't like being sucked back into the Microsoft ecosystem after spending years getting away from it. But ultimately, I want to just get on with my job, and my job is not Lua Developer or Neovim Plugin Expert. Personally I've started paying for intellij and using it with it's vim emulation. I know it doesn't solve the p…

Same. I like it better than the vscode vim emulation, which is more “strict” and turns to the visual mode when selecting anything with the cursor. Which I personally think is the worse part of vim.

Re: LazyVim

#350
post #239

Earlier quoted context omitted.

> I agree that neovim is not for people who are not interested in learning their tools. That, right there, is one of the biggest turnoffs I have encountered from the community. The sheer disdain in that sentence alone. I learn many tools, and am deeply interested in learning them. That includes languages, frameworks, databases, infrastructure tools, operating systems, standards and protocols. I wouldn't be in this jo…

> The sheer disdain in that sentence alone. I'm sorry that you read it this way, I think I could have written it differently. That being said, I don't agree that any of the things you listed are tools. Moreover, reading what you wrote in your original comment from a more negative stance, I also think it's easy to read it as disdainful but I chose not to read it that way. I would appreciate it if you were more positiv…

> Again, I would like to stress, I am not trying to make any objective claims as to how correct your approach is. I am simply observing that there seem to be broadly two categories of programmers. Those who feel like investing time in learning and writing/modifying "tooling" is worthwhile and those who do not. I feel like you fall into the latter category.

I use zsh, with customizations. I know git, and mercurial, and a few other VCS I've forgotten. I know my way around the Linux toolkit. I can configure a Python or frontend or Go environment with whatever linters and formatters and pre-commit and so on and so on. I have a fat repo of dotfiles. Hell, I use vim whenever I need to work on headless servers or the odd config file and the like. Works fine, in that use case.

Every time I learn or modify a tool, I look at whether there is a net benefit in learning it, whether it makes me more productive. Zsh shortcuts for example are tiny, but I get a nice little productivity boost that adds up to many hours over time.

I have spent the hours learning and configuring neovim, but run up against that point where that time spent is no longer yielding that benefit, compared to just using vscode and putting up with its issues.

So, I chose one tool over another. But it's a generalization to say I somehow don't think learning "tooling" is worthwhile.

Post reply on HN