Hey show HN!<p>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.<p>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!<p>Let me know what you guys think about it :)
This looks very cool, kudos on the launch!<p>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.<p>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".
<p><pre><code> :set nu
/ whatever you want to find [return]
i
*edit stuff and use arrow keys for nav*
:wq
Or :q to quit without saving
</code></pre>
That’s all the vim most people need.<p>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.
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?<p>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>I don't have to learn anything new</i>.
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.<p>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.<p>[1] <a href="https://www.vim.so" rel="nofollow">https://www.vim.so</a>
When I was learning vim, I decided to extend the existing vimtutor with some more programming specific tasks. You can find it at <a href="https://github.com/drodil/codetutor.vim" rel="nofollow">https://github.com/drodil/codetutor.vim</a> if you are interested :)
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.<p>(This is basically a copy-paste of previous comments I’ve made, I haven’t tried your tutorial beyond the first lesson.)
I once tried to migrate from VS Code to Neovim. I use TypeScript at work, and use many languages for my side projects.<p>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.<p>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>.<p>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.
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.
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!?
I am a designer that got fed up with "mouse" control everywhere.<p>One day I asked myself: Is there a way to scroll in the browser without using a mouse or arrow keys?. Enter Vimium.:)<p>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'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.<p>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.
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 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).
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.
> Let me know what you guys think about it :)<p>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.<p>:help user-manual is easy, built-in, and it goes way beyond this. And it's free.
vimtutor is pretty good!<p>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.<p>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.
This looks interesting.<p>I also paid for <a href="https://vimvalley.com/" rel="nofollow">https://vimvalley.com/</a> and am a satisfied customer.
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.<p>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.<p>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.<p>3. I started using a buffer navigator.<p>Regarding (1) here is the setup:<p><pre><code> :let $top=getcwd()
:au BufWinEnter * exec "lcd " . expand('%:h')
:au BufWinEnter * if expand("%") == "" | exec "lcd $top" | endif
:au BufWinEnter *.git/* exec "lcd $top"
</code></pre>
I know you don't need the colon in your vimrc, but I have it anyway.<p>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.<p>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.<p>Regarding 2, here is my setup for working with sessions:<p><pre><code> :nmap + :wa<Bar>exe "mksession! " . v:this_session<CR>
:command -nargs=1 S exec "mksession! " . expand('$top/') . expand('<args>')
</code></pre>
+ 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.<p>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:<p><pre><code> " added before the other maps
if !hasmapto('BufExplorer') && g:bufExplorerDisableDefaultKeyMapping == 0
nnoremap <script> <silent> <unique> <Leader>\ :BufExplorer<CR>
endif
</code></pre>
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.<p>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.<p>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.<p>Do vim users know if there was anything like Select next occurrence in vim? Feature discovery is not one of vims strong suites<p>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.