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

Learn Vim (2021)

github.com

Post reply on HN
Print view View original

181–190 of 215 posts

Re: Learn Vim (2021)

#181

Post by cbushko »

kzrdude wrote: post #137
cbushko wrote: post #23

I've re-built my neovim config like 3 times this year as I have played with several 'distributions' and styles. SpaceVim, LunarVim, AstroVim, and NVChad to name a few. This last weekend I gave LazyVim a try and it is by far the most sane config setup I have used and I will now be sticking with it. There is a starter repo where you clone it, delete the .git directory and start customizing. https://github.com/LazyVim/L…

Could you elaborate, why is LazyVim more sane? It too seems to require understanding a lot about their organization of configuration. (It doesn't help that I'm still not migrated from Vim to Neovim and lua, because I just didn't find a neovim configuration that was better than what I have.)

There are a couple things:

- Most distros seem to like wrapping functionality and having you use their own convenience functions to get things done. For example, for AstroVim, astrovim. is all over their config files. This is fine if you were a distro developer and you were trying to make things easy for yourself but I do not find it easier for the user when neovim already has simple lua based functions. It is another barrier to entry as you have to learn how the distro authors put things together. - The config for LazyVim is will thought out. For example, it has 2 directories: /config & /plugins. That makes it simple to figure out where things should go. keymaps go in keymaps.lua, options go in options.lua... it kind of makes sense. - The plugin config for disabling a builtin plugin is the same as where you would configure your own plugins. It is literally:

  return {
    { "github/plugin.nvim", enabled = false },
  }
vs

  return {
    { "github/myplugin.nvim", {config here if you want}},
  }
- There are no weird plugin loaders and most examples you see from plugin authors are copy/paste into that bracket section. - The LazyVim website is decent. Not perfect though. https://www.lazyvim.org/ - The starter is a great place to start your setup. https://github.com/LazyVim/starter - The plugin manager, lazy.nvim, seems to be a lot simpler and well thought out compared to others plugin managers (like packer). It has autoloading, caching, a UI, etc. - Folke, the distro creator, has written many popular plugins and knows quite a bit when it comes to configuring plugins. That seems to be paying off in the design.

To be fair, there are some design decisions that I don't agree with when it comes to the LazyVim layout itself. Putting everything in editor.lua or ui.lua instead of per-plugin config is not how I would have done it. It was pretty easy to figure out where the plugin settings were though because they match the categories on the website.

Note: I mainly switched to Neovim as I am find that there just seems to be much more development in the ecosystem and the number of amazing plugins coming out is staggering.

Re: Learn Vim (2021)

#182

Post by grimgrin »

imiric wrote: post #95
pugworthy wrote: post #77

It's kind of weird to read about "learning" VIM, at least from someone who's been using it (er VI) for 40 years. It's nuts, but if asked, I don't even know how to do certain things in VI; I just do them. Ask me what keys to press to go up, or down, or right or left? I dunno - I just do it. Yea it's nuts. It's like baby duckling bonding - the first editor mindset (aka EMACS vs VI) you use, you just bond to and it just…

Slight tangent, but what's with the capitalization of VI and VIM? You surely know those are not acronyms, yet I've seen VIM miscapitalized many times, even by experienced users, and it's always slightly irritating. EMACS, while historically accurate, also isn't common anymore.

The very first sentence of wikipedia: "Vim (/vɪm/;[5] a contraction of Vi IMproved)"

I see a way to get "VIM" out of that.

Though it looks like originally, in 1993, you'd have read: "Vi IMitation":

https://groups.google.com/g/comp.sources.misc/c/Q34bWDtDIM8

Re: Learn Vim (2021)

#183

Post by MrJohz »

btschaegg wrote: post #163
dmitriid wrote: post #161

Earlier quoted context omitted.

> But I've had enough of these conversations that I can assure you that this low a bar is needed for some people to skip important jobs. If your doubt applies to the usefulness of knowing the system No. My doubt extends to "omg vim is so amazing that these tedious tasks take seconds unlike in these primitive text editors". Because my experience at work has been consistently the exact opposite: vim users routinely tak…

Well, I'm not really sure if we're talking about the same thing. If you're talking about language integration, I've got no quarrel with that (see my earlier comment). The experiences I was referring to are more along the lines of text manipulation in general, not "rename class", "extract method" and the like. If you're talking about features like that, I'd readily agree with you: Trying to do the same thing with Vim…

I get what you mean, but "minute-to-minute text handling" for me is pretty much always covered by my IDE's refactoring integration. Like, in the last few weeks, I've written a whole load of Python, Rust, and Typescript, where the IDE covers pretty much all my needs, and then maybe in total a day or so of fiddling with Dockerfiles and config files? None of which were really long enough or complicated enough that I needed anything complicated in terms of editing techniques, most of my time was spent waiting for builds to run and then trying something else out.

So yeah, you're probably right that Vim techniques are far better when you're editing those sorts of files, but those really do make up the tiniest fraction of my time, and everything else is covered by IDE refactoring tools. And if I had the choice, I would always rather have the better IDE tooling than the improved text editing, so this doesn't really sell me on the whole thing.

I would like to try Vim-mode for VSCode at some point, because I can imagine that being a kind of "best of both worlds" thing, but I've not really got round to it yet.

Re: Learn Vim (2021)

#184

Post by vdm »

cess11 wrote: post #100
bee_rider wrote: post #65

I dunno, I never sat down to learn vim, just used it every day for a couple years. I’m not one of those wizards who is, like, answering stack overflow questions or writing wiki articles, but I get the job done. Is it necessary to learn Vim? Seems like a chore. Is the text editor really a bottleneck for anyone? I find that no matter how slow I type, I need to spend more time thinking of what to type anyway, if I’m doi…

What vim can do that emacs often is a little too slow for and IDE:s can't is to have finished even quite complicated incisions and changes to your text before you've become conscious that you asked it to do the thing. This means it can help keep out intrusions about editor maneuvering from your mind at work. Some people see no value to this and fill their vim bundle with plugins that slow everything down a lot, but s…

you had me at

> 'ok, understand but Ide competent, knows many things, need more info before can do the thing'

Re: Learn Vim (2021)

#185

Post by kzrdude »

cbushko wrote: post #181
kzrdude wrote: post #137

Earlier quoted context omitted.

Could you elaborate, why is LazyVim more sane? It too seems to require understanding a lot about their organization of configuration. (It doesn't help that I'm still not migrated from Vim to Neovim and lua, because I just didn't find a neovim configuration that was better than what I have.)

There are a couple things: - Most distros seem to like wrapping functionality and having you use their own convenience functions to get things done. For example, for AstroVim, astrovim. is all over their config files. This is fine if you were a distro developer and you were trying to make things easy for yourself but I do not find it easier for the user when neovim already has simple lua based functions. It is anothe…

Thanks a lot. Maybe I'm starting to see what you are talking about. I have setup a working (?) lazyvim. Let's see where it goes. Some frustrations had to be overcome, most of them turning off unwanted functionality like autopairing parantheses, for example.. The custom notifications/popups also had to be disabled for now since they have some problems (cursor vanishes in light terminal? Important command outputs are only visible for a few seconds?).

Re: Learn Vim (2021)

#186

Post by bobbyskelton41 »

noloblo wrote: post #145
jalino23 wrote: post #28

Earlier quoted context omitted.

https://github.com/helix-editor/helix is the answer mate

What are the design goals of helix other than neovim in rust without all the original vi/neovim key bindings sans extension interface b

https://github.com/helix-editor/helix/blob/master/docs/visio...

Re: Learn Vim (2021)

#187

Post by mcluck »

endorphine wrote: post #169
mcluck wrote: post #112

Earlier quoted context omitted.

I'm definitely not a vim master but I've made an active choice to avoid 4j style movement. The main benefit of vim, for me, is the mind-body connection. Commands are either muscle memory or like saying a short phrase in my head so it flows out naturally. Counting lines before executing breaks that natural flow

What if you use relative line numbers though?

That could help and I have experimented with relative line numbers but have decided against it. I want to see absolute line numbers for matching up error messages and I find it's easier to communicate in absolute line numbers when doing code reviews or pair programming

Re: Learn Vim (2021)

#188

Post by femto113 »

fbarred wrote: post #128
femto113 wrote: post #15

Earlier quoted context omitted.

Setup how? I've used vi/vim daily as my main editor for the past 35 years or so, over that time I doubt I've put more than 20 total hours into its setup. I've been using some evolution of the same .vimrc for decades and it's only accumulated a couple dozen lines. The longest setup task I can remember was a few years ago getting MacVim to launch with one window per folder (with files as tabs, in most cases that equate…

20 hours??? Your comment makes it sound like you think it's a small amount? I get that it's over 35 years, but still!

It's a tiny amount--I'm guessing I've probably easily logged 20,000 hours of active use in vi by this point, I can't think of any other tool I use regularly that has a better time-of-use/time-of-setup ratio. Compared to the time I've spent, say, installing Ruby gems and fixing dependency conflicts it's a rounding error, and Ruby's only been a focus for a small fraction of my career. To clarify that wasn't ever one 20 hour chunk, that's a rough guess at the total time spent setting it up on dozens of different computers across many different operating systems and window managers. It's typically well under an hour of setup per computer, and much of that time goes towards remembering where to find installers, picking fonts, etc.

Re: Learn Vim (2021)

#189

Post by pynappo »

julesnp wrote: post #166
cess11 wrote: post #100

Earlier quoted context omitted.

What vim can do that emacs often is a little too slow for and IDE:s can't is to have finished even quite complicated incisions and changes to your text before you've become conscious that you asked it to do the thing. This means it can help keep out intrusions about editor maneuvering from your mind at work. Some people see no value to this and fill their vim bundle with plugins that slow everything down a lot, but s…

If you already have Caps Lock remapped to Control, why not just use Ctrl-[ to get back to normal mode? Ctrl-[ is the same keycode as escape in terminals, and it's much easier to reach. For me, remapping jk in insert mode results in lag after typing 'j'.

This issue is only cosmetic as the other commenter explained. vim won't insert the character until you indicate you're not invoking the keymap (either by waiting or by typing other characters).

If you want a plugin that makes it so that the j appears immediately regardless of whether you're trying to invoke the keymap or not, you can use something like https://github.com/nvim-zh/better-escape.vim

Re: Learn Vim (2021)

#190

Post by schemathings »

mcluck wrote: post #112
endorphine wrote: post #96

I'm using vim for 10 years and I know I have a lot of "bad" habits that I'm trying to eliminate, but it's hard. For example: 1. instead of doing 4j I might do jjjj 2. if I'm in the middle of a word and want to change it, I'll do bcw instead if ciw 3. if I want to copy 3 lines, I'll do Shift-V+jjj+ESC, instead of just 3yy 4. (possibly other 100 items here...) But I find it very hard to change those habits. Anyone else…

I'm definitely not a vim master but I've made an active choice to avoid 4j style movement. The main benefit of vim, for me, is the mind-body connection. Commands are either muscle memory or like saying a short phrase in my head so it flows out naturally. Counting lines before executing breaks that natural flow

For more than a few lines I'll go to a spot and mark it (ma), navigate to the next spot and delete to the mark (d'a).

That's how I thought of it anyway, not delete n lines. Delete from here to here.

Post reply on HN