Live data from Hacker News

Learn Vim (2021)

github.com

211–215 of 215 posts

Re: Learn Vim (2021)

#211
Those new to vi(m), check this vi quickstart tutorial that I created.

https://gumroad.com/l/vi_quick

From the start of a Twitter subthread I wrote about the tutorial (thread unfortunately deleted later by accident - Twitter should have an undo feature like vim, heh):

[ Those new to vi / vim, hit the ground running with my short vi quickstart tutorial here:

https://gumroad.com/l/vi_quick

I first wrote that tutorial at the request of a couple of Windows system admin friends of mine (at a company where I worked earlier), who were tasked with managing a few Unix boxes, without knowing Unix. They used the tutorial and later told me that it helped them to quickly start using vi to do their work on those boxes, including editing config files, simple shell scripts, etc.

Edit: Since vi is mostly a subset of vim, the tutorial works for vim too. ]

Re: Learn Vim (2021)

#212

Earlier quoted context omitted.

I don't understand this attitude. It's clearly more conducive to solving problems to be able to move around our environment more quickly. It's extremely useful (compared to a beginner who only knows insert and write quit) to understand the different vim modalities as well as a few commands to jump around a file or to perform regex or to call an external command. When you're not proficient with the necessary tools, yo…

I’m definitely not going to try and endorse intentional incompetence. I think it is just not so tricky in the first place. If you start out with “you can use hjkl for directions, and y for copy, d for delete, these can be combined with directions and prepended with numbers; remember the modes, and :w and :q” vim is already as good as most others editors. Then I’d just start using it, rather than trying to learn from…

> My filter for when I should learn a new feature is when it solves a task I find repetitive and annoying

There! You said it so well... that's the #0 reason why I go RTFM'ing, because most likely my problem fits a pattern someone already encountered and figured a solution for. Or nobody did and I put together a less annoying workflow to deal with it.

Sometimes the effort is worth it, but often it is just fun trying out new things/techniques.

Re: Learn Vim (2021)

#213
post #191

Earlier quoted context omitted.

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

Keyboard layout, it would actually be Ctrl+Alt Gr+8. That little lag on the j doesn't matter, when you notice you're already a few keys ahead anyway.

Ah, I hadn't thought about international keyboard layouts, yes, that sounds like it'd be a pain to type.

Re: Learn Vim (2021)

#214
post #58

No one should be learning Vimscript at this point. That language should have died a long time ago. A new user coming to the Vim ecosystem in 2023 would be best served by using Neovim with Lua.

Vim9script is pretty darn good; and fun to use.

Re: Learn Vim (2021)

#215

Earlier quoted context omitted.

This is true for tools in general but I've managed to master vim to the point I can be somewhat productive yet it never feels quite ergonomic. Moreover, I think vim-like UI is holding everyone back nowadays. Learning all the intricacies of vim feels like an exercise in brute-forcing a deliberately user-hostile design. For example, is it really still OK to have little to no visual feedback when entering commands with…

> Vim's modal editing implementation also can't handle non-Latin keyboard layouts This issue is solved by langmap.

It really isn't. I've spent a lot of time trying to tune langmap/keymap and looking into other options but the result is mostly unsatisfactory. Some of the issues: only translates the first letter of the command; doesn't support :commands; isn't expressive enough to remap punctuation. Vim needs to be keyboard layout-aware in order to support non-Latin keyboards. It also needs to know whether the current input state is expecting text or a command (e.g. typing ":s/" from the normal mode should always be parsed using the Latin layout but the currently active input language should be used following the "/").
Post reply on HN