Interactive Vim tutorial
openvim.com
openvim.com
First, learn
:q!
h,j,k,l
i and ESC
:w
Most of the good stuff in vim, you'll learn accidentally, because you're in normal mode when you think you're in insert mode, or because you have caps lock on in normal mode and you don't realize it. Pay attention to the bizarre behavior that results and you'll learn useful tricks. Mode confusion is a feature, not a bug.
For the rest, there are certain topics that reward study and are unlikely to present themselves to you accidentally, but there's no hurry unless you're feeling the pain of not knowing them. I recommend:
1. Visual selection mode
2. Prefixing counts to commands
3. Search and replace with regular expressions
4. Advanced cursor movements
Lastly, if you're using gvim, do
:set guioptions=
Edit: learning to use x and d early on is probably also a good idea, if like me you're the kind of person who makes mistakes.
Then you realize that insert mode is the least useful mode there is.
http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressiv...
I'd add windows to your list of things to take a look at once you feel comfortable with the editor. You can split your workspace with ctrl+w followed by 'v' (vertical) or 's' (split). Then you can switch between those panes by pressing ctrl+w twice, or ctrl+w followed by hjkl or an arrow key. You can also resize the windows and stuff, it's great for things like viewing a header and source file at the same time.
For one thing, it doesn't give new users any positive experience or reason to learn vim. If all you learn is to do things that are "pointless" (like learning hjkl), then you won't get any value out of vim. And if your way of learning is to do something that screws up your file and try to recreate how that happened, well, let's just say that every time I do something that screws up my file I'm in the middle of working, and the last thing I want is to stop and fix some random problem.
I usually recommend people try to get into vim easily, then learn the GOOD things. I.e. I think it's perfectly fine that people start with arrow keys, much as I love hjkl. But to get value out of vim, you should really learn "f" and "t", and text objects, then how they compose with "c" and "d". That is the reason I started loving vim myself - that's when I saw that it gives me something that other editors didn't give me, adn that encouraged me to explore further.
- Vim is not newbie-friendly regardless of whether you remove guioptions or not. One has to spend at least a few hours of study and practice to get comfortable with Vim. If one is forced to invest a few hours to learn an editor, one might as well get rid of guioptions and follow other advice provided in sevensor's comment.
- Learning hjkl is not really pointless. hjkl and other motion commands makes Vim a unique and ergonomically a very superior experience. If one does not want to spend time learning hjkl and other motion keys, then one might as well skip learning Vim and pickup Emacs, Sublime Text or another capable editor.
On the other hand, if I want to show someone the "good parts" of vim, I try to show them something they can't do in another editor, rather than something that they can do (arrow keys). Even if I 100% agree that arrow keys are a worse experience, it's just not as convincing as something that can't be done outside of vim.
At least in my experience.
I've recently taken this approach to emacs and org-mode. I'm a long-time vim user with a super-optimized vimrc, so I know what productivity feels like. I threw in spacemacs to reduce the learning curve, but I still was initially much less productive with org-mode and emacs than with markdown and vim for my TODO lists.
Now, after using org and emacs for three weeks, I'm at the point where several of the amazing features that I had heard about are in my bag of tricks, and it feels awesome! But I've barely tweaked my .spacemacs file, have only learned a bit of org, and am sure that I am nowhere near peak comfort/productivity/flow. But if I had tried to learn all of the things that I know are cool about org-mode, emacs, and spacemacs all at once, I wouldn't have gotten any work done over the past few weeks, and honestly I probably would have given up.
TL;DR: the fancy stuff is the best marketing, but it's best to start slow.
I just feel like it's a thing that people don't realize will help until they internalize it. Whereas almost everyone I show the text objects to immediately realizes their utility. I'm only looking at this from a pedagogical perspective.
Assuming the new Vim user already knows how those work, telling them that they instead need to go `Esc -> hjkl -> i` and ending things there... that's going to leave them worse off in Vim than saying nothing.
I agree. For navigation I rather use f, w, e, {,}, ctrl-l, ctrl-u, /, o. I think hjkl are overrated.
Anyhow, I'd be really interested to know if you agree with this characterization of your outlook.
u is my favourite!
My hackles were raised when it starts with "ESC" to enter normal mode and "i" for insert mode. Rather than "i" for insert mode and "ESC" to get out of insert mode. Also, I used the arrow keys to move around in vim for ages before I disabled them.
Same with using 's'. Super handy when you accidentally type the wrong character.
I think i and Ctrl+[ is better? It's more in line with the idea of keeping your hands near home row.
Of course, then I bought a kinesis advantage2 keyboard and now suddenly every key is easy to press, even the cursor keys.
For me on Windows, GVim was the only sane option. Mostly because the Windows console can't fully handle syntax highlighting / italics. However it's also a good transition world. You've got all the power of Vim but quite a few of the commands you'd expect still work. I've practically never need them but it's handy to reduce the confusion / frustration
Put this in your $profile and you can open it just by calling "vim":
Set-Alias vim "C:\Utilities\vim74\vim.exe"
[1] https://github.com/brookhong/Surfingkeys
[3] https://addons.mozilla.org/en-US/firefox/addon/vimperator/
Personally I like the simplicity of characters-in-characters-out that comes with working with vim in a terminal. I also like to be able to exit to bash and do redirection trickery on my recently saved files. For these reasons, I avoid GVim.
MSYS2 (which uses MinTTY for its terminal) is what I use, and as far as I've noticed it supports all the bells and whistles that the windows terminal lacks.
I did spend a lot of time in Vim in DOS and loved the fact that it was even possible to do something productive there.
But I just started wasting more and more time on little details that didn't quite work.
It's even more frustrating when you compare to how perfectly it works in the Linux command line. Certainly in Linux I'll use regular Vim.
I've used very little of the GVim commands and got rid of the ugly menu so it looks like regular Vim.
But I have utmost respect for GVim for being forgiving and kind to a new user.
The tutorial succeeds if it gets people to have a superficial comprehension what Vim is about -- especially for those that have been putting off trying it out in a terminal. That's it. It doesn't really try to make you actually learn Vim.
As a tutorial it could be made so much better. I don't have the energy slots for this project. But I feel anxious when I get feedback because I feel like there's some moral duty to fix the site. The least I can do is to pay for the hosting so that people get to have a go with it as it seems some people like it.
Just to make clear: the Vim behaviour is modelled and is not just trivial precoding of keystream. There is a sandbox where you have contextual helper at the right side of the screen. You can play around with it to your heart's and battery's content. But it is merely a simplistic version of Vim.
Development-wise the most fun aspect of the tutorial was the DSL for tests. For some reason (haven't really updated the code properly in years) many fails. But click on the individual tests and you see something fun. http://openvim.com/tests.html See the corresponding code here: https://github.com/egaga/openvim/blob/87b9e1d62c4144c958ddf8...
The actual code is modelled operating on html elements. This was a fun side project, so please don't be too critical. It grew bigger than anticipated.
I was impressed with the high ratio of useful content to time spent, and how the full tutorial only seemed to take 10 - 20 minutes.
I'm a 6 or 7 year vim veteran, and your tutorial taught me I could combine numbers with commands. I didn't know that!
For anyone reading and scoffing, please don't think I'm some vimless noob, I know %s/regex/replacement/g visual block selection and edit mode ( ctrl-shift-v, cursor, shift-i, double esc ), split mode :sp, and so on, but I never knew about the numbers with commands, nor about shift-X for left of cursor delete.
So even as someone experienced in vim ( and who codes in vim for everything ), this has improved my productivity!
Thank you so much, a great piece of work. Hope you keep making more tutorials on topics.
I appreciate your support. Thank you.
Don't worry, you did an awesome job and the world is a slightly better place because of it.
On https://news.ycombinator.com/item?id=14658197 and its children I wrote something about the business model of VIM Adventures that you should consider before buying.
The only real shortcoming of vimtutor is that it cuts off before taking really advanced topics like buffers and windows.
I remember reading this beautiful essay Seven habits of effective text editing by Bram Moolenaar, the main author of Vim.
I like Vim adventures a lot. I think it's a better approach than this in a lot of ways.
It's simpler and better at imparting the minimum viable working knowledge of Vim than any online tutorial -- you don't even need a net connection or a web browser. I'm by no means a competent Vim user but I did have the basics after 30 minutes which is what it advertised.
Start by copying someone else's vimrc (vim-sensible [1] is a great starting point) and tweak it as needed. My $0.02 is to avoid plugins until you have used vim for a substantial amount of time.
[1]: https://github.com/tpope/vim-sensible/blob/master/plugin/sen...
Writing my own vimrc from scratch (but obviously referencing others) was by far THE best learning tool for me.
Anyone have some better examples of things you can do with Vim that make it worth learning over a GUI-based editor like Atom?
ci( - Change inside parentheses ci" ci' ci}
If your cursor is anywhere inside a set of parentheses, (if, while, for, function call, aka this happens a lot) and you need to change everything inside the parentheses, just type ci( and it deletes everything inside the parens and puts you in insert mode so you can start typing. Guess what ci" and ci' do? How often do you need to rewrite a string? This is huge.
dd - Delete line
Deletes the whole line with a quick double tap of a home row key. So much faster than highlighting the whole line with the mouse and hitting backspace twice, or hitting home, shift+ctrl end, backspace backspace. Want to delete 3 lines? 3dd.
A
Move to the end of the current line and start typing. Super simple and nice to have.
w
Move to the beginning of the next word. Way more ergonomic than ctrl+right arrow.
yyp
Copy the current line and paste it below the current line. Super simple, super fast.
Those are the commands that make Vim matter to me. Once you put in the time to make them muscle memory, you'll never look back. There are of course tons of other commands, but I can say that those are the ones that changed how editing text feels to me.
1. The main benefit of vim or any editor is not some fancy feature like macros or visual block editing. Although vim has those and they are great, they only become useful in about 20% of situations. When coding, you spend much more time reading code than writing it. That's why vim has you in Normal mode most of the time, where you can't type at all, and the whole keyboard becomes a tool for navigating. Reaching for the mouse incurs an unconscious mental cost that affects the way you read and write code. Editor ergonomics do impact your codebase.
2. Vim's ratio of power to learning difficulty is the best out there, because once you learn one word of vim's "language", you can combine it with every other word you know and it will behave how you expect.
3. I never try to convince people to switch to the actual vim editor because it requires a ton of customization just to be usable, and overall it's not that great. It's filled with cruft and weird things like a custom scripting language. The only important part is the key bindings, and you can get those in any modern editor. I use about 4 different editors and IDEs on 3 platforms on a daily basis. I never had to learn all their crappy keyboard shortcuts because they all have vim key bindings.
The key observation behind its design is that programmers and sysadmins spend much more time editing than entering new text, and therefore it is asinine that 40 of the keys on the keyboard are permanently dedicated to typing out literals when there are very obvious editing operations that give you a lot more leverage.
For example, the `d` key begins the `delete` action, the `i` key means `inner` (or `current`) and `w` means `word`. From that, you can deduce that `diw` deletes the current word.
I figured that command out myself, among many other ones, and that only works because of the composable nature of Vim's modal editing.
Vim's macro system is also rather amazing, IMO. I haven't used Atom much, so I don't know if it's comparable, but I will usually set up several macros and compose them together to do mass edits of things.
You don't have to give up Atom, you can use Vim bindings in atom. Most editors support it to some extent via plugins.
I use vim bindings in Visual Studio, and I combine it with Resharper, and that is insanely awesome. I started writing a guide to it ( https://github.com/keithn/vsvimguide ) but it needs a bunch of work, I keep changing my mind about what the best starting bindings are to get the best blend of VS + R# and Vim ( I mainly fully embrace the Vim way, but I think thats too much when starting, it's best to start with the core Vim moving/editing and then learn to customize). But I digress, the "Changing Text" section has a number of combos that people often find a selling point of using Vim.
I've tried learning VIM a few times and always gave up, and feel like my editors shortcuts cover most cases anyway. There's also not that many times where I feel like coding speed is required. Honestly curious how much more productive you guys feel after learning VIM.
I only SSH occasionally and it is a pain to navigate through nano. I actually tried a bit of vimtutor this morning and found it pretty enjoyable.
I use it constantly when configuring Linux machines, which is only an ancillary part of my job, just for the regex search to find the line I want to tweak. Since servers don't generally offer a GUI, it's the simplest way to replicate that feature.
In actual day to day use, it is more a matter of saving my fingers from stressful yoga tricks.
Also consider vim in your web browser (vimperator or vimfx or qutebrowser or vimium)
Vim in your file explorer (vifm)
Vim in your terminal (tmux in vim-mode)
Vim in your mayonnaise for lunch (https://lisalynnfit.vimtoday.com/images/thumbs/0000878_1200....)
Vim as a floor wax/desert topping (http://www.mysavings.com/img/link/large/74808.jpg)
and so forth.
If you could improve your typing efficiency by an order of magnitude (not likely), how much time would you save? Minutes per day? Certainly not a whole hour.
Use a modern IDE with sane out-of-the-box configuration (ex: JetBrains.) Realize that you spend more time thinking than typing. Eliminate redundant typing with templates.
I used vi for years, then emacs for nearly two decades. I will never go back.
The reason I use and like vim isn't because it improves my productivity. I mean, there's a chance it does, but I kinda doubt it makes that big a difference.
The reason I use vim is because I enjoy using it way more than any other editor. That's because with vim, the amount of time between me deciding on a specific change to make, to it happening, is almost instantaneous. In other editors, I have to spend time moving the cursor around, selecting stuff, etc. In vim, there's usually a command to get what I want done immediately. Not to mention that, with additional plugins, you can get some insane functionality that doesn't exist elsewhere (and you can easily customize vim to add commands that are relevant for you).
I don't think this impacts productivity, but it just makes vim more fun. And (in all seriousness), it's ruined me for other IDEs and editors. Even though there's a chance I'd be more productive in e.g. PyCharm, I can't make the switch because I'd miss too many things from vim.
Btw, it took me a long time to get semi-descent in vim, as I assume it takes most people. I did it not just because vim was a better editor and I was hooked, but because I enjoy playing with and customizing editors. So the amount of time I wasted (and still waste) on vim was enjoyable, so it was worth it to me. I wouldn't consider it productive time well spent though.
If you think Vim is not helping you being more productive, I suggest reading the excellent StackOverflow answer that explains how learning Vim is like learning a language (not just learning keyboard shortcuts): https://stackoverflow.com/a/1220118/1175080
The only things that I find lacking in Vim is good support for various software development environments, for example, Java development. Another thing that used to bother me is the awkward placement of the Escape key but I overcome that easily by remapping my Caps Lock to Escape (see https://github.com/susam/uncap#uncap for examples).
I find it more comfortable to have my fingers on the home row, than stretching them to pull off CTRL key-sequences.
https://www.youtube.com/channel/UC9xP5LRmm2qbSKq6nHTB_bw?vie...
set editing-mode vi set keymap vi-command:w
This gives you vim on the command line, very handy.
Interactively, set -o vi will work.
This is a great way to 'live in vim.'
I've tried Gvim, but this just seems like vim with buttons (no smooth-scroll). I've tried Sublime text with the ActualVim plugin (powered by NeoVim), but this had errors which somehow swapped document buffers on write, essentially deleting an entire document (thankfully I had a backup).
However, with Latex documents, for example, very long lines (i.e., paragraphs) are a big pain for me (even with vimrc options `set display=lastline` and `set linebreak`). In typical GUI text editors, the wrapped lines of long lines are treated as sort of "pseudo lines" themselves. This means when I cursor down (via mouse or keys), the cursor doesn't jump to the next newline after the paragraph (as it does with vim).
Apparently, this last described problem can be addressed [1]. So maybe the solution is that I need to spend more quality time with my vimrc? :)
[1]: http://vim.wikia.com/wiki/Move_cursor_by_display_lines_when_...
In Vim, it'll just do an instant repaint, so you kind of lose context.
For GUIs, I tried VimR and MacVim. Neither seems to smooth-scroll. Using the above plugin might work though?
Also, have you tried Vintageous for Sublime Text? I use it and it works well.
This can be solved by remapping ESC to Capslock.
For example, I have jj and jk mapped to ESC. So I just tap j twice while in insert mode, and it switches to normal/command mode. If you find yourself needing to type jj or jk often in insert mode, just pick other letters that make sense for you.
To use mine, plop these in your .vimrc:
inoremap jj <Esc>
inoremap jJ <Esc>
inoremap jk <Esc>The modal aspects are there, but my experience has been that 80% of my editing time is spent reading and finding the right place to put something, and the default when opening a file is reading to find the right spot. Further, switching from read mode to write mode is often done with different purposes, and vim lets me express those different intents when changing modes (insert here, replace this word, replace this line, etc).
I think there is probably a little bit of changing your workflow, but for me it's been largely about learning how vim fits my workflow.
No doubt, becoming proficient in vim is a big commitment that you really have to work at. Personally I think it's a great editor though.
Putting things up on the wall is like a free, albeit static, extra monitor. :-)
Besides, I use Neovim for 1-2 years now.
That kind of situation can foster resentment, but I embraced the challenge. I got use to Vim, and overall adopted a more "UNIX" approach to my workflow and development. I'm not all the way there, but I'm trying to embrace it more, little by little.
[1] - http://www.nethack.org/
ESDF and IJKL look temping
Typing in Dvorak, I'd need to remap anyway before being able to use the keys. May as well pick the best scheme.
Get a demonstration, then try on your own.
Or maybe even include a vim golf game as an exercise? E.g. get to some word in less than four key presses.
Since emacs changes its behavior depending on the mode, it would be impractical to do a more in depth tutorial, in my opinion, but I liked the Mastering Emacs ebook.
Emacs is too big to learn every one of the 7000 or so functions, one learns just what's useful in a particular realm. Anytime it's necessary to wander into new territory, there is really good built-in help system available. Help commands start with Ctrl-h. The next keystroke determines the kind of help that comes next.
A handy prompt after Ctrl-h suggests typing '?' for additional options. The basics options are:
a PATTERN -- show commands whose name matches PATTERN
d PATTERN -- show commands whose documentation has a match to PATTERN
f -- documentation of a particular function
c -- what command runs for a particular Emacs key sequence
t -- learn by doing tutorial.
There is a full page of other help options including access to the full emacs manual.
The only thing to know is to press 'q' to quit the help window and get back to where you were.
Do you know the command to quit vim?
CTRL-Z
sudo killall vim
sudo apt uninstall vim
I've just started working on a text editor as a side project, and one of the main things I want to include is a really complete implementation of vim keybindings. So far I just have a queue of keyboard events. Basic movements seem pretty easy, but I'm worried about operator motions (d6w - delete 6 words, etc). Will I basically need to build a parser?
Any guidance or keywords I can use to research/learn how to do this would be greatly appreciated.
[1] https://chrome.google.com/webstore/detail/cvim/ihlenndgcmojh...
The most disappointing thing about using an extension for this is when I open dev tools or a tab fails to load. I love luakit because the browser itself lets you set up vim like commands. Unfortunately I had to give up trying to build it for macOS
- Press 't' to open a new tab.
- Now I realize I want to go back to the previous tab. I press 'Escape'. Nothing happens. The focus is stuck in the address bar. I press 'J' and of course the 'J' gets typed into the address bar. How do I escape back to normal mode? I can't figure.
With VimFx for Firefox, it works exactly as one would imagine.
- Press 't' to open a new tab.
- Now I realize I want to go back to the previous tab. Press 'Escape' to return to normal mode. Press 'J' to go back to the previous tab.
If this is something that works fine in cVim, I am going to ditch Vimium in favor of cVim today!
On https://news.ycombinator.com/item?id=14658197 and its children I wrote something about the business model of VIM Adventures that you should consider before buying.
Guess I'll need to look at the source here later on to find out.
nnoremap h j
(define-key evil-normal-state-map "h" 'evil-next-line)
(define-key evil-normal-state-map (kbd "j") 'evil-backward-char)
(define-key evil-normal-state-map (kbd "k") 'evil-next-visual-line)
(define-key evil-normal-state-map (kbd "l") 'evil-previous-visual-line)
(define-key evil-normal-state-map (kbd ";") 'evil-forward-char)
(define-key evil-visual-state-map (kbd "j") 'evil-backward-char)
(define-key evil-visual-state-map (kbd "k") 'evil-next-line)
(define-key evil-visual-state-map (kbd "l") 'evil-previous-line)
(define-key evil-visual-state-map (kbd ";") 'evil-forward-char)
(define-key evil-motion-state-map (kbd "j") 'evil-backward-char)
(define-key evil-motion-state-map (kbd "k") 'evil-next-line)
(define-key evil-motion-state-map (kbd "l") 'evil-previous-line)
(define-key evil-motion-state-map (kbd ";") 'evil-forward-char)
(define-key dired-mode-map (kbd "j") 'evil-backward-char)
(define-key dired-mode-map (kbd "k") 'evil-next-line)
(define-key dired-mode-map (kbd "l") 'evil-previous-line)
(define-key dired-mode-map (kbd ";") 'evil-forward-char)) (defun multi-evil-define (d symb)
(define-key evil-normal-state-map d symb)
(define-key evil-motion-state-map d symb)
(define-key evil-visual-state-map d symb)
(define-key dired-mode-map d symb))
(multi-evil-define (kbd "j") 'evil-backward-char) ....Vim is all about ergonomic touch-typing.
vi" - select inside "
va{ - select around curly brackets
(optional) first, go thru vimtutor (just type vimtutor in your shell and press enter).
second, get a vim cheat sheet (google).
finally (most important), code a few things using vim. keep google at the ready to look up "how do (etc)?" to speed up things you're actually doing.
once comfortable with that, maybe watch a few vim tips videos.
after all that, you will probably find vim much more comfortable than gedit, textedit, notepad, etc, just for the power. if you favor ides, you'll probably need to do a lot of tweaking to love raw vim, though or course some ides offer vim keymapping anyway.
I wouldn't put that in a beginner tutorial (at least the system clipboard copying/pasting).
cut: x,d,c,s
copy: y
paste: p
different variations for different use cases, can be combined with movement commands, can be repeated, etc
Vim, beyond the very basics for server side administrative tasks, isn't worth your time.
Vim isn't worth the investment in time for me, as an average programmer, and I doubt it's worth the time of most other (average) developers as well. It's a big investment in retraining muscle memory and rethinking about how your editor works for, frankly, little gain.
"It speeds you up" - no it doesn't. It gives you access to keyboard shortcuts for moving around your buffer that other editors give you. It has a cool way of looking at text and once understood, you can do cool shit. I never could find a need for any of that stuff, even after spending a week or so learning it and adjusting muscle memory. After moving to VSCode, I've never missed that stuff neither. That says a lot about my personal use case I'll admit, but my use case in very common as an everyday programmer.
Funny enough, most editors have plugins to enable Vim modes and keyboard weirdness anyway.
So I've tried moving to Vim from Sublime, and I'm thankful for the time I invested, but I quickly realised that Vim (and Sublime, actually) fall short compared to VSCode or a serious IDEs. And yes, I'm aware you can make Vim behave like an IDE - I did it. I get it. It's not worth the time.
With modern, graphical editors and IDEs like VSCode, Atom, Eclipse, the IntelliJ family like IDEs, and so on, you get up and running straight away. You can extend them very quickly using a built in plugin system - you don't even have to leave the software.
I use VSCode, and I've found that I haven't had to leave the editor or install anything outside of VSCode plugins to make it operate as a Java IDE, Go IDE (OK, I had to install Delve), or Python IDE. It has saved me a lot of time tinkering and allowed me to just get going. It even PROMPTED me when I opened a Python, Go, or JavaScript file for the first and offered to install plugins for making the file easier to work with... YES PLEASE! And yes I know Vim can do these things (using external, third party plugins.) I did it. I get it. It's not worth the time.
I'm also aware that Vim uses kilobytes, perhaps megabytes, of RAM to operate and VSCode uses hundreds. And that's a problem how? I have 16GB of RAM on a system running a single VM for Docker and a browser. I'm the first person you'll find who will complain about how bloated and heavy applications are in this day and age, believing that us programmers are getting lazy due to an ever increase in resources, but a few hundred MBs of RAM for massive time savings and a great UI is worth it.
It's simply not worth the time invested. The basics allow you to do quick server side stuff and you'll be thankful for the knowledge, but beyond that use something designed for the job, even if it does eat RAM for breakfast.
Your whole comment can be dismissed easily because of this one gross misunderstanding. Vim is not a bunch of weird keyboard shortcuts. If one approaches Vim as an editor that uses keyboard shortcuts that are inconsistent with every other editor out there, then one is simply setting themselves up for pain and unproductivity.
Vim is not a bunch of keyboard shortcuts. It is an interactive editing language! For more, see this excellent comment on StackOverflow: https://stackoverflow.com/a/1220118/1175080 (a very well written answer!).
The fact that you were not aware how Vim is different than other editor (editing language vs. keyboard shortcuts) shows that you use your current editor as a macro for keyboard shortcuts rather than something you can talk to with little verbs and nouns and combine them into complex editing instructions with ease.
There is no way you can match my speed and productivity of editing and refactoring code with that kind of approach to editors.
Putting that aside, I totally understand what you're saying about Vim. I felt the same way when I started out with it. But I didn't have a choice at the time because the company I work at only supported Vim, and there weren't too many other options around at the time. Atom was just new and ran like a dog. We were told we couldn't use Sublime unless we bought a license, so I was stuck with Vim.
And now, after 3 years of learning, and tweaking, and practising, I get Vim. I'm not a hardcore user; I don't use hjkl, I rarely use any register apart from ", but that doesn't mean I'm not getting any benefit from Vim. There are definitely some features in those other editors that are also attractive, but I've managed to find ways to replicate them in Vim, either using plugins or by mapping commands.
That said, at home I still use Sublime, but it has been pretty awkward because my hands are so use to certain Vim things, that I find myself pressing keys, doing things I didn't intend a lot. Installing a Vim-mode plugin to one of those editors doesn't fix that.
I never said it was an IDE. At least, I never intended to say it was, because it's not.
> And now, after 3 years of learning, and tweaking, and practising, I get Vim.
It took three years to learn to use Vim to be productive, is what you're saying here. Point and case.
You explicitly called it an IDE.
> It took three years to learn to use Vim to be productive, is what you're saying here. Point and case.
They didn't say that. Anyone without sever learning difficulties should be as productive in vim as any text editor in a few days at most, it just takes years to master because it's capable of so much.
I called it an editor that I made into an IDE. It operates no different than the most powerful IDEs available for the languages listed.
> Anyone without sever learning difficulties
Now you're just being rude.
It didn't take three years to get productive. It probably took a few months before I was fully productive, and that was while learning a new language and new codebase at the same time.
It's taken 3 years to get, not just comfortable and familiar but, beyond comfortable with Vim. It's taken 3 years for Vimming to become second nature. Actually, that's not true. I was typing Vim commands into my browser at the start of the year, so it's probably more like two years.
And that's not even 100% solid use. Last year, I used a lot of IntelliJ, VSCode, and Eclipse, but using Vim 1-2 days a week kept me in the habit enough that it's second nature to me.
I'm honestly glad it's working for you. The point of my original post was to talk to new users of Vim. You're quite well established with Vim so it's easy to have the opinion that it's not too difficult to use. However, I believe there are better options that enable people to be just as productive in a fraction, of a fraction of the time.
Good luck.
In contrast to what I just wrote, the ubiquitous nature of vim is a huge factor for anyone who does a lot of work on a number of remote servers where it's not feasible to use a GUI-based IDE. You can use nano if you really don't want to learn vim but I'd love to hear someone make a case for using nano over vim. You may only need to deal with this for 'basic server side administration tasks' but a lot of people have to do a significant amount of work on multiple servers due to data access and resource availability issues.
In addition, there is also the fact that a number of command line tools use vim key bindings for navigation (eg. man, less, more)
*Edit: grammar
The choice of Escape key to return to normal mode and H, J, K, L for navigation makes total sense if we look at the original Lear Siegler ADM-3A terminal[4] that Bill Joy used while creating vi, but in the modern day keyboard, the choice of Escape key to return to normal mode really disturbs the otherwise fine ergonomics of using Vim.
[1]: https://github.com/susam/uncap#uncap
[2]: http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_Windows...
[3]: http://vim.wikia.com/wiki/Map_caps_lock_to_escape_in_XWindow...
[4]: https://vintagecomputer.ca/wp-content/uploads/2015/01/LSI-AD...
It's also useful to use Bash in vim-mode and also remap the esc-key, e.g.
set editing-mode vi
set keymap vi
$if mode=vi
set keymap vi-insert
"jj": vi-movement-mode
$endif
inoremap jk <esc>
And
inoremap kj <esc>
In your vimrc file should do it.
The artificial delay I have to introduce between typing "j" and "k" to actually type "jk" is unacceptable. Although it is rare, I sometimes do have to type "jk" in special circumstances such as while typing LaTeX code.
Mapping Caps Lock to Escape is just a much cleaner solution that does not come with any surprises.
What I'd suggest if you want to give it a try is to also set the `timeoutlen` to a lower value. By default it's usually 1000ms, but that can be dropped quite a bit I believe without much interference.
autocmd InsertEnter * set timeoutlen=100
autocmd InsertLeave * set timeoutlen=1000- How do you escape from visual mode to normal mode?
- How do you ensure that your abbreviation gets expanded when you escape from insert mode to normal mode?
- How do you escape from operator-pending mode to normal mode? With this mapping, if you press 'd' to delete something and then change your mind and decide to return to normal mode, you are forced to use the original 'Escape' anyway. If you happen to press 'jk' due to habit at this time, it is going to end up deleting lines.
For these reasons, I thought to have a clean mapping of another convenient key (such as Caps Lock) to Escape at an operating system level, rather than trying to make Vim treat some other key as Escape in certain modes.
> The artificial delay I have to introduce between typing "j" and "k" to actually type "jk" is unacceptable.
I tried the CAPS approach and tried using it via my left pinky, but find it too awkward to use - but this is probably a very individual thing and it's good that Vim supports it via its remapping capabilities.
But I hear you, sometimes if I have to type the string "jj" I get really confused, but this happens not very often.
What if you want to type an abbreviation and expand it when you escape from insert mode to normal mode?
I press space or tab or enter or actual escape if I need an abbreviation and it happens to be at the end of what I intended to insert... I pretty much never rely on escape to do the abbreviations though because it's not at the end of what I want to insert anyway.
I also don't use visual mode enough to need to have an escape for it. you can certainly change the timeout on visual mode and add a visual mode mapping for that too if you want to do that. It seems you have a the attitude of this is the only "correct" way to do it. I don't really care if you use it or not... I was merely providing an alternative way to do what you want with the added benefit of it giving you an extra modifier key that you can bind other things to. You can also map it globally or for each of the handful of modes you want to escape from using it.
I also bind ALT-J and ALT-K globally to down and up arrows which is super useful when any kind of drop downs turn up and you want to select different options
I also don't use VIM the program that often, more often than not I'm using Vim bindings in other editors. Though they all have their quirks in terms of what they support.