Show HN: I built an interactive course that helps you learn Vim faster

[Silica6149]

Hey show HN!

This course came about as a result of wanting a more targeted way of practicing using new vim commands I wanted to pick up, rather than just trying to use them in my regular code editing sessions. When I would try to use new commands during code editing, my productivity took a hit because I was trying to do two different things at once: thinking about code vs practicing my muscle memory.

So, I made a separate environment for practicing, one that had an interactive editor, progress tracking, and achievement goals to let me see which areas I should work on, like speed and efficiency (# of keystrokes). When I realized it would be useful for beginners too, I added lessons to go along with it and this course is the result!

Let me know what you guys think about it :)

[xavdid]

This looks very cool, kudos on the launch!

I feel like vim tutorials mostly focus on navigating and editing a single file, which is great! But I mostly struggle with how to replicate opening a whole directory in VSCode, which makes it easy to browse the directory, switch between files, open multiple panels, etc.

I'm almost certain vim does all these things out of the box, but tutorials always end at "this is how you edit some text quickly" and never cover "this is how you do software engineering".

[vidyesh]

I am new to using vim too so NerdTree is a little hard for me to use and navigate and the split windows too are difficult to understand in vim. Not many tutorials or guides or courses cover that well.

So I have the same issue as you, I really like using neovim for smaller projects as its easy to work on them through the shell. But when it comes to big projects I go back to VSCode with the Vim emulator extension as it just makes using the tree much easier for me in VSCode. I have setup custom keybindings and settings to launch the directory when needed or the command palette works great to launch other files. I wish there was a resource to help switch VSCode to neovim while retaining some of the "most" used VSCode features.

[bootstrappit]

That's exactly how I feel too. I just started using neovim a few weeks ago. I'm using `nvim .` to get to a navigable tree, but have no idea if that's the right way to do it.

[RMPR]

You may want to check out Practical Vim by Drew Neil, he covers that aspect.

[seanp2k2]

  :set nu
  / whatever you want to find [return]
  i
  *edit stuff and use arrow keys for nav*
  :wq
  Or :q to quit without saving

That’s all the vim most people need.

The fact that less is installed on many more systems than nano is a testament to the bad assumptions too many devs make about who will be using these systems in the future. And yes, it’s not hard to "apt -y install nano" except at work where we have proxies and internal repos, so now I need to use vim to reconfigure apt sources just so I can use a more normal editor that doesn’t require arcane incantations to perform basic config file editing.

[dash2]

I really want to like vim and I love some things about it, like the ability to move chunks about with only the keyboard. But so many things about it kill me. Like, why can't I hit right at the end of a line, and move to the next line? Who thinks that is a good idea? Also, why do I have to have a special mode to insert things? Having to change modes just seems so complex and unintuitive. And why does the help system never tell me what I want?

The frustration is that probably there are fixes for all these things, which if I were an expert I would know. But meanwhile I can use an ordinary visual text editor and I don't have to learn anything new.

[yetanotherjosh]

Are you interested in learning a potentially new and more efficient way of doing things? Then you have to stop being annoyed that your habitual way of doing things is unavailable to you, and stop assuming your habits are the obvious and correct way.

The modal nature of Vim is one of it's key features and makes a lot of sense. If you consider the keyboard the primary, if not singular, means of interaction, then there will be times you want to use the keyboard to type text and times you want to use the keyboard to control the editor behavior. In a "normal" editor, you have to use modifier keys to enter commands. In Vim, you do it by changing modes. It's actually quite powerful but you can't get past your own assumptions about efficiency.

[dimensional_dan]

> I really want to like vim

> Also, why do I have to have a special mode to insert things?

First and foremost Vim is a modal text editor. If you don't like that Vim is probably not for you. Your comment is kind of like saying I'm really trying to like chocolate, but I don't like the flavour.

There's a Vim way of doing things, if you really take the time to learn it then the questions you are asking will all be resolved.

[gofreddygo]

I really want to like to swim and I love some things about it, like the ability to not sink when thrown in deep water. But so many things about it kill me. Like, why can't I just sit in the water, and float to the top? Who thinks that drowning by default is a good idea? Also, why do I have to have a special way to move my hands and legs? Having to coordinate my limbs just seems so complex and unintuitive. And why can I not see anything underwater? The frustration is that probably there are fixes for all these things, which if I were an expert swimmer I would know. But meanwhile I can use an ordinary kayak and I don't have to learn anything new.

[wruza]

why can't I hit right at the end of a line, and move to the next line? Who thinks that is a good idea?

I do, I hate accidental wrapping on left/right so much and see absolutely no use to it.

But you may configure it, :help 'whichwrap'

Also, why do I have to have a special mode to insert things?

Because if your alphabet keys do always insert, you have to hold some control key to enter commands and movements, and not if not. That’s the point of being modal. Otherwise there are plenty of emacs-alikes to train pinkies on, and no need for yet another notepad+.

[konart]

> there are fixes for all these things,

No, because those are features, not bugs. If don't want them - you don't have to even think about them.

>Like, why can't I hit right at the end of a line, and move to the next line? Who thinks that is a good idea?

It's not that you can't. The idea behind vim-like navigation is that you don't press those arrows (or hjkl for that matter) in a consecutive manner (or hold) unless you really have to. 99% of the time you jump to some place in the text (a character, or line, a word, a nth line etc).

[mpalmer]

> an ordinary visual text editor

Funnily enough, Vim is short for "Vi IMproved", and its predecessor vi is short for "visual"!

---

Taking the time to learn Vim yields significant rewards if you're willing to meet it on its own terms. I certainly grant you that it's not for everyone. It's the agony and the ecstasy of deep tools. No pain, no gain.

> The frustration is that probably there are fixes for all these things, which if I were an expert I would know.

I would submit that if you were an expert, you would not have the same list of gripes. To wit:

> Like, why can't I hit right at the end of a line, and move to the next line?

This is a fair complaint, but one that's actually never occurred to me as a Vim user, because:

> Why do I have to have a special mode to insert things?

It's a core part of Vim's design! In fact, insert mode is The other mode (Normal mode) is where the real power is. It's not so much about moving chunks of text around with the keyboard as about moving the cursor.

Vim divides normal mode key commands into motions and operators. operators add/remove/change text, and motions move the cursor.

For instance:

- `d` is an operator deletes text.

- `w` is a motion that moves the cursor to the start of the next word

- `12w` does this 12 times (practically every motion can be repeated like this)

But the rubber really meets the road when you combine them.

If you hit `d` once in normal mode, nothing happens: you've started a command but Vim is waiting for you to finish it by entering a motion. `dw` deletes from the cursor up to the start of the next word (you can guess what `d12w` does).

> And why does the help system never tell me what I want?

Perhaps start with `:help help` :)

[snet0]

> why can't I hit right at the end of a line, and move to the next line?

I know this is probably something that sounds like someone too far down the rabbit-hole to see where they came from, but I'm not sure why you'd want to do that. The horizontal movement is probably adjacent to the vertical movement on your keyboard. Just use the appropriate movement to get where you want to go?

> Also, why do I have to have a special mode to insert things?

Because then you can use the regular keyboard, i.e. keys that would normally insert characters, as control inputs.

> But meanwhile I can use an ordinary visual text editor and I don't have to learn anything new.

You don't have to learn anything new because you don't want to do anything new.

[VoodooJuJu]

>Like, why can't I hit right at the end of a line, and move to the next line

What do you mean by this? Do you mean the right arrow key?

The mode paradigm was definitely weird to me too at first, but it eventually makes sense, especially when you start using macros.

I agree about the help system - it hasn't been very helpful to me either. I usually am better off consulting stackoverflow or vim's wiki for how to do something.

Vim took me quite a bit of time to learn beyond the basics, but once I learned it, it became a productivity boon. It's nice to have the same powerful text editor available wherever I ssh to, right in the terminal, in the same place I'm using all my shell commands.

[naillo]

Learning new things is fun and you get used to it. I like the shift A command for moving to the end of the line (and go directly to insert mode). A good tip is to mainly stay in edit mode (and remap caps to escape and hammer that to go back to the default non insert mode whenever you're done).

[agumonkey]

Have fun in other editors for a while (no need to suffer something that annoys you), and reconsider vim in a year. Its ergonomics can be frustrating at first but the design is sound enough to be valuable, fun even. And I say as an emacs user :)

You don't really move a caret around in vim, you process units of text and lines.

[juniperplant]

> Like, why can't I hit right at the end of a line, and move to the next line?

set whichwrap+=<,>,h,l,[,]

Source: https://vim.fandom.com/wiki/Automatically_wrap_left_and_righ...

[bitlax]

https://gist.github.com/nifl/1178878

[Silica6149]

I think most people would agree with you. Being comfortable in your editor of choice and knowing the shortcuts in it will already make you faster than trying to use vim from scratch (at least for a while). Vim definitely needs to be practiced and used more frequently to get up to the same speed as regular editors. However, you can reach (an arguably) faster speed in vim.

[yjftsjthsd-h]

> But meanwhile I can use an ordinary visual text editor and I don't have to learn anything new.

Then do that?

[robertlutece]

> Like, why can't I hit right at the end of a line, and move to the next line?

:h whichwrap

[nomoreusernames]

press o?

[CoffeePython]

Congrats on launching :) I built a pretty similar tool last year [1]. This looks like it has some nice improvements over the stuff I did with mine.

Wish I had the time to improve on the course I launched but I ended up starting a company shortly after launching my course and getting into YC.

[1] https://www.vim.so

[psyklic]

This is very kind, saying "pretty similar." The example exercise seems nearly identical!

[drodil]

When I was learning vim, I decided to extend the existing vimtutor with some more programming specific tasks. You can find it at https://github.com/drodil/codetutor.vim if you are interested :)

[phkahler]

Just type "vimtutor". If you have vim you should also have vimtutor.

[MatthiasPortzel]

My pet peeve is Vim tutorials that start with "use hjkl to move around" instead of "use `set mouse=a` to turn on the mouse." In my opinion you need to make sure that you are very clearly disclaiming that you are teaching a harder way of doing things in exchange for incredibly small productivity gains that will be realized years in the future, if ever.

(This is basically a copy-paste of previous comments I’ve made, I haven’t tried your tutorial beyond the first lesson.)

[delusional]

This may be a little elitist, but if you're not going to use vim the way it's really made to be used, why even bother? I get that `mouse=a` makes it more familiar, but if you're always going to reach for your mouse, you're never going to really get used to the motions.

[BirAdam]

I very whole heartedly disagree. I find vim to be an unusable vi implementation until I turn off mouse support completely. For that matter, I also have to turn off any automatic indentation and any other "smart" feature that people try to ram into their distro-default configurations. It's nearly as annoying as autocorrect is on a desktop computer.

[vscode-plz-stop]

I just created this account to say that I agree wholeheartedly 100%. People always ask me, "How do I get better at Vim?" or say "Vim is too hard" etc, and I always say `set mouse=a` isn't just a gimmick, it's a _very_ useful feature...

[yetanotherjosh]

a harder way of doing things initially in exchange for incredibly small productivity gains that when applied millions of times over the course of a programming career, make a monumental difference

A key ethos of Vim is that once you climb the initial learning curve, you're on a path of increased efficiency for the long haul. Moving the hand to the mouse, dragging the cursor to the spot you want, then moving the hand back to the keyboard, is objectively slower than key-based movement commands for someone who has climbed the learning curve and I'm confident that could be proven empirically though I'm not aware of any such proof. There may be certain exceptional cases where the mouse is faster, but for most editor usage it would not be. I'm not sure if you agree w/ that and are just criticizing how tutorials introduce people to Vim, that they should start w/ the mouse to lower the learning curve, which might be an okay argument.

[em500]

I use vi(m) more often on remote servers than locally, and in many cases I don't have much control what software is available. Mouse support is a crapshoot, so I never bothered with that.

[Silica6149]

Ah, I see. I agree, more context would be better for the beginner to understand why the lessons are the way they are.

I tried to explain the benefits of vim in the "Why Vim?" section, but I should really go into why using and learning vim will be slower at first than using the editor you're already comfortable with, and how it might be worth it in the end.

Thanks for the feedback!

[manx]

Agreed. Hjkl only makes sense when using a keyboard layout where these 4 keys are located in a row. This fact made most vim tutorials useless for me, as I'm using the neo2 keyboard layout, where arrow keys are located in the middle of the keyboard and hjkl are not in a row. Using vim works well for me, and I can use hjkl for other keybindings.

[renewiltord]

Interesting, I always move down by page. I find the mouse to keyboard switching disorienting. But I know lots of great engineers who use the mouse extensively. I wonder if I just trained myself into this efficiency (and out of that efficiency) when I was young.

I bet I could untrain with sufficient work but it's no longer worth it.

[kjeetgill]

Huh. I mainly find myself disabling mouse=a if it's on by default. But that's mostly because the only time I'm using my mouse is to copy/paste something out of my term and it breaks that.

Also, I think scaring people away from arrow keys is premature. It's not that big a deal.

[Arisaka1]

I once tried to migrate from VS Code to Neovim. I use TypeScript at work, and use many languages for my side projects.

But the worst part was making Vim provide with things that you'd expect programming editors to have. So many options, what's best is up to opinion, integrating language servers, getting intellisense to work as you would expect, searching the project folder for file names.

Then I realized that all I'm trying to do is make Neovim behave like VS Code with the extra addition of keyboard navigation, which I can get behind. But at my current career level I'd rather spent those 5-10 hours configuring an editor in learning more about <insert whatever language/framework I'm learning>.

I mean, just another Vim introduction when you already have the free options (vimtutor etc.) and FEM's "Vim Fundamentals" won't fix my pains with getting it to work as I'm expecting it to work.

[chadcmulligan]

Nicely done. Though I have to say - I gave courses on vi in the 80's but then IDE's and GUI's came along and I moved on. I will never understand why anyone still uses vi in the 21st century, except for occasionally editing a config file on a *nix box.

[cassepipe]

Learning to remap escape to Caps Lock or to jk or what the Ctrl combination are to switch to normal mode should be the first lesson of all vim courses. This was the biggest cognitive discrepancy for me as a vim beginner : What did you use your smarts to create a modal editor while choosing the worst key ever to switch modes!?

[sneak]

*interactive paid course. That should be disclosed above the fold, methinks.

[stayux]

I am a designer that got fed up with "mouse" control everywhere.

One day I asked myself: Is there a way to scroll in the browser without using a mouse or arrow keys?. Enter Vimium.:)

I have tried in the past Emacs, but I have an operating system, and I don't need a new one (for now). So now you can take MacVim only from my cold hands. P.S. > You can paste the buffer in insert mode with ctrl+r+0.

[stevebmark]

Please just read Practical Vim if you’re going to double down on using Vim. All of these tutorials are the minimal basics. Vim forces you to glue together lots of inefficient commands to manipulate text. I feel frustrated seeing Vim users tout how efficient their editor is when they haven’t learned all of Vim’s nasty bells and whistles you need to actually be efficient at manipulating text. (When you press colon, do you know how to edit the command in Vim mode? No? Read Practical Vim).

[QuiiBz]

I wonder why the headline and other gradient title are images. Why not a text with linear-gradient and background-clip?

[immigrantheart]

I'm a vim user. Over the time I dwindle down my plugins and stick to the basic ones because I often do SSH and don't want my environment to change rapidly.

One thing that I still need though, is proper syntax highlighting. I wish there is an easy way for vim to do it rather than just too many plugins here and there.

[giansegato]

I see that there's a pretty big miss in the syllabus: surround! yes, true, it's not "official" but rather a plugin, but you can't really do without it, can you?

[mastermedo]

I love projects that popularize vim. But I think this one might be in a way too early stage to justify the pricing (assuming those 8 lessons are all there is).

[vogt]

Amazing. I came into programming from a bit of an unorthodox professional background. When I started learning web app development in a serious way, I got blindsided by some of the encounters with vim. In fact it took a long time before I even realized that it was vim I was interfacing with at first. wish I had this back then.

[johncoltrane]

> Let me know what you guys think about it :)

Same as the last time you posted it: learning Vim has nothing to do with muscle memory and doing it outside of Vim is pointless. Plus, the "master Vim" claim is dubious given how basic the lessons seem to be.

:help user-manual is easy, built-in, and it goes way beyond this. And it's free.

[timwaagh]

I often use vim for editing files but not code. The need to adhere to corporate style pretty much kills it for that.