Show HN: I built an interactive course that helps you learn Vim faster | Hacker News Reader

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

vimified.com

344 pointsSilica6149253 comments

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 :)

Open articleView on HN

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

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.

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.

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

Good to know, thank you! I'll check it out.

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

Absolutely haram

Is this an Andrew tate reference or just normal Muslim one?

Nano and commandline is good enough. If apt is available, Micro is even better.

I don't find Nano very productive or very easy on my previously RSI-suffering hands and wrists. VIM is so much better for me along those two dimensions that it's not even much of a comparison.

My problem is I can't use the up/down arrows for nav while editing stuff, it just starts spewing control characters on new lines IIRC.

This is the reason why I like vim-nox

now I need to use vim to reconfigure apt sources just so I can use a more normal editor

Prepare and paste this into your terminal:

  echo "another line" | sudo tee -a /etc/apt/sources.list

Sorry for your pain, but choosing hard ways is a person’s business.

I believe the parent was trying to say that the default editor is the hard option, even though easier and intuitive solutions exist.

or just "echo 'another line' >> /etc/apt/sources.list"

Yes, but only when logged in as root.

of course, but redundant if you are root

*sudo is redundant

This is equivalent to saying hunting and pecking on a keyboard and using only their index fingers to type is "all the typing most people need". Technically, it's true, but it's also sacrificing a lot of productivity that could be gained from a relatively modest one-off investment in learning a skill.

It's also derailing someone's Show HN with a very old and generic online argument.

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.

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

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

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.

press o?

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

My answer to all these things is that 90% of the time, I am not using a text editor. I will be writing in Word, or in LyX, or in RStudio, or in a text box. My muscle memory is used to that.

You're absolutely right. You do sound far down the rabbit hole! I am used to being able to hold down the right key and traverse my entire document, as far as I like. Why would I want to stop at the end of a line? Any time I'm editing multiline text - like, say, English - that is essentially arbitrary.

The regular keyboard... right... but what if there were some kind of special key that could be pressed to issue controls? Why is that worse than having a special key that goes into control mode? This is analogous to having caps lock, but no shift key.

Again, you're right, I don't want to do anything new. Why would I? I want to get on with my job. If the response to my complaints is "the problem is with you, my son", without any idea of the ultimate benefits I might gain from changing, then yeah, I'll pass. Honestly, this applies not just to you, but to all the responses below... they're all like "if you try it, one day you will understand". That's probably what people say about Morris Dancing.

> I will be writing in Word, or in LyX, or in RStudio, or in a text box.

You might still spend more time editing than writing, and Vim's modal approach makes editing more comfortable to me.

> Why is that worse than having a special key that goes into control mode? This is analogous to having caps lock, but no shift key.

The assumption is that modal editing is more comfortable and powerful. I can traverse the text and make modifications and replacements without holding chords between Ctrl, Alt and letter or arrow keys for long periods of time. Vim's model with text objects also makes some things easier to do than what you can accomplish with chords on editors liks VS Code.

If you spend a significant amount of time writing in all caps, you might benefit from having a Caps Lock key instead of shift.

> I don't want to do anything new. Why would I? I want to get on with my job.

Vim is something that's radically different from other text editors. If you think the learning curve is not worth it, it's up to you. It might not be; it's not like it will turn you into a better writer or programmer. But its uniqueness was enticing enough for me to give it a go, and I realised I enjoyed working with it.

> "if you try it, one day you will understand"

I don't think you should try Vim because it will magically make you a better professional. That's a fantasy some people use to justify the time investment they made to adapt to Vim. I think you should learn it if you're curious, and it's fine if you start learning and decide it's not worth your time. Have you never learnt something just for the fun of it?

PS: If you use VS Code or a JetBrains IDE, I don't recommend switching to Vim. Just do Vimtutor and go back to your regular IDE with a Vim plug-in. VS Code's is pretty good. This is the best of both worlds: you get all the powerful extensions and general IDE goodness while having Vim's Normal and Visual modes. As a bonus, you can still use the regular navigation and editing shortcuts while in Insert mode in VS Code. E.g. navigiating and selecting with Shift, Alt and Command plus arrow keys works like normal, so you don't need to switch modes for small things.

> I am used to being able to hold down the right key and traverse my entire document, as far as I like.

I mean chances are, if you're holding down a key in vim, you're doing an inefficient movement. That's kinda the point: it's a keyboard language that turns complex actions into compound, simple actions. If you're still using the simple movement and complaining about it not doing what you want, you're just not using vim correctly.

I'm not sure why people get this defensive, though. People like vim, people like editors-that-aren't-vim. Is that not okay? If you don't want to learn to use vim, this link isn't for you.

> but what if there were some kind of special key that could be pressed to issue controls?

This works for a limited number of shortcuts, and when you only want to issue a few. The point is that you can now issue a large number of "command" inputs, very quickly, without holding down a key.

> Again, you're right, I don't want to do anything new. Why would I? I want to get on with my job.

Then uh... don't use vim? Do you post on every "I wrote xyz course for abc language/tool/technology" expressing that you don't want to use it?

I mean it's obviously not the tool for you, so don't use it. I find it for easier to navigate code using the vim modal concept, and can context switch relatively easily when moving over to another editor. I don't think anyone is trying to convert you or will be upset if they fail to do so.

You’re asking why this hammer can’t make ice cream. vim is a modal text editor. That’s fundamental. If you don’t like it use something else.

vim is a line-oriented text editor. When using vim, my mental model of the file is an array of (mutually non-contiguous) arrays of characters, not a single array of characters. I expect the same is true for most proficient vim users.

This is clearly a great fit for programming in most languages, but it also works well for natural language. You can put one sentence per line or even split up long sentences into clauses. Then you use the line-manipulation commands to make big edits quickly. Of course, this only works for formats like LaTeX and HTML where consecutive nonempty lines are merged into one line for rendering.

Under the "array of lines" mental model, it doesn't make sense to hold down the right arrow key and traverse the entire document. You move to the desired line first, then move to the desired position in the line.

I agree the two models are basically incompatible. I don't like editing text in non-vim interfaces and will generally open vim for anything longer than this comment.

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

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

> 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` :)

These sorta combinations and things like visual block mode are why I can’t let go of vim. You can also do:

set -o vi

And get vim in your bash shell. Then you wonder what the default mode is, and it turns out it’s emacs and you can do wild things like ctrl-A to go to the beginning of the line.

And now I cringe when ever I see someone painstakingly left-arrow for 30 seconds to edit something at the beginning of their bash prompt.

>> set -o vi

A million thanks!

Didn't know about that. I'm using default shell shortcuts, which are different set of shortcuts. Like:

* Ctrl-u: clear line and start from the beginning * Ctrl-a: go to the beginning of line * Ctrl-e: go to the end of line * Ctrl-b: move backwards * Ctrl-f: move forwards * Ctrl-c: leave the command as it is, just cancel the command and start with new line * Ctrl-w: delete a word before cursor * Ctrl-h: delete a character before before cursor * Ctrl-d: delete a character after cursor * Ctrl-t: swap last 2 characters (this is one of my favourites in terms of lulz, I actually trained myself to use it :D) * ...

Pulled these out of my fingers, but there are more. Don't know the correct source to point to.

What's good about those is that they work by default and behind every computer.

This is where you can find a reference for the default emacs mode: https://catonmat.net/bash-emacs-editing-mode-cheat-sheet

Unless you’re super into vim, it makes more sense to learn the basic emacs keybinds ‘cause like you said, it’s almost everywhere.

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

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.

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.

>...more efficient way of doing things?

Is that a fact, or you just parroted other people who made similar claim?

for me it is a fact.

I still use the mouse from time to time when editing text mind you. But for most actions, I would not think of moving my hand to the mouse, because it is slow.

Even before vim, I made gratuitous use of end of line navigation via keyboard (home/end buttons; cmd+arrow keys). vim is just a more powerful version of those buttons.

I make no claim that vim is the MOST efficient platform ever created, but it's a lot faster than mouse+keyboard and/or out of the box editing methods.

I would like to leave this link to SO page on mouse vs keyboard... You may be faster with a keyboard, but may ONLY feel faster with the keyboard.

https://ux.stackexchange.com/questions/30682/are-there-any-r...

The link feels irrelevant, because it is not related to vim and text editing. Or does it?

It is a fact. The grand parent is talking about slowly navigating around one character at a time. Vim has much more efficient ways to move the cursor to where you want to go.

For me it is not a fact, and I find vim objectively much more harder to use than “regular” editors. But it matches my thinking in a way that I don’t have to plan ahead how many times to press an arrow, or to wait until a key repeat rate gets the cursor where I want it to be. Acquired vim reflexes erase the complexity and leave this benefit.

I always found this “faster” claim somewhat stretched and zealous. I don’t need to type fast. I need the editing routine to gtfo of my mind when I’m programming.

I find it quite a bit faster to type ci] or ci) to replace everything inside a pair of [] or () than selecting the same text through other means. There are similar shortcuts for working at the word, block or "rest of the file" levels and it's all consistent across replacing, deleting and copying actions.

> I don’t have to plan ahead how many times to press an arrow

Usually, I'll just do something, e.g., hit dd to delete a line and then even though I could hit "3." to delete three more lines, I'd usually just repeatedly tap . to repeat that dd action. It doesn't really matter if the action is deleting a line or commenting/uncommenting it or changing capitalization or modifying a word in a certain way. The general strategy of doing the action you want and then repeating with . it is very useful.

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

:h whichwrap

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

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

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.

I mean, these are all valid criticisms of the swimming experience, it just sounds silly because you can't edit swimming.

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

Then do that?

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

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

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 :)

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

Ah, the lost ritual of descending into accompanying manuals. Only a few are able to practice it nowadays.

In fairness, a lot of software doesn't come with good documentation built-in anymore, so it's understandable that people would get out of the habit.

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

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!

IMO, the choice of nix editor is always somewhat contextual depending on how much full stack work is being done. If one is doing a lot of systems work (ie a lot of bash commands), then one inevitably wants to set a default editor on the systems being used. While I choose vi, it really depends on the number and type of systems being regularly accessed, and your personal preferences. For me the use of a terminal editor is just part of the seamless flow of using the command line for everything else. I personally don't think it is especially valuable to consider terminal editors in isolation away from bash, other than to become familiar with key strokes.

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.

I think they were speaking from a total beginner's perspective, and how to get them up to speed as fast as possible.

I felt the same way when first learning vim, since it was completely different from the code editors I'd used in the past, it was strange not being able to use the mouse in the way I was used to.

I get that, but that strangeness is what pushes you to learn. I find that if I can do something suboptimal, but familiar, it takes way longer for me to change my habits because my subconscious keeps thinking in terms of the familiar.

I find it much more useful to remove the ability to even do the wrong thing, than to simply try and will myself to do the right one.

Oh yes, when I was trying to fully learn vim, I had the mentality that I could just practice it for 10 minutes a day and be able to use it while editing code.

The remaining time I would edit code like normal with vscode, so it turned out that I wasn't really able to pick up vim and use it well.

It wasn't until I switched to a different keyboard layout that I decided to move over to vim cold turkey, and was actually able to learn vim and retain it.

I agree. When I started at my first internship, one of the developers (and now a close friend) put layers of tape over the arrow keys so I couldn't use them. Took a week of pain and then I never went back.

I get that, but that strangeness is what pushes you to learn.

Yes, exactly. This is analogous to travelling to another country and hoping to learn the local language by immersion. If you then meet people that speak your language you run the risk of only hanging out with your little expat group and never immersing yourself in the local culture. You can end up spending years there and never learning the language.

Vim was designed on qwerty keyboards. On other layouts (e.g. neo2) hjkl are not in a row.

That's somewhat comforting to know. I'm in the beginning stages of building out a keyboard-heavy application, and I keep wondering about how to support different keyboard types. I suppose it's not possible to satisfy all customers if even Vim can't do it.

Just support QWERTY but allow the user to remap everything. Even among programmers, the share of people that use alt layouts is so small that is not worth your time.

I’m a Colemak layout user. I don’t bother remapping anything for Vim because I want it to be consistent with other apps with vi keys.

I have done that briefly years ago but I find it a dead end.

After a while you just get used to the cursor keys being in a different place and if you’re touch typing it doesn’t mater much.

Also what you loose to cursor key placement you gain back on other navigation.

So in short just support qwerty and it’ll be fine.

Specifically, it was designed on the ADM3A keyboard, which had the arrows printed on the H, J, K and L keys. Also of note is the key in the upper right, which is labeled with "HOME", ~ and ^ (which explains why shells use "~/" to represent the users home directory).

And while I'm diving into history here, vi (which stands for "visual") was a modification of "ex" to use the newfangled "video terminal" instead of the battle tested teletype machine.

Very minor issue, speaking as someone who switched to dvorak and then workman while continuing to use vim daily. No keys remapped. It's just not even an issue. Those letters still make those movements. They're in different spots, but I already had to get used to the new spots for writing words in the first place. Doesn't even feel slower.

IIRC dvorak even happens to split the vertical and horizontal movements between hands but while keeping them near each other, almost like RC car controls. Workman is comparatively a bit crazier with its placement, but it still doesn't bother me.

Tbh, one of the biggest issues with vim for me is, that all my coworkers do not use it. When I have to explain something to them, they are completely oblivious as to how they navigate vim without the mouse. So enabling mouse is one of the most important things for me

I use Vim as a secondary editor, when I need to quickly edit a file in my terminal or over an SSH session. I'm not interested in it replacing my primary IDE.

If you're going to disable the mouse and the arrow keys and really commit to the home row, more power to you. That is probably the best way to master Vim. But I think a significant number of people looking at Vim tutorials have never used the editor, and I think they deserve to know that there is an easy way to make the editor more comfortable and more familiar.

Someone down-thread used a metaphor to say 'the best way to learn a new language is by immersion' which is something I would agree with. But opening Vim for the first time feels like being dropped into a foreign country where no one speaks your language. Imagine how frustrated you would be to find that the people there actually do speak a language that you know, they're just refusing to understand you because you haven't issued the magic words, "set mouse=a"

That's certainly valid. I've had friends throughout the years that used vim as you would nano. I don't think vim is any good when you use it like that since the more advanced features just get in your way, but if it works for you then that's cool.

The people who seek out a "learn vim" course are just not that kind of people. In this case you've signed up for a course on how to speak Spanish only to ask the teacher to not speak Spanish.

You're conflating learning aids with actual usage.

Having mouse support gives you a superset of functionality. Often this can be useful, like if you have on your hand on the mouse using another application.

Saying "why even bother" using vim if you add features just makes no sense.

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.

I posted another comment on this, but I never found this to be an issue when using dvorak or workman. Just as I slowly relearned to type the letters at all and improved over time, I kept using vim and got used to hjkl being moved over time. It doesn't bug me at all.

Interesting. I guess the difference here is that I learned vim after neo2 (https://neo-layout.org), not before. That way I already had proper arrow keys in my home row and hjkl felt cumbersome and redundant.

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

Definitely a hurdle to overcome for beginners.

Although, it would help to show beginners exactly why abandoning the mouse will be better in the long run. It wouldn't do well for them to always rely on it in place of more efficient commands. Some people might always use the arrow keys instead of hjkl, for example, when hjkl will be better in the long run since they are on the home row.

I buy the idea that the more advanced features of vim are worth it, being able to quickly cut+paste bits of text around, skip to end of line/bracket/etc.

I don't believe I'd write usefully larger amounts of code by using hjkl instead of arrow keys, and personally I am always going to use the mouse when I want to move more than a couple of lines.

Yup. I had tried to use vim and quit because I thought it was needlessly cumbersome.

What changed my opinion was watching videos of people using vim on youtube that made me interested in learning it for real. It made me realize how much more efficient it could be.

The comparison is not between hjkl, arrows and mouse movements. Vim motions are far richer than that.

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.

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.

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.

Counter point; set mouse support and if you want to use it use and if you don’t don’t.

I’ve been using Vim as my primary editor for 25 years and at this point the keyboard nav is burnt into me.

I still use two finger scrolling on my track pad though. If I’ve been in another window I might also start the cursor at a point with trackpad.

It works fine over ssh too.

I think most newbies that care enough to try Vim know there is a Vim Way. They know about Vim Golf.

That get tiring all the time when you’re starting out. Sometimes they just want to get the job done until they learn, I’m ok with that. Just have a go.

It’s absolutely fine to make use of all the features Vim provides and use it any way you want because you’re always going to me slowly learning more.

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.

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.

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.

This is a good starting point if you ever feel like trying again with Neovim.

https://github.com/nvim-lua/kickstart.nvim/blob/master/init....

If you’re trying to achieve VS Code with the keyboard navigation of vim, have you given the VSCode vim plugin a try? I’ve had positive experiences mixing editors/IDEs with a vim plugin to get the best of both for my workflow.

This. VSCode has so many great features. Adding in keybindings for vim via a plugin has worked great for me.

I use this but my god the VS Code vim plugin pisses me off sometimes. It's good probably 99% of the time. But I feel that (from time to time) it collapses multiple commands into a single undo action.

Frequently I find myself frustrated that I can't undo exactly what I need to, and it ends up undoing more than I want it to. I never had this problem with vim but with vscode, I probably experience it once a day.

That plugin’s handling of undo drove me absolutely nuts! It would randomly decide to eat the entire undo stack when I accidentally mixed the native cmd+z with using u to undo. At least I think that’s what happened… I was never able to reproduce it on command, though. It would happen unexpectedly, and often would destroy a whole swath of text that was then impossible to get back.

I switched to the vscode-neovim plugin which works better… at least, it doesn’t do this undo thing, and it’s faster. But it’s not entirely perfect either and lately the command/insert/cursor location has been bugging out.

Vim is a text editor, not a code editor. IDEs are much more efficient for code edit.

Vim is a code editor, IDEs are mouse-navigators.

That's wrong. Vim can be setup as an IDE and it's the IDE of choice for many developers.

vim bindings exist for IDEs as well.

You aren't always able to use an IDE.

You aren't always editing code.

You also don't have to wait on an IDE to support your language.

What about prepared set of plugins for vim for typescript https://spacevim.org/use-vim-as-a-typescript-ide/

Okay, but you spend 2000 hours per year at work.

So 10 hours on a config is only .5%, which is the productivity gain you need to realise to get that time back in one year (assuming you also spend 0 hours on fighting vscode).

Unless you're retiring within the year, that calculus doesn't make sense.

The productivity boost you get with from Emacs/vim is huge once you learn it well.

I strongly believe that learning one of these two editors is probably the easiest and biggest skills leap you can take as an intermediate or senior developer.

No other skill you can learn will have as big of a payoff to your productivity given the relatively small effort to get proficient.

I've been coding for nearly 40 years and I just don't see any correlation between editor usage and developer productivity. Being able to design and work with complex software systems is what makes a senior dev productive, not which keys they hit to copy and paste.

I really doubt that the tools of your trade do not matter.

I’ve been building corp infrastructure for a decade and I can tell you first hand how much of an impact fast, stable, updated environment can have on organizational productivity and overall output. I doubt devs are some how excluded from the pack.

The old proverb of shit in shit out also applies.

You have a fair point about tools and environments. I just don't think of editors as being a significant part of an environment, nor a significant differentiator of tooling.

I've worked on teams where some members used IDEs and others used traditional text editors, and what differentiated their productivity was inevitably between their ears.

You should see how slow people are at doing the following: creating a new directory, creating several files, initializing git, and creating a new work tree.

While learning vim/emacs and CLTs may not make you a better programmer, but they can absolutely make you better at understanding and using your tools effectively.

One simple thing I like to do at every job is setup an ansible playbook for the team I'm working on. What ansible allows is me to setup a tool to download all the relevant languages, binaries, create company specific repos for directories, establish a foundation of common CLTs, automatically install software, and fully setup all the paths. Now any person, old or future hires, can literally set up their machine in less than 10 minutes; an activity I see people usually give a full "week" to do.

This is just one example of being more productive with these tools. What's nice about vim are vim motions, they become extremely intuitive and all the supporting libraries, plugins, and other CLTs utilize these vim motions which makes productivity extremely nice.

If you want to see someone's workflow I'd checkout ThePrimeagen's video on his workflow:

https://www.youtube.com/watch?v=bdumjiHabhQ

Command line tools are great. Environment setup is great. Ansible is great.

I don't know why you are conflating these things with the editor one uses.

*Edit: Why the downvote? Tell me what I'm missing instead.

I didn't downvote.

Most of these tools I tie in with vim hotkeys to shoot off various things. For example, I use telescope to jump between different git worktrees using vim motions or when using tmux I have vim motions mapped to maneuvering around panes (tmux cmd + hjkl) or going back to previous window (tmux cmd + o).

I'm not saying you can't learn to use these tools without vim/emacs but in my limited work experience those developers that use vscode for everything tend to be completely lost when the terminal takes the fullscreen.

It's not about which keys you use to copy paste, or about the speed in which you navigate your text.

What the vim movements do is allow you to focus on your code without interruption. You can do everything without shifting your focus from the block of code you're currently editing. It's hard to describe until you've experienced it. I think it's just easier to get into and maintain a flow when the editor gets out of your way.

Our experiences differ with regards to the correlation. In my career I've seen a massive discrepancy between effectiveness of editor use and developer impact. Off the top of my head, save for one person (who used Sublime), every outstanding engineer I've worked with have either used vim or emacs.

I use VSCode with NeoVim as a backend.

https://github.com/vscode-neovim/vscode-neovim

I highly recommend this if you know vim keybindings and want an IDE experience.

Beautiful - I've been waiting for something like this since neovim was announced with enbeddability as a design goal.

My experience with this mode was frustrating, because these two don’t really get along. You should try, but don’t expect much of advanced vim editing like folds, visible marks, etc. It felt just slapped on top in too many ways.

I use this too. This extension used to work amazingly well for me, but lately it’s been troublesome. I switched to it from vscode-vim after it destroyed my undo buffer one too many times, and vscode-neovim was great. It was fast, and it seemed solid. Now though, it will randomly stay stuck in command mode no matter how many times I mash i or I or A or o. Other times it will make changes a few lines away from where the cursor is. I’m not sure what’s changed - maybe VSCode changes that the plugin hasn’t kept up with? Maybe the rust-analyzer plugin is messing with it? - but it’s been a real bummer to not be able to trust that the editor will do what I tell it, and I’ve been thinking of switching to something else. I’m not sure if there’s anything better, though. (I mean, real vim would work better, but I do really like rust-analyzer)

I’ve run into that issue with the incorrect line changes. I think that’s a sync issue between neovim and VSCode. I usually switch to another VSCode tab and back and it goes away. It’s disruptive, but I can live with it. I’ve tried many other vim emulators in IDEs, I’ve even tried going back to vim and neovim, but overall I just prefer the VSCode extension system and these bugs.

I got further with spacemacs, it has a lot of stuff that’s sorta batteries included but you can still use vim bindings. I still just use ideavim in pycharm and webstorm but I have been slowly exploring some things like magit and org in spacemacs.

I tried hard to convert from my IDE to vim. I write PHP and rely heavily on for example EA inspections, there is no way to get these in vim. You can do some analysis with either psalm or phpstan, I forget, but in any case that was a show stopper for me.

What IDE are you using? Almost all of them have either vim mode or a vim plugin. I love vim, but I almost never use it directly. I usually use JetBrains IDE with vim plugin. Best of both worlds.

You might like prepared Vim frameworks then, like SpaceVim which was recently on HN [0].

[0] https://news.ycombinator.com/item?id=31986851

LunarVim may be what you're looking for.

I tried the same a couple of month ago and I came to the conclusion that VIM will never come close to editors like VS Code.

How is it that nobody seems to know that every major editor has either vim mode or a vim plugin. I love vim, but I almost never use it directly. I usually use JetBrains IDE with vim plugin. Best of both worlds.

How many times have you pasted this as a reply?

What are you doing, <C-r><C-p>0 ??

I guess many of us have tried but don’t like the “uncanny valley” where standard Vim thing don’t work.

It’s been a few years since I last tried so hopefully this has improved. I tried the vim plugin for Jetbrains and found it lacked window navigation and support for things like registers that I use a lot in vim.

At the time I was using webstorm (at a client’s insistence) and found that for the weird JS project we were working on Tern.js was actually better at refactoring and navigating anyway so I just went back to using it with Vim.

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.

Oh man, you are going to get a ton of replies on this.

Short version: vim is not vi.

Longer version: I use vim because I am way faster with it than any standard editor. I personally barely customize my vim at all, but there is a large community whose hobby is installing dozens of plugins to turn it into a full IDE and/or making it a highly personalized experience.

Neovim is pushing the text editor space like nothing else.

I've used a great many editors/IDEs and within a day of installing any vim mode or plugin I find multiple inconsistencies or errors that make my life worse.

Exception being spacemacs/evil, which is why that's the only thing I prefer using over vim

Normal mode navigation, macros, (mostly because I end up editing a lot of repetitive old code), and marks so far. Using vim for vscode enables me to much more quickly bang out code.

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!?

> What did you use your smarts to create a modal editor while choosing the worst key ever to switch modes!?

I believe when vi was originally created, the Esc key was often placed to the left of Q, where the Tab key is now located on QWERTY layouts.

You could also just press the Alt key on some systems, which sends the control code Esc.

Correct; vi was born on this layout: https://en.m.wikipedia.org/wiki/File:KB_Terminal_ADM3A.svg (see https://en.wikipedia.org/wiki/Vi). Notice the arrow keys, and Ctrl and escape. In this case, the history of the program basically explains everything in my opinion.

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

Definitely try out the free resources for learning vim before ever considering Vimified, or any paid option!

I used vimtutor and openvim to get started, and they're fantastic free resources.

It was only when I couldn't find something to fix my specific problem that I stated in the top comment, did I start building this.

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.

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

I can't really understand whether you recommend Vim itself or not, because of these sentences:

> Vim forces you to glue together lots of inefficient commands to manipulate text

> Vim’s nasty bells and whistles you need to actually be efficient at manipulating text

I’m a power Vim user. I do not recommend it for code editing. Learn it as a curiosity if you want. It’s also handy for quickly editing over SSH. IDEs with multiple cursors are so much nicer than Vim.

cool, that's a really useful opinion!

Perhaps I'll stick with VS Code over SSH, then

There's no reason to be snarky.

Wasn't being snarky.

This is odd to hear because the general consensus online is that vim/vim motions makes for seamless text editing.

I also feel like multiple cursors is an antipattern, you don't need multiple cursors in vim. You need a macro, which is easy to make and you can pass this to a buffer to modify it or apply it to certain lines or the entire file.

Personally I love Vim’s visual block editing and use it a lot too.

Macros are more flexible but visual block works well in a lot of situations.

Either way if one was really tied to multiple cursors Vim and NeoVim of course have plugins that support it. I don’t bother with them myself.

> I don't bother with them myself

This makes senses, because these plugins are terrible (I've tried them), and if you had used them you wouldn't suggest them as an option.

Vim macros are OK, and better than multiple cursors in the minority of situations.

If you record a long macro, and you make a typo in the middle, do you know how to edit that typo in the middle of the macro? You probably don't*

The answer is you past the macro contents into the buffer, edit it, then yank it back into the macro register. Do you know how to properly yank this so characters are escaped properly and you don't copy the line break and put it in the right buffer? You probably don't*

Do you know how to make this processes easy to iterate on so you can trial and test macro changes each time you modify the buffer? You probably don't*

* This isn't meant to be a dig at you, it's based on my experience with other Vim users. If you know how to do all of this, shame on me.

Most Vim users I see manually go back and try to re-record the whole thing, or don't know how to use macros in such depth.

Either way, none of this matters. These are Vim problems only. Multiple cursors are so much nicer, partially because they give you instant feedback, and trivial undo. The only thing I've missed from macros is manipulating numbers, and VSCode plugins that increment in multiple cursors solve 90% of that want anyway. It's so nice not to have editor problems (aka "how do I edit this text in Vim"?) and instead just use the editor seamlessly.

> This isn't meant to be a dig at you,

That is, of course, how it comes across, although a fairly mild one. If it's not meant as a dig then I would suggest generalising the phrasing to something like "many people" so that it's not direct at me.

As it happens I do know how to copy and edit registers. It's actually something I rarely need though because I can do most multi-line edits using just Vim's visual blocks. That's out of the box with no plugins.

I only mention multi-cursor plugins because they illustrate that Vim/NeoVim can and will be taught to every new trick over time, which is one of the nice things about an actually open source editor.

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

Thanks for asking, I initially had them like you suggested but with the way I was doing it, it made it kind of hard to make responsive. For the hero especially, the words didn't line up without lots of adjusting.

I'm not really good at css though, so there's that.

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.

Do what makes you happy, but just in case you weren't aware, vim supports editing over SSH natively, so there's not really a need to skimp just because you need to edit files remotely, you can use your local machine's setup to edit remote files. The SCP incantation is `vim scp://user@myserver[:port]//path/to/file.txt`, or see `:h netrw` or various tutorials you'll be able to find.

Ooh I didn’t know this. Thank you.

Two suggestions:

1. Prefer sftp over scp whenever it's available. The scp protocol is pretty obsoleted. Just substitute `scp` with `sftp` in the command.

2. Turn on ssh multiplexing to drastically shorten the wait time when opening a file.

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?

I see, I could add a whole chapter on useful vim plugins! Thanks for the suggestion!

In addition to surround, what other plugins do you think beginners should almost always use?

I think surround is so deeply nested in users workflow that it's almost like an official one. It's the only one i'd go as far as to adding it to your course, but potentially you could think of a chapter on vimrc, which skyrockets your productivity (but is also quite advanced)

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

Thanks for the feedback! The 8 lessons you mention are actually 8 chapters.

There are actually 34 lessons right now (you can see the lessons if you click on the chapters to expand them).

Please let me know if there are topics that you want to see, I wanna add what people want to learn!

Sorry, I meant 8 chapters. I read through the 34 lessons. I suggest you take a look at typingclub. 700+ lessons free of charge. Repetition, and metrics are the selling point. If you incorporate that model in vimified I think you’ll have way wider adoption.

Thanks for the guidance! I'll look into how typingclub works, I'm new to this business stuff.

After reading Practical Vim by Drew Neil I went to his site to check out what else he has. Well he's selling a course that looked like the majority of what he's covered in the book. When I saw the $150 price tag I couldn't believe my eyes.

I left the site and bought his other Vim book instead.

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.

Mind sharing what professional background you came into programming from? I find such info always interesting.

A little late to reply but yes I am always happy to talk about this kind of thing. Unfortunately the reality is that my story is not in any way interesting; I didn't start off as a railroad engineer or 2nd grade teacher or anything like that. I started in graphic design in the mid-2000s, got heavily into Web 2.0 and was one of those designers that did skeuomorphic designs delivered in .PSD format with the Lobster font and realistic metal textures and all of that. I've been in UI/UX design sense, and still technically have a role in a design department, but I write code full time. It's an interesting niche to fill and the pool of competent technical designers is growing all the time.

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

Hi, I understand where you're coming from. My introduction to vim was through vimtutor and it was free!

I agree with your point about muscle memory. Learning !== muscle memory. However it does make it more comfortable to edit code by not having to expend energy remembering the vim command to do something (since you can just focus on editing code). Practicing new vim commands in the interactive editor has helped me use them faster when coding. I feel that my muscle memory is built faster when practicing in a targeted way.

The interactive editor aims to bring the skills you develop while practicing in it, into your daily code editing, by making you practice on code snippets (for all the lessons after the first 2).

In addition, in my opinion, vimtutor and :help are slightly difficult for a complete beginner to parse because they overwhelm with a little too much information. I tried to fix this by making each lesson focused on a single topic, with short and simple explanations.

Thank you for your feedback, I appreciate it!

> The interactive editor aims to bring the skills you develop while practicing in it, into your daily code editing, by making you practice on code snippets (for all the lessons after the first 2).

If only Vim itself was an interactive editor.

> In addition, in my opinion, vimtutor and :help are slightly difficult for a complete beginner to parse because they overwhelm with a little too much information.

Except I mentioned :help user-manual, which is built-in and offers a very gentle, progressive, learning curve. Not overwhelming at all.

Vimtutor only introduces the basics and :help, assuming you mean "the reference manual" as opposed to "the user manual", is not suitable for the first steps of learning at all: most of it is really just a reference for when you are not quite sure about the specifics of a command or function.

> I tried to fix this by making each lesson focused on a single topic, with short and simple explanations.

Not much more than the user manual, then, and judging by the lesson titles, quite less.

Agreed with your comments on muscle memory and very cool project overall.

An issue keeping me from wanting to use this: holding down the directional keys doesn't move the cursor multiple times - it's one keypress per movement. In the desktop environment, one can hold 'j' to go down, and since there is so much vertical movement, it's important that that's replicated.

Huh, thanks for letting me know, no one else has mentioned this issue, and I haven't experienced the issue either.

Can you let me know which browser and OS you're using? This seems like an important bug, thank you.

Thanks for being so responsive - I'm on Safari version 15.3 (17612.4.9.1.8), on Mac OS 12.2.1 (21D62)

Hey I'm on a mac too, but I can't seem to reproduce the bug. Perhaps there is a safari extension, or a native application that is interfering?

Sorry I wasn't much help, please let me know if you've found a solution, I'm curious what caused this.

It's a Show HN. OP's just sharing something they've been working on that they find interesting. No need to dump on it over and over.

>Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

https://news.ycombinator.com/newsguidelines.html

I kind of get where they're coming from, but I hope all my messages in this thread have made it clear: If you want to learn vim, please try all the available free resources before considering vimified, or any other paid option.

I used vimtutor and openvim and they were great starters!

It was only when I tried to find something to fix my specific problem that I stated in the top comment, did I build this.

> A good critical comment teaches us something.

> learning Vim has nothing to do with muscle memory and doing it outside of Vim is pointles

He fairly expressed his opinion of the OP's project. I don't agree with this opinion, but let's not be such snowflakes. The commentator did not insult the creator.

I don't think it's constructive feedback in that it doesn't give anything for OP to do except just give up.

johncoltrane gave the same feedback last time, so I don't see how this is supposed to be helpful to OP. [0]

[0] https://news.ycombinator.com/item?id=31832423

OP is pretending falsely to help people "master Vim" via repetition. I'm using the same strategy to steer people toward better ways to learn Vim, without the lies. OP doesn't need help, it's the potential victims of that scam that do.

I think "lies" is a bit of an exaggeration.

Again, I'm not gonna defend the opinion because I disagree with it, but johncoltrane can give his feedback as many times he wants to, and I think his feedback can suggest to change approach to the problem, not only to give up. He didn't said OP should just give up, so don't put words into someone else's mouth.

Plus I think it's great that he's suggesting to all readers free alternative for learning.

It’s a repost. don’t post it over and over :)

> learning Vim has nothing to do with muscle memory

See this definition for muscle memory from Wikipedia:

"Muscle memory is a form of procedural memory that involves consolidating a specific motor task into memory through repetition, which has been used synonymously with motor learning. When a movement is repeated over time, the brain creates a long-term muscle memory for that task, eventually allowing it to be performed with little to no conscious effort. This process decreases the need for attention and creates maximum efficiency within the motor and memory systems. Muscle memory is found in many everyday activities that become automatic and improve with practice, such as riding bicycles, driving motor vehicles, playing ball sports, typing on keyboards, entering PINs, playing musical instruments, poker, martial arts, and dancing."

I don't see why Vim commands would be any different from typing on keyboards, or playing a musical instrument. They are tactile, and rely on motor control.

> and doing it outside of Vim is pointless

I see no reason at all why this should be true. Does the tool let the learner use keyboard to practice memorizing the commands, and they produce the exact same effects as inside Vim? If yes, then by what claim do you say it is pointless? A claim that this tool isn't "the real Vim" feels like a "no true Scotsman" fallacy.

This whole comment reads like sour grapes. Are you mad that it isn't free? Just come out and say that. Perhaps reference Socrates, and how he was angry at the suggestion he charged money for education. Or just point out the free resources and leave it at that. No need to attack him so strongly.

And before someone else says it, yes, I wrote a book about Vim, and no, it isn't free ;)

> I don't see why Vim commands would be any different from typing on keyboards, or playing a musical instrument. They are tactile, and rely on motor control.

They are not tactile and they don't rely on motor control. It's typing them on your keyboard that is tactile and relies on motor control. I make use of muscle memory to type these words, not to decide what to type. Learning Vim is learning how to decide what to type, learning how to type it or to type it quickly is just learning typing.

The "memory system" mentioned in that quote is definitely involved in learning and using Vim but the other "system" mentioned, the "motor system" only deals with _typing_ things. The real hero, here, would be the "language system" in charge of assembling commands.

> I see no reason at all why this should be true.

And yet it is.

> Does the tool let the learner use keyboard to practice memorizing the commands, and they produce the exact same effects as inside Vim? If yes, then by what claim do you say it is pointless?

The learner can do all that within Vim itself so why do it outside Vim, which is freely available and comes with an extensive yet very approachable tutorial that goes way beyond what is offered in those online knock-offs?

Again, the tool in question only seems to cover very basic topics that are not going to help anyone "master Vim" anyway so why bother with it at all?

And again, learning Vim, let alone "mastering" it, has nothing to do with muscle memory and rote learning at all.

Vim itself comes with everything one needs to learn it. Learn Vim in Vim.

> Are you mad that it isn't free? Just come out and say that.

Well, I noticed that it went from $25 to $10 between posts. Who knows? Maybe it will be free by the third repost? Whatever the cost, the claims are false and there are much better ways to learn Vim anyway.

> No need to attack him so strongly.

Persons curious about Vim don't really need to be fed outlandish claims and promises one can't deliver either.

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

Is editorconfig any use there? It definitely makes life easier on projects where the contributors have a mix of tools.

https://editorconfig.org/

If I was in the lead perhaps.

How does yours compare to shortcutfoo.com?

Thanks for asking, I actually have practiced vim on shortcutfoo.

It is really good for remembering shortcuts for regular desktop applications, but I felt that it wasn't really meant for learning a code editor like vim.

It did not have an interactive code editor, with the ability to edit lines of code inside of it. In addition, it does not measure progress in terms of speed and # of keystrokes, so you aren't able to see how you could improve. If I recall correctly, it is just meant for remembering the command keystrokes and typing them out (kind of like using flashcards).

Also, as of right now, shortcutfoo is $8 monthly, but it allows access to all shortcut courses.

Please correct me if I'm wrong, I used shortcutfoo a few years ago.

So, did it help you finally learn Vim?!

Yes, in a narrow sense. I would say I know it well enough now to edit code faster than using a regular editor.

It would be difficult for a lot of people to say they've fully learned vim though, since it has a lot of things to discover. Many people who've been using vim for years still find out new tricks. This aspect of vim is appealing, in a way.

vimtutor is pretty good!

Besides that once you learn that you enter edit mode by pressing i - ESC to exit it. :w to save, :q to quit and :q! to force quit / quit without saving. Then you can get by just fine.

You can of course do magic with vim, but that's more in the tinkerer territory~

IMO one of the best ways to learn vim after the basic movement is to copy others vimrc and build your own using vim. Use :help or :h along the way. vimrc is fairly simple to edit compare to actual programming languages.

Tried to register using my `.dev` email address: "Invalid email"

Hey, sorry the landing page is a little unclear.

You gain access with the email you use to purchase (the buy button is all the way at the bottom, which I could with improving its location). Thanks for letting me know!

Ah, that is not clear. It should say "account not found" at least instead of "invalid email."

It's visually appealing. I really like the web design.

Congrats!

This looks interesting.

I also paid for https://vimvalley.com/ and am a satisfied customer.

Hey, I have started using the course yesterday, opened just now and my statistics are gone... Is there a way to report a bug?

I write C# three days a week. Is learning vim worth it?

Yes I would say. Most IDE's support vim keybindings via plugins. Vim kingbindings with the convenience of and IDE results in an powerful experience.

Nope. If you're already comfortable in your code editor of choice and like it, there's no good reason to switch.

However, if you've seen people use it in real life or in youtube videos, and think that it's cool being able to execute precise and fast commands without needing to move your hands from the keyboard, to edit code exactly how you want to, definitely try it!

If you plan to code for many years, it's definitely worth it. But it has a steep learning curve. It could take you a few weeks before you feel like Vim is not actually slowing you down. But past that point, you will continuously gain productivity and will eventually refuse to use anything else. I've been using Vim for almost a decade and I'm still learning new tricks that boost my productivity.

Love it!

Thanks! If you wanted any features that are missing, let me know!

Anything like this for editing in Emacs?

This is the wrong way to go, if the UI is so bad it requires a course, then the problem is clearly the tool.

It can also be a boon. One of the things some vim users like is always being able to discover something new, after using it for years.

I'm not really in this camp though, I would prefer vim commands to somehow be more "discoverable".

Much easier said than done, though.

What were the last three things that you discovered in your editor?

In Helix:

- space, k for documentation on the thing under the cursor

- space, [yp] for copying/pasting to the system clipboard

- m, [ai], [acfo] for selecting around/in language structures

This is easy because Helix has a very fast command palette thing, and a lot of its commands are behind consistent prefixes, so if you know `mi(` for selecting within parentheses, you can do `mi` to ask "what other things can I select within?"

This is a wild take. I'm not quite sure how you would go about changing it into something "better" without funadmentally destroying its functionality. The "UI" of driving a car or a jet requires "a course" but it doesn't meant that they're bad.

What a strange comparison. Driving an (automatic) car can be learned through trail and error in no time at all. It's the external factors like other traffic that are hard to get right.

vis is a step in the right direction, at least in terms of modal editing.

You're just assuming that one set of optimisations are the most important for everyone in UI design. Good UI design doesn't state that it is always the case that people should be able to use it intuitively. Sometimes enhanced performance, speed, and focus over the long term are optimised over intuitiveness. This is the case for Vim. There is room in the world for both sets of optimisations.

I do not see how performance, speed and focus are a characteristic of vim. if anything, that's the one thing it lacks.

I think this is the wrong way to think about computing, though I sympathize, because I also used to think this way until I reflected on a podcast I'd heard about how when the computer mouse was invented, it's little known that a second very sci-fy-y device was also intended to be used as a peripheral, one which you put on your other hand like a glove and moved in all sorts of ways in order to direct your computer. Ultimately this device didn't catch on, but it's not necessarily the case that just because something isn't trivial to start using that it's bad -- on the contrary, both kinds of tools are useful.

Tools which are eminently transparent in how you use them are great to get started, and to continue with if you don't want to spend any more time.

But so are tools which you need to actively invest effort into using. These can unlock ways of using something which are more powerful and rely on the time you put in to learn them -- true for a computer, but there are plenty of other devices in the world where this is the case too.

I take it you're not a musician?

Or a pilot. Or an artist. Or a mathematician. Or basically anything difficult.

This is the price we pay for having easy-to-use computers. People have developed an expectation that everything should be easy and if it's not easy for beginners then it's bad.

Some things are just hard! That doesn't make them bad. Some of the best things in life actually take years of study to learn.

Nice of you to give mathematician as an example, considering we no longer do math with roman numbers.

Artists will do what they do, just for the hell of it. given that art is expression, doing something hard like painting with your toes could be considered art.

The key is simplication, and its something I notice programmers refuse to allow in their profession.

Plenty of musicians made it big with easier to use tools many people made fun of. like fruity loops. more intuitive interfaces is not a demerit, it was the point all along.

Good UI is not always optimizing for beginners.

If you're using a tool for 8 hours a day, everyday, for years, you won't be a beginner for very long.

The program must be optimized for the people who are going to use it for thousands of hours. Not for the users who are heard about vim yesterday.

Hard to learn doesn't mean good.

Which code editor does NOT have an online course on how to use it? Go ahead, type "IntelliJ course" or "VS Code tutorial" and see hundreds different videos.

The problem is how much time do you HAVE to sink into just to learn a tool? If you have a tool with the same functionality and requires less time sink, then the previous tool is obsolete and should be tossed away.

How do you reconcile that with Vim's massive popularity? Surely, Vim users are aware that there are many "easy to learn" editors.

I don't, I belittle it whenever I can. but I'm just a stranger on the internet. pay no attention to me.

Invalid email

On it!

Edit: hmm, can't find any errors. Can you reply with the first 3 letters of your email? You can also contact me via the email located at the bottom of the page.

got it, need to pay before login

I've been using Vim since 1994, but only this past year have I started getting better at juggling large numbers of buffers. There are three main improvements in how I use Vim compared to before and they are simple.

1. I switched to :autochdir, so that in any buffer, the current working directory is that of the file. Then I dumped :autochdir due to certain annoyances and found a nice way of emulating its good behaviors.

2. I started using sessions to save and recover the states of the buffers. I associate sessions with certain tasks and can return to those tasks quickly.

3. I started using a buffer navigator.

Regarding (1) here is the setup:

  :let $top=getcwd()
  :au BufWinEnter * exec "lcd " . expand('%:h')
  :au BufWinEnter * if expand("%") == "" | exec "lcd $top" | endif
  :au BufWinEnter *.git/* exec "lcd $top"

I know you don't need the colon in your vimrc, but I have it anyway.

The $top variable captures the top level directory on startup; I refer to it in command lines when I need it using $top. Why the dollar sign? Ah, this makes it an environment variable. Vim is much better about interpolating environment variables than other variables; there are more places you can use them thanks to the dollar sigil.

The other three commands above set up a local chdir (lcd) to the directory of the file containing the buffer. The third rule is smart: if we are editing something under .git/ then we go back to the top. This is what autochdir gets wrong. What do we edit under .git? Oh, COMMIT_EDITMSG, for one thing! I want to be in the repository root when editing a commit message.

Regarding 2, here is my setup for working with sessions:

  :nmap + :wa<Bar>exe "mksession! " . v:this_session<CR>
  :command -nargs=1 S exec "mksession! " . expand('$top/') . expand('<args>')

+ becomes a command for saving the current session. Then I have a :S <whatever> command to save a session under a new name, relative to the top directory: the $top variable rears its head.

Regarding 3, there are many buffer navigators. I'm using bufexplorer (version 7.4.32). I make the following tweak to the plugin/bufexplorer.vim file:

  " added before the other maps

  if !hasmapto('BufExplorer') && g:bufExplorerDisableDefaultKeyMapping == 0
      nnoremap <script> <silent> <unique> <Leader>\ :BufExplorer<CR>
  endif

In Vim the "leader key" for hot key commands is backslash by default. Instead of using the default key binding for launching the bufexplorer view, which is like \be or something, I map the backslash key to do that. So just by hitting \\ (backslash twice) I get the buffer explorer.

Mostly I use the LRU view in buffer explorer (most recently used buffer goes to top, pushing others down). Should be called MRU, but everyone who knows memory cache hierarchies understands LRU.

The above three things are very simple, and have a big payoff. I have many more tricks in my vimrc. For instance I use a C program called autotab to analyze a sample of lines from the loaded file and adjust the indentation settings.

I tried out vim for a month or so. I did enjoy using it, although I'm not sure if using vim just feels more productive because you press more keys to do the same thing. However multi-cursor editing and cutting whole lines in modern editors is way more conducive to my workflow and eventually stopped using vim.

Do vim users know if there was anything like Select next occurrence in vim? Feature discovery is not one of vims strong suites

EDIT: More specifically by multi-cursor editing I mean selecting multiple occurrences of a word, and then editing in place. For example selecting all occurrences of the word user -> (getUser, setUserId, variable declarations with user) and then replacing them with account. This can be done with vim but is nowhere near as fast, since every change needs to be done one-by-one. Or selecting all the above occurrences, and pasting them somewhere for an interface declaration.

If I'm interpreting "cutting whole lines" correctly, in vim that's "dd" in normal mode. Then you can paste (put) with "p".

I agree discoverability is not great; to be honest I can't remember how I discovered the plethora of commands I use, though I do have a habit of reading the help a decent amount. That's how I discovered "g?" (Rot13) :D

Oh yeah I did use "dd" and "p". They work OK, although they don't allow selecting multiple lines that don't follow each other.

Just use the number of lines you want to cut like 3dd This is consistent for all commands.

> they don't allow selecting multiple lines that don't follow each other.

3dd won't work. You can use registers, though:

1. "ayy for the first line 2. "Ayy for the subsequent lines (repeat using .) 3. "ap to paste.

You can replace a/A with other letters to copy into multiple registers. If there are patterns (e.g. odd lines to A and even lines to B), you can even record a macro.

I think registers are not something most Vim users use, however. I have no data to back this up, but I wouldn't be surprised if Vim is like Git, where people learn the commands for 80% of scenarios and Google the rest. In Vim, case, they might even settle for a very inefficient solution if the problem is not recurring.

What’s the use case for this disjoint selection?

Yep. I use the VIM extension for Vs Code. I do a CMD-SHIFT-P -> Disable Vim whenever I need this functionality. Not sure if there's a better way to do it.

No need to disable it, the feature is mapped (by default) to 'gb' (in the extension not in vim)

> Do vim users know if there was anything like Select next occurrence in vim?

You can press '*' in normal mode to search for the word under the cursor.

I use / to search by a string (or press * while my cursor is on a word to search for that word), then press n or p to go to the next or previous. cgn changes the matched text, and you use . to repeat the change, so to change a word over all occurrences I just cgn once and repeatedly press “.” .

Yeah this is the way I tried it. I did not find as fast.

I just select a block of code (visual mode) and use sed syntax, much faster than worrying about multiple cursors, etc and it works fine for me.

This article might go a bit over your head if you just started using vim, but I found it to be very helpful for typical multiline/multifile editing tasks in vim: https://bluz71.github.io/2019/03/11/find-replace-helpers-for...

I am aware that I could extend vim with all the missing features, but that seems error-prone and not worth the time investment, since other editors have them out-of-the-box.

Nowadays I have almost the opposite feeling of it not being worth my time and being error-prone to take up with some editor gui when my terminal already gives me an editor that does everything I want from it and in exactly the way I want it.

But I remember having your stand point when I first started to try to get into vim and getting to where I am now definitely took a lot of invested time. Wether the advantages of vim are worth your time you have to decide for yourself and it seems like you did that already.

Vim has visual block mode for multi cursor which you can enter with ctrl-v

Yeah that works for selecting contiguous blocks of text. Multi-cursor editing allows for selecting rows that are further apart.

vim-visual-multi works well.

https://github.com/mg979/vim-visual-multi

I do wish it was built in (like in vis) though

https://github.com/martanne/vis

> selecting multiple occurrences of a word, and then editing in place

I'm sure there is a way to do this More Properly, but the kind of thing I'd do is:

:%s/user/account/g

:%s/User/Account/g

If you wanted to check each one interactively, end with gc instead of g.

Vim is the reason I'm real confident with regexes, even nonsense with grouping and quantifiers etc. etc., and while I can see people not wanting to have to acquire that power, I must say it's also very handy outside of text editing.

> selecting all the above occurrences, and pasting them somewhere for an interface declaration.

I don't really understand the behavior desired here, but I'll bet there's something similar.

What about traces.vim?

https://github.com/markonm/traces.vim

You can search & replace all occurences of a word with the substitute command.

Type : and write `%s/user/account/g`.

Although you won't get a real-time preview and will only see the changes after they've happened, unless you use a bunch of extensions(I use nvim).

> Although you won't get a real-time preview and will only see the changes after they've happened, unless you use a bunch of extensions(I use nvim).

In Neovim, you can just :set inccommand=nosplit (actually, it's the default now).

> Do vim users know if there was anything like Select next occurrence in vim?

As noted in a sibling, you can press * (shift+8) in normal mode with your cursor over a word to find the next instance of the word. This also updates the search pattern so you can use n and shift+n to navigate forward and back between matches.

If you combine this with other bits of the vim "grammar" (which I do think encourages a kind of feature discovery, although I agree there's a large learning "hump" to get over to take advantage of it), you can use something like cgn to change the currently-focused search match, n to navigate to the next search match, and . to replay the command.

So while it's not exactly the same as multi-cursor, you can achieve something very similar (and just as fast) with the following sequence:

  1. In normal mode, place the cursor over the symbol you wish to edit
  2. Press key: \* (read: "find the next occurrence of the current symbol and update the search pattern to be that string")
  3. Press keys: cgn (read: "change the search match under the cursor")
  4. Type the new symbol
  5. Press ESC to return to normal mode
  6. Press keys: n. (read "find the next occurrence of the search pattern [set in step 2] and repeat the last command [the edit from steps 3-5]")
  7. Repeat 6 until all symbols are replaced

Or, in raw keystrokes, I might replace all six "foo"s in a document with "bar" by typing the following sequence of characters (having placed the cursor over a "foo"): *cgnbar<ESC>n.n.n.n.n.

It may seem complex compared to something like multi-cursor editing, but the nice thing here is that there are concepts here that are extensible beyond the scope of that specific edit, and can yield similar "speedy" workflows but on a much wider set of tasks.

- c[something] is a pattern that means "change [the given region]", so you could construct similar commands with different regions (`ciw` to change inside the current word, `ca{` to change the current curly-bracketed region (inclusive), and so on)

- [something]gn is a pattern that means "[do something] to the next search match", so you could delete it with `dgn`.

- . can replay many types of commands, so if I have a more complex sequence of edits to apply starting at a search match, I could do that too (not just simply replacing the symbol).

It's a very powerful paradigm.

Reply on news.ycombinator.com