So, the first motivation for using vim is that you think it's readily available everywhere. However, the first thing you explain to me is how to remap the Esc key. That is definitely not something configured everywhere.
For beginners with vim, just leave the Esc key as it is. It is way simpler to grasp the modes if a single key is required to switch. Also, you can just hammer a single key multiple times to get back to normal mode at all times.
Mapping keys are an advanced topic. That is not the first thing you should start with when explaining vim. Unexperienced users will not understand the significance.
> "So, the first motivation for using vim is that you think it's readily available everywhere. [...] That is definitely not something configured everywhere."
The aversion to custom settings is a rather uniquely "vim thing" (emacs people don't seem to do it), but I've never understood why it is a thing. I am probably temporarily annoyed by my missing custom settings once every year or two at most.
Most machines I work with get my vim config lazily loaded as I use them. Where that isn't feasible/possible/permitted, the lack of my custom color scheme flips a bit in my brain and I naturally use the compat feature set.
Custom settings not being ubiquitous is an objection that makes sense in theory, but it just doesn't seem to be an issue in reality to me. Honestly I have more trouble with ~/bin
Right, but even if that is your reasoning, the objection does not hold if you observe reality. In reality, even ubiquity is a reason you use vim, custom settings aren't damaging.
After using vi / vim since 1986, I finally remapped CAPSLOCK to CTRL at the operating system level. It's made a world of difference, and not just for vi. It easily unlocks all the EMACS style cursor movements like ctrl+A, ctrl+E, etc.
Yeah, I know you can do it with the CTRL key in the lower left. But if you move from Mac laptop with Fn key in lower left, to an external keyboard with no Fn, you're gonna have a bad time.
But here's another reason why I advocate this approach. Remember vi was written by Bill Joy back in the 1970s. Back then, the early terminals had the control key right there next to the A. In fact, the CAPSLOCK was to the left of that!
I was recently at the Computer History Museum in Mountain View where you can see some of these early terminals. A lot of us know the Happy Hacker Keyboard, with the control key at it's rightful place. But to see it on the old terminals, it's a pretty good archeological insight into why it just feels right.
Plus, WHO USES THE CAPS LOCK KEY ANYWAY EXCEPT FOR SHOUTING IN FORUMS?
I often use Caps Lock for acronyms, such as HTML, CSS, IntelliJ IDEA, and ad-hoc acronyms for book titles in notes. I do remap Caps Lock to Ctrl when I use Windows, because Windows requires Ctrl for many keyboard shortcuts, but I also make it so that Shift+CapsLock activates caps lock, so I can still use it.
Stuff like that is what various completion options are for. Ideally you only type crap like that out once, and for that typing with your left pinky on shift is sufficient for me.
Funny enough, I just installed a vim plugin that gives a mapping for converting variables between camelCase, snake_case, MixedCase, and UPPER_CASE. The plugin is vim-abolish by Tim Pope.
(This isn't really relevant to your post, just funny)
I use a Happy Hacking Keyboard which does this remapping in HARDWARE and it is awesome for nearly everything! You never need Capslock, but Ctrl you use all the time and having it basically on the homerow feels great.
For me a big discovery in Vim after two years of active use were <C-i> and <C-o> in normal mode. They allow you to jump between your navigation history. Allows you to edit a piece of code. Search for something else in the same buffer and go back in one stroke. Useful if you lookup documentation or often "jump to definition". Works across files so you can "git grep", iterate through the result list and go back to your editing position.
As always, what loses me on vim is that I'm not sure what's the easiest/best/common way to have a "project directory" open and quickly open one of the files inside that directory... no basic tutorial seems to tackle this, yet it's essential to migrate from any other editor you use as a programmer...
You want CtrlP - it's a plugin that works basically the same way as Sublime Text's Cmd-T.
If you want a more familiar Sublime-esque experience, you can also rebind it from Ctrl-P to Cmd-T (which is how I personally use it).
So my workflow on a Mac is to type `mvim ~/project-dir-goes-here` and then press Cmd-T just like I would in Sublime to start typing in a filename and see a list of matching files to open.
If it's C/C++ code I use ctags and cscope and just ":tag <function-name>" to go to the function definition (VIM will autocomplete the function name).
If it's a Rails project, there's a Vim Rails plugin and then ":Econtroller <controller-name>" opens the relevant file, etc.
It's also possible to keep a file listing all of your project files (Or just edit your Makefile if you use one). Then just switch to that buffer, search ("/<blabla>") for the file and "gf" (goto-file - opens the file whose name is under the cursor).
:e .
Will show a directory listing, you can navigate the directory tree and open files. Particularly useful if you have a shortcut to change the working directory to the current buffer's file path.
I have things set up to easily drop the output of a git grep into my quickfix buffer, so I can step through occurrences across many files in my project.
Perhaps beginners aren't in the intended audience, but as a cautious (Level 0) beginner to Vim, you lost me at the "Configuration" section. I appreciate your impulse to teach and I like the layout of the guide, so I hope you can massage it a little for a beginner like myself.
As an advanced vim user I have to agree. Just about everything in the "configuration" section could wait a bit, or is personal preference. At most to start with a .vimrc with the following is needed:
filetype plugin indent on
syntax on
set encoding=utf-8
Sean, I recently taught 16 high school juniors and seniors vim through two means:
- www.vim-adventurs.com. I negotiated an educational discount and rewarded kids points based on the number of levels they completed. A few of the kids actually completed all 14 levels. What teacher assigns game homework? I can say all 16 are using vim on a daily basis for Python with zero complaints. At least to me.
- vimtutor. We spent an hour on this one. It's an app that comes with vi. It really just launches vim with a text file that teaches you the basics.
One thing you might have already learned from Linux or maybe from playing Dwarf Fortress/Nethack is that you just need to roll with it even if its uncomfortable. Most things that are awesome are really hard to optain. And I don't mean that tutorial, I mean you should continue to learn Vim even if it feels hard just to get out of it! Thank me in 5 years. ;)
I'm not your audience at all, but a few ideas from that section:
* You refer to ~/.vimrc and ~/.vim with no prior introduction. Even assuming knowledge of "~" expansion is risky, and ignores Windows users.
* You mention a "self-managed Vim install" and Janus in passing. Who cares? It's confusing.
* Why am I remapping stuff I haven't used yet (<Leader>)?
* Why am I remapping <Esc> to `jk` (why would you suggest such a radical change for somebody just starting out?)
* Why do I care about CAPSLOCK?
* Pathogen? Github? What's going on? I thought I was learning an editor.
This is kind of a scatter-shot ... there's a lot of stuff that makes no sense unless you're already familiar with Vim, and with configurable Unix text editors' mode of operation in general.
I think it's a common mistake of people who want to teach anything, but I see it frequently in coding (probably because that is what I am trying to learn these days). That problem is usually articulate with this phrase: "Before you get started..."
Essentially, when I look for a beginner's guide, I want to start at the beginning. There is nothing before the beginning. If I need to plug something in, turn something on, or install something, I'd like to know how to do that. I exaggerate only slightly. For example, when I was learning to play the piano as a child, I started centered on the first note I played, which was a G, and arranged myself accordingly to accommodate my chosen midpoint, since no one had taught me about Middle C.
Oinksoft's points are all crucial. You're clearly knowledgeable, but those details are beyond the scope of my understanding for a Level 0 beginner, so if they are essential, they need to be broken down. If they aren't, then you can leave them out.
As a general rule for teaching anything, you should explain, demonstrate, and then solicit a student response or reproduction of the concept. I think the material you have here can be arranged such that it accomplishes these components, and rearranging it thus would make it easier for someone ignorant of the subject, like myself, to follow along.
I hope this is helpful criticism. I really like what you're doing and I'm excited by your attitude – 'basics to ninja' – because this is useful for preventing learners from stagnating. With some work on the beginner level information, I think you'll have a solid guide.
It could be better if I didn't have to follow links to other parts of the site in order to complete the initial tasks. Creates a lot of back-and-forth in the browser, and there will already be a great deal of that as I attempt to switch window to install, open a text editor, etc. However, the outline captures the suggestions I was trying to make above.
You make some pretty drastic changes that most people would never make until they get pretty acquainted with vim. I get the idea behind the changes because I had made some of them myself, but I learnt vim first.
You need to teach prospective vimmers about the native power of vim. The concepts of motions and nouns wayyy before you start finely tuning vim.
A beginner following your guide would be completely lost in a vanilla instance of vim…
As a long-time vim user I just recently made the switch to Emacs + Evil because of the excellent functional-language support Emacs has (with the slime plugin).
Vim users are used to the "modes" like insert, normal, visual. Coming from Vim it feels like Emacs is only in Vim's insert-mode. Having to press ctrl+key just to navigate the screen felt completely wrong to me. All the ctrl/alt keybindings just seems like a recipe for RSI.
However, with the Evil plugin, a Vim user can immediately use Emacs because you're editing with Vim keystrokes. Vim also encourages you to spend as little time in insert-mode, and there are very few commands in Vim that work in insert mode (to be honest, I never use them anyway)
So what you can do is you can tell Evil to drop Vim keybindings when you're in insert-mode (except for ESC) and then.. voila... you're back to Emacs keystrokes, but only while you're in insert-mode (which is what Emacs seems to be about anyway)
;; use Emacs keybindings when in insert mode }:)
(setcdr evil-insert-state-map nil)
(define-key evil-insert-state-map [escape] 'evil-normal-state)
This is the coolest thing ever if you want to learn both editor's commands, or if you're coming from the one/going to the other. (Yeah you can switch mode with Ctrl-z but this is "seamless" for a Vim user)
You probably also want the Evil-leader plugin so you can map things like ",f" to find-file and ",h" for help-command, etc.
In addition to those jbeja mentioned, there is also fiplr[1], somewhat in the spirit of ctrl-p, command-t etc. for vim.
One favorite tweak of mine for file finders like this in general: rewrite the dir listing to use "git ls-files -co --exclude-standard". This obviously only works in git projects (similar commands exist for mercurial I think), but is really fast and most of the time is exactly what I want.
vim emulation frustrates me to no end because it is never a complete emulation. Additionally, in emacs, there are many conflicting keybindings that prevent normal usage of using vim.
for someone like me, who is familiar with vim, but not-so-familiar with emacs, it would help if you would specify which features you are looking for more specifically.
My guess would be that if the features you want are available, they might not be packaged in the same way, so listing some key features might get you more answers.
I run Chrome with cookies (and local storage) disabled by default. When I visit the site, I only see the first two headings of a table of contents, and no actual tutorial content appears. Why does an information-only (non-interactive) web page require cookies and/or local storage to function?
Great tutorial. There's a mistake in "Getting things done" -> Moving within the Screen. It lists ^U and ^D as moving a full screen, which is not true. Those only move half a screen. You correct this a few line later... I think you just forgot to take it out.
The guide is a little off in parts, and that was one of the worst offenders. It assumes you're on the first line. Then, you have to hit Escape after typing the colon. Finally, the whole command depends on your having "vnoremap . :norm.<CR>" in your configuration, which I sure don't.
Thanks for that tip! I wandered in here hoping someone had already asked and answered and got my reward.
I mostly use emacs for the past 15 years, but I learned vi about 20 years ago and use it regularly at something approximating level 4, but only for vi (not vim) commands -- having no real knowledge of visual mode or some of the extended commands. One of the hard things about learning vim is figuring out how to search for help -- because "enable dot command in visual mode" (and variants) doesn't turn up anything useful right away. I know I've got the right idea (esp. when seen in a tutorial like this one) but there's some setting or plugin or subtle nuance that I'm missing.
For beginners with vim, just leave the Esc key as it is. It is way simpler to grasp the modes if a single key is required to switch. Also, you can just hammer a single key multiple times to get back to normal mode at all times.
Mapping keys are an advanced topic. That is not the first thing you should start with when explaining vim. Unexperienced users will not understand the significance.