Oh also: he mentions O to insert above the current line. I use that a lot, but on my systems (going back 15 years or so I think) it has always required a pause, like vim is waiting to see if I'm typing O or some longer command. If I type O and immediately start entering text, strange things happen. This doesn't happen with o. Does anyone else experience this? Maybe it's just something weird in my own setup.
EDIT: Some more "moving fast sloppily": 1G goes to the top of the file. G goes to the bottom. Also you can not-move, but scroll the visible area so that your cursor is on the top line (zENTER), middle line (z.), or bottom line (z-). I use that a lot when I am Ctrl-Fing through a file, so I can see more context.
set scrolloff=999
While scanning a buffer for some pattern I'll quite often make a one-off keyboard macro that searches for a pattern and then invokes `C-l C-l`, it's very nice to then bounce on the "repeat keyboard macro" key and leave my eyes in the same place while the screen contents change under them.
" for scrolling up and down quickly
nnoremap J 7j
nnoremap K 7k
vnoremap J 7j
vnoremap K 7k
" easymotion allows us to jump to all places that could have been reached by
" (w in this case), and the bd- indicates we want to search backwards too.
nmap f <Plug>(easymotion-bd-w)
vmap f <Plug>(easymotion-bd-w)
The even better solution (and I use them both in tandem) is to install easymotion [1] and use it like I show in the second example.
I also use gg and G to get to leap to the top and bottom of the file quite a lot.
---
As to your question about using O to insert above the current line, that should not work that way. Your specific issue sounds very much like a binding has been defined for O<other character>. Type :nmap in vim to display a list of bindings and check for lines starting with O. It might be in your .vimrc or some plugin defined something. I would definitely say remove the binding or the plugin rather than put up with that, O is very useful.
nmap <C-j> 3j3<C-e>
nmap <C-k> 3k3<C-y>
About the 'O' problem, try ':set noesckeys' and see [1] for more.
[1] http://stackoverflow.com/questions/2158516/delay-before-o-op...
I'll also note that although I do also frequently use () and {}, I very much like the plugin sneak, which adds an f-type motion. Usually f{char} goes to the first following instance of {char} on the line. Sneak adds in s{char}{char}, which goes to the first instance of {char}{char} (not restricted to the line), and is ;-repeatable just like f-type motions. What this means is that my default navigation is often, look where I want to go, find two letters, sneak to that combination, and then ;;; until I get to the right one.
On your also: My O doesn't stall at all. Have you tried performing the same action on an empty vimrc? You might start vim with `vim -u NONE`, enter some text, and try out O. Or maybe `:map O` or `:nmap O` will inform you that you have some operator-pending map beginning with O.
Also, with relativenumber set, it's easy to move to the exact line without counting, or to see how many lines you need to yank, etc.
But sometimes I'm just idly moving through a file with j and k, and it feels perfectly natural to do so, the same way I unconsciously move the mouse cursor over text as I read it (outside of vim).
I have to mention that for navigation purposes, f/F is only useful with ;, otherwise you could find yourself looking through the line for a suitable character which slows you down. With ; it's enough to pick a "rare" character on the line which is near to/in the desired object.
Next to c2f, ci" (and ci) etc) could be really useful when you end up being in the middle of a string literal and just want to change the whole thing. Or in the middle of an expression in parens - http://fuckyeahvim.tumblr.com/image/122373002741
set relativenumber nonumber
autocmd InsertEnter * :set norelativenumber number
autocmd InsertLeave * :set relativenumber nonumber
You can look through :map and try and find it -- not sure if there's an easier way.
http://stackoverflow.com/questions/2158516/delay-before-o-op...
set number + set relativenumber is pretty awesome for line counting. This marks all lines with relative numbers, except the current one.
I can easily without leaving home row move a few letter to the right or back with hl or f and F. but things started to get a lot more fun when you realize that Vim is a programming editing language and it's beauty is in the commands. This leads to amazing things that I hated before, such as deleting 2 words back from my current position would simple be d3b. instead of shift+ctrl+left arrow x 2 + delete.
Overall it's been about 2 months since I've started using EVIL mode for Emacs and I love it. I'll stand by the saying that Emacs is a great OS and vim is a great for editing text in it's modal editing.
lastly modal mode really felt powerful only after I had re-mapped my CAPS key to ESC. I mean throughout the past decade I don't think I've even used Caps for anything. so I've remapped the machines I work on the have caps as esc.
- for those that think it's not reasonable to do so and the whole point of using vim is so that you can edit machines via ssh then use vim on that machine, my suggestion is to use tramp in Emacs with ssh or plink to get to the server and edit (you will still have the local caps to esc key mapped)
TL;DR - Vim modal editing is amazing and feels has straining than other editing layouts - IMO.
I have tried it out loved the ease of it, but not the trade off for hangs and crashes.
https://en.wikipedia.org/wiki/Vi#/media/File:KB_Terminal_ADM...
I guess it'd be more like tab, but whatever.
Just the leader key and layers alone are incredibly powerful concepts Spacemacs brings on top of Emacs/Vim :)
But I can highly recommend anyone to give it a try. It's a good example how you can split configs into smaller packages and do keybindings the right way.
I went back to neovim and re-wrote my vimrc from scratch. With mnemonic keybindings, layered config and all the likes
Maybe I haven't understand well exactly what you wanted to delete, but if I have, then you might reconsider your emacs-fu, because there is much easier way to do that: Meta+<Backspace><Backspace>.
I did use plain Emacs mapping for the first few months of learning Emacs but as many have mentioned it's like do acrobats with your fingers and I lost the benefit that I was looking for in Emacs (better productivity). The benefit of not having to lose my thoughts and use the arrow keys or mouse, once those benefits were achieved I noticed that there could still be a bit more improvement and the vim modal editing was the solution. I still use all default Emacs mapping for everything else org mode, bookmarks and standard plugin stuff, Such as C-c C-j for jumping to the declaration in go-mode or things like mapping imenu to C-x C-i.
The most important part about this is the fact Emacs supports multiple Frames (different than windows). So I can work on 2 monitors and use window-numbering to move between windows and 'other-frame' to change what monitor I am working on I usually bind that to M-` as it's in the same row for navigating windows or search across all open buffers and use ace-mode across 2 monitors. (I'm not sure if VIM has that).
one other note, ace-jump originated from vim under a different package, VI(M) does have a lot of neat features and I believe the Ying and Yang need to balance and be in harmony which Emacs allows with vim (EVIL) :)
And in emacs, working with the selection does similar things for me (esp. once you add some functions/modules like expand-selection to it).
For movement, it's mostly search forwards/backwards, in both vim and emacs. Raskin was definitely along the right track with his leap keys (and someday I'm going to remap some dedicated keys to C-s/C-r/\//?).
others don't seem to like this, but i've found the following global key swaps effective
swap ctrl->alt
LCtrl::LAlt
RCtrl::RAlt
swap capslock->alt
Capslock::Alt
This very point is actually why I moved from Vim to Emacs years ago. After mastering Vim, I realized that Vim strongly encourages you to think a little too much about exactly how to get there or do that thing in the fewest keystrokes, and that it's incompatible with muscle memory. Even years later, I still had to think too much about it. Whereas in Emacs I can just use basic character/word/line-based movements and let my muscle memory do its thing while I let my brain focus on the code itself instead of how to use the text editor.
I feel like with every editor, it involves repeatedly hitting J, Ctrl+N or down arrow, which is inefficient. Do you have a way to get to a particular line that does not force you to think too much about how to get there ?
If you want to jump to a specific line number, you can use M-g M-g <number>, or (because C-u also provides numerical arguments) C-u <number> M-g M-g.
Finally, many motion commands set the mark, so you can use C-x C-x to return to where you were and select all text between your previous and current locations.
Oh, and if you want something even better, you can use C-` to jump to the location of compiler error if you use M-x compile, you can use ag.el or helm-ag for ag integration, Ace-Jump, which is similar to EasyMotion, built-in exuberant ctags integration (and a built-in ctags clone, etags), packages for cscope integration (if you're using C), and fiinally semantic, which provides a variety of parser-based tooling if it's supported by your language.
But you can also just use C-n, etc. and we won't judge you for it.
What, inefficiency? Inefficiency wasn't the problem. The problem was having to focus too much of my mind on how to use the editor. Muscle memory is invaluable, and Vim just doesn't let my muscle memory take over if I keep having to think about what's the most "efficient" way to move around or change text. Emacs lets my muscle memory take over easily. I just hit C-n or M-S-] a lot. It's inefficient, sure. But who cares? I never realize I'm doing it, and I never feel blocked having to wait until I get to the line I want to.
2. move mouse cursor to desired position
3. click mouse
If you're just looking to put the cursor somewhere you can see, this is actually quite quick.
These days I use emacs, and I pretty much always move the cursor using the mouse.
1. look at character you want to go to 2. M-x ace-jump-mode (I have this bound to F9) 3. Hit key for the character you want to go to 4. All instances of them are rewritten in the buffer with a coloured character. 5. Hit the coloured character you are looking at.
The trick is to just look at where you want to go and touch type the rest. Even on very large monitors with dense data (I find this invaluable if I am going through an minimized HTML blob or a plaintext database dump) this can turn any point to be 3 keystrokes away. Cursor + search forward doesn't work if there is a lot of duplicate text around where you want to go, like a string of five .set* methods and you are trying to kill the third one
The only commands I use to move vertically in vim are j, k, /, ?, ctrl-d, ctrl-u. And sometimes I just get the mouse and click.
But then I told myself, hey, why not try Emacs? So I've been using Emacs for ~6months now and cannot but notice that community is much more niche and humble compared to Vim. Just look at the sheer number of color schemes available for both editors. And I had to agree, Vim was far superior text editor, but that wasn't enough to keep me away from Emacs, since I gave the advantage to other things (everything else) that Emacs does better.
I tried EVIL mode, and it is amazing, but something just felt wrong using it inside Emacs. I wasn't using either Emacs or Vim. I would often shuffle and mix commands, sometimes I would do :w, sometimes C-x C-s. So I decided to ditch Evil until I get more comfortable with Emacs key bindings. I came to Emacs because of Lisp (and general FP audience is much, much, more based around Emacs, makes sense), amazing tools and plugins which I found more stable, better designed, and it is weird to say this but things just worked with Emacs, things like auto-completion and code navigation (ivy, ace-jump-mode) were really fast, hustle free experiences. Disclaimer, I have never touched older versions of Emacs, spent my time in 24, and now in 25, so many of myths and problems that Emacs got known for over the time, I think, aren't there anymore.
And to sum things up, what is really weird to me is that functional programming is on the rise and every year I see it more and more being adopted, but that doesn't help Emacs audience grow. (Maybe because I am young, and I am nerd often found in nerd communities where things like FP are often praised, but in the real world considered a bit awkward or esoteric.) I showed up at the FP workshop few weeks before in local dev/hacker community place, everybody rocking Sublime Text/Vim, but nobody used Emacs, people were looking at me like I was an Alien. Spacemacs is doing good job at attracting people, but maybe Emacs will stay that programmers/nerd phenomenon, the all-mighty lisp OS, that in the end people often reject or overlook. And why is it like so? I do not know. If somebody can sink into and learn Vim, I don't see a reason why it is different story with Emacs.
For new users selecting one I think this comes down what you're looking for from the application and the plugins/community around them. But, I really don't think there's any killer differences between them, it's just a matter of taste.
For you:
> I came to Emacs because of Lisp (and general FP audience is much, much, more based around Emacs, > makes sense), amazing tools and plugins which I found more stable, better designed, and it is weird > to say this but things just worked with Emacs, things like auto-completion
I recognise it's more popular to edit Lisp with Emacs, but Vim seems to do just fine. I play with Clojure and do that using Vim perfectly fine there are great plugins (fireplace etc). There's no doubt that the 'emacs is code' thing attracts Lispers to it.
Both, Emacs and Vim both have large ecosystems of tools and plugins around them so I consider that a non-issue.
In terms of configuration, I think Vim is easier to get started with. I personally consider Emacs system a steep learning curve for the general use-case. I find Vim is very well documented and has lots of settings for all the conceivable things you'd want, plus a raft of plugins to alter it's behaviour in the ways I want. However, the fact that Emacs can be rewritten in-itself is a powerful concept so in principle you can't see an advantage there.
In the past people used to say that Vim was smaller and that was a reason to use it over Emacs, but that's a total non-issue for the general use case.
I don't think it really matters which one you choose, as long as you spend some time getting to know 'it' properly.
LOL, I felt the same way about emacs when I tried to force myself to use it. Interesting that you point out that "the scripting is awful" - my sense after a year of using emacs full time was that the _only_ way to use emacs is to learn to script/reprogram it. If you don't mind my asking - how _did_ you learn emacs? Were you a lisp programmer to start with? Or did you learn it in the context of emacs?
Modal editing is far superior, once you learn it.
Emacs runtime and configurability thanks to Elisp is far superior to VimL.
So just use Spacemacs. ^^
For me the "feels wrong" is that vim is always just a little bit snappier than emacs. If you gave me a borderless window with no branding and only let me type vi commands I bet I could tell vim from emacs 9/10 times.
I used emacs exclusively for > 20 years and just recently began to transition to vim to save my tendons. It's amazing that so many of the verb-noun command constructs are still wired in to my brain stem.
I use emacs with evil, my approach for this is to use vim keybindings for everything related to text editing and emacs keybindings for everything else.(With just some minor exceptions).
Unless you want to go the whole full exotic keyboards route and/or go crazy with remaps, emacs keys are just too painful.
:%!awk '<do some awk stuff>'
I agree with a lot of the things in this article, but wow, I could not possibly disagree with this quote more. Ctrl+[ is WAY more uncomfortable than using the Escape key.
Granted, I have many years of vim usage that have made hitting Escape a habit, and that probably plays a big part in it, but Ctrl+[ is downright painful for me (and yes, I sat and tried it for a while in vim to see what it would be like).
I can get from the home row to Escape and back with very little effort, though I understand that is not the case for many people. Perhaps it is due to the fact that I use my ring finger to hit Escape rather than my pinky (which would be a lot more work, I think).
So, I basically don't mind CTRL right where it is. It doesn't bother me for the things I use it for.
For me, the two-handed combo of CTRL-[ is just a lot more work than the single-handed move of my ring finger to the ESC key. I don't have trouble getting my left hand back to the home row quickly after doing so either. Moving CTRL to Caps Lock would alleviate that some, perhaps, but I don't think it would be enough of an improvement to make me prefer CTRL-[ over Escape.
Did you try it with one hand or two. I do it by using my left pinky on the ctrl key and my right pinky on the [ key. In general, I've always tried to stick with the touch typing convention where you use the modifier key on the opposite side of the keyboard relative to the key you press.
For example, I will always press the left shift key for capitalizing I and the right shift key to capitalize A (and similarly with the alt or ctrl keys). It's more ergonomic, IMO (and also the reason I dislike keyboards that are missing modifier keys on one side of the keyboard).
^^ was this supposed to be a joke? (I laughed at first when I thought you meant stretching the left hand between the left CTRL key and the [ :-D ).
I guess I could see someone trying to type it one-handed with their right hand, but I would have never even have thought to do that (and I don't know that I ever use the right CTRL key anyway).
Outside of the CTRL keys, I touch type pretty much everything normally, with very few exceptions (like using my ring finger on Escape). I find moving my right pinky to the right CTRL key to be very uncomfortable, so I just always use the left CTRL key.
xD
A lot of people have a tendency to think of each tab as corresponding to a single open file. This is very understandable because it closely matches the paradigm of most IDEs but it's actually an anti-pattern in VIM. Tabs are really meant to be more like workspaces where you arrange multiple windows into a desired layouts. You then have one buffer for each file that you're dealing with and view them in your windows. It's perfectly fine for multiple windows to share a single buffer or to switch out the buffer that is being viewed in any given window. This StackOverflow answer [1] and this blogpost [2] both go into a fair bit more detail.
If you're trying out this approach for the first time then you probably want to add `set hidden` to your configuration in order to avoid automatically closing buffers that aren't currently being viewed in a window. Coupling this approach with fzf.vim [3] makes managing very large numbers of files a breeze compared to using one tab per file.
[1] - http://stackoverflow.com/a/26710166
[2] - http://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs-...
But I then I pretty much exclusively work with three windows side-by-side, NERDTree, File 1, File 2. I guess if you like switching window layouts a lot then tabs could be very useful.
I never really understood what the problem with this was; I rarely actually use them (esc|capslock /str,ctrl+f|b etc) is usually how I move around and if I'm wanting to move a few chars my little finger is not moving very far (at least, on apple keyboards)...
Is this heathen territory? ;)
Do you see any big advantage of using a lot of buffers/tabs/splits over running multiple vims inside tmux? My workflow seems to be more multiple vim's and shells inside tmux (I have ` as my "control key" in tmux, which is right beside z on my keyboard) which always feels quicker to me than ctrl+ww or ctrl+w<arrow>; and I really like the "zoom" functionality there...
hitting `` to switch between windows in tmux is really nice, too.. :}
One advantage would be the ability to use vim registers to copy text from one buffer to another instead of having to go through tmux or screen. Another would be word or line completion in a given buffer using contents in another buffer. In general, by running multiple vim instances instead of a single vim instance, you lose the opportunity to leverage vim to manage multiple buffers by using information in a given buffer.
I think my personal benefit is that I don't have to make a bunch of new SSH connections every time I want to split files in vim, I can just open up a new buffer.
So, that said, check out ctrl-p.
https://github.com/ctrlpvim/ctrlp.vim
It's a nice quick way to see a filelist that you can filter, like fzf. You can filter on:
* the whole project, excluding .gitignore stuff
* all open buffers
* Most Recently Used (MRU) file list
In addition to the built in ^p binding, I also add:
nnoremap <leader>v :CtrlPMRUFiles<cr>
nnoremap <leader>b :CtrlPBuffer<cr>
Is git for windows using msys2 yet? If not, do yourself a favor and start using msys2 instead. It has packages for git and vim, and it uses pacman for pacage management. I've had a great experience using it.
The numbering system is a little screwy (starting at 1 instead of 0) though.
I just wish I had more control over window layouts. Something like the controls of a good tiling window manager, like I3. There is just no way to open 12 files in a list of windows, and then arrange them into a sort of rectangle tree, but I prefer to open all the files I will need at once from the command line, using globbing operators and brace expansion.
The author addresses that, too, in https://sanctum.geek.nz/arabesque/vim-misconceptions:
> The model Vim uses for [tabs and windows](https://sanctum.geek.nz/arabesque/buffers-windows-tabs) is rather different from most GUI editors, but both are supported and have been for some time.
This is built-into my Lenovo Carbon X1 (gen2) keyboard, drives me bananas as I use tilde quite a bit (being home on linux): http://www.lenovo.com/images/gallery/1060x596/lenovo-laptop-...
What kills me more though is that "Shift" is now caps-lock if you double hit it (because home/end are where capslock normally is). The standard way I wake up a machine when it's locked/asleep/blanked? Tapping the left shift key a few times. ergh.
Should get a gen3, they reverted to a more sane keyboard layout.
I also typically use a Unicomp Model-M style keyboard, complete with springs. But that's an entirely different flame war.
The author's explains his rationale in the next section, it's to prevent users from living in Insert Mode. Fair enough. But, when making several relatively close edits, the ability to tap a few arrow keys in Insert Mode is far easier and less mentally demanding than any key combination that requires the user to bounce around different modes.
I'd also add that if you remap Esc to something more manageable, leaving insert mode for a second to move around starts feeling a lot more natural. I still do get where you're coming from, the arrow keys do have a time and place. But since I do all of my moving around in normal mode, leaving insert mode to do it just 'makes sense' now and I really don't even have to think about it.
What ultimately worked was to map the triangle `ijkl` like you normally see `wasd` in games.
i
jkl
i -- up
k -- down
j -- left
l -- right
i
hjkl;
h -- skip backward to the beginning of a word (ordinarily `b`)
; -- skip forward to the end of a word (ordinarily `e`)
My vimrc: https://github.com/rectang/dotfiles/blob/master/vimextra
This must have been around the time that I started to understand, and manicure, my vimrc because I remember having to learn all the mapping modes to recover arrow keys for Insert Mode.
So, anecdotally, completely disabling arrow keys led me to learn more Vim than just efficient movement.
Today, though, I don't have the makings anymore because it's no longer a problem.
One quick question; I can't answer this because I am currently commuting. Does 'noremap' disable keys in Command Mode? Now, that would be aggregating, to me.
Also, there a remap mode that combines Normal and Visual modes (right?), that would be one better than 'nnoremap'.
The dvorak layout (and especially switching layouts) saved me from a lot of pain, so I don't plan on ditching it any time soon.
Another anti-pattern I did was Da and dWi, NOP-ed them and forced myself to start using C and cW respectively. Not much of an achievement, but feels better :) Same for x, I deleted whole words with x, then pressed i, I removed the mapping of x.
Conclusion: in case you think you have an anti-pattern, just NOP the mappings. In case one or two turns out to be too much of restriction, you could always remove the NOP mapping later.
Something like this: https://ergodox-ez.com/collections/frontpage/products/ergodo...
Maybe there are scenarios where the busywork of text editing really is on your critical path, but even as a fluent coder who uses some verbose languages at times (my current project is C++ and IEC Structured Text, does it get any more blabby?) I still spend far more of my time looking at, and thinking about, code than I do actually typing. Any extraneous cognitive load just takes focus away from what I'm actually meant to be doing.
I agree that we spend far more time thinking about code than we do editing it, but being fluent in vim means that when I have the code in my mind, or I decide how I want to refactor something, I can get those ideas out with very little effort. If you reduce the friction of translating thoughts into code, it means you can spend more time thinking about the code instead of futzing about with an editor. Once you get good with vim, it _reduces_ your cognitive load. I know that from the outside all these tricks and tips seem like random jibberish, and impossible to remember, but when you live inside the vim bubble it really does make sense. You find the tricks that fit your mind and your work the best. They quickly become muscle memory and you don't think about the keys at all.
That said, it _is_ a cult. I've seen cool features in other editors, and I've tried to use them, but it always feels like I'm typing with mittens on my hands. And I come crawling back to vim.
BTW, I rarely use escape. I am using Spacemacs with evil-mode, and the default "fd" is perfect for me. It's much faster than using ESC.
Any extraneous cognitive load just takes focus away from what I'm actually meant to be doing.
Also, combined with some other changes (the space bar is fn if depressed with another key, space bar otherwise; caps-lock is mapped to control; a couple somewhat more complicated macros), it is pretty effective at keeping others off my machine.
A programmable keyboard offers useful options.
It helps that vim is installed by default in every modern OS.
Otherwise, if it's a really modern OS, there's a plethora of modern, fast, cross-platform editors that follow CUA conventions.
c2w v2ec
Thinking I should just bite the bullet. Would mean I could work on a server using Mosh + Tmux as well, which should be rather nice.
What would the current canonical guide be for getting up and running with Vim, with plugins, auto-complete[1], inline linting, multiple carets etc?
[1] Just the ST3-style of parsing out tokens in the same file
What worked for me to bite the bullet at uni was making myself do an entire programming assignment in vim and not opening in any other editor. If you commit it doesn't take that long to learn. Keep a list of commands handy and learn a few new ones each day.
[ed: a little more context and detail: http://usevim.com/2012/07/06/vim101-completion/ ]
xD
^X mode (^]^D^E^F^I^K^L^N^O^Ps^U^V^Y)
I really like having C-x C-f, which autocompletes file names.
The simplicity of vim (and pretty colors) drew me in. Plus as I learned more sed/ed, I understood vi more. That, and a slow connection from off campus really sucks. I learned that too pretty well. Well enough to hack together some vim scripts, but nothing near my Emacs level. I feel like vim mode hacking is a beast you need to be specially equipped to handle (and I can write APL in any language so it isn't the syntax).
Then Eclipse and IntelliJ came around and I only really used vim for quick one off stuff (if I didn't use printf, echo, or cat). The only time I used vim was for C/C++ or something esoteric, like KDB+/Q/K, that didn't have their own dev environment (unlike say VHDL or Matlab where I could sit in their ugly cocoons).
Now I'm growing tired of the very buggy, slow Java environments that seem to require a gaming rig to compile HelloWorld.java (or sorry, HelloWorld.xml with SpringBoot). And I see all these poor Emacs clones playing catchup with 2000. You have editors written in JavaScript inside a web browser with modules transpiled to JavaScript (for some reason JavaScript is too low-level to write text editing packages in now -- God help us all). That, and they don't support a tenth (I'm being generous) of the functionality that Emacs does and they probably never will.
What is so hard about an extensible text editor? Just getting the basic hooks down for self-insert and movement without having to go to swap?
I remember when Emacs was called "Eight Megabytes and Constantly Swapping". I now see Atom routinely take up over 800 MB. And it still can't play Pong.
Now with Rust and other languages, I'm back home in Emacs, but the keystrokes do tend to bother me a little. I liked the HJKL movement keys in vim - I just hated the modality and think I spent more time trying to figure out "my cursor is here, but I need move it over there - so first I need to jump on that log, shoot the rocket to knock down flowerpot then run quickly while the line is falling to catch it and K it to the next line" -- like some sort of weird text editing puzzle (I wonder if you could make a vim code golf puzzle set).
Emacs has these bindings that feel like finger yoga, even when I've remapped Caps, control, half my F-keys, etc. What I really need to do is remap my toes to my hands, I think.
It would have been really nice to see C-[hjkl] style movement (with maybe CS-[HJKL] be the distance mods or something). It's too late now. You of course you can remap those keys, but too much of that behavior is baked in to people).
Maybe one day when I'm old and gray I'll do the Knuth thing and start a new text editor, but before that I'll probably need to redo the monitor, mouse, and keyboard and that is just too much right now.
setxkbmap -option caps:escape
And here I was undoing and redoing the entire time.
For me the biggest boost in Vim was configuring the shell (i.e. readline via .inputrc) to use my vim key bindings, so I can use it without arrow keys. Not because of efficiency, but more for wrists comfort.
Furthermore I am in the camp of mapping ESC to 'jj'. My index finger has more power and using the pinky (e.g. via CAPS or ESC) is too exhausting for me.
Meh whatever, it works, and the amount of time I spend in vim these days is so minimal that I doubt it's worth it to retrain.
There is a nice chart on this page with a few more inferior/superior motion commands:
http://vimcasts.org/episodes/modal-editing-undo-redo-and-rep...
One problem I commonly see with most vim advice articles is they just have too many tips for the reader to consume at once. But if you just make sure to pick up at least one of the tips, you'll at least gain something.
Did not know this! (although I've been on vim for ~a month) That's a great trick. Much easier than trying to count words.
deleting/yanking with / and ? will do whole lines, so it may go past the match.
deleting/yanking with t, T, f, and F will go up to just the char you want, but it won't search onto the next line.
I wish there was a way to get a char-by-char multiline search, so I could e.g. cut/yank a whole sentence (something like d/.). But I haven't found it. I wonder if anyone else knows of a way?
https://github.com/easymotion/vim-easymotion is another plugin that does something slightly different, but also useful.
Only just figured that one out by mistakingly having the capslock on when moving around.
In general I would agree 1 character at a time is an anti-pattern but it needs to be balanced with the cognitive load of counting how many words or deciding what is or is not a boundary when there are symbol characters.
I think where vim often wins over emacs is the 110 vi modes that every IDE eventually gets. Vi is an idea that can prosper in many environments.
Emacs is kinda like smalltalk. To get much benefit from it, you have to buy into it whole hog, or not at all. I can write C# in VS with vim keybindings, go in sublime text, and then just hack on a Lua snippet in vim itself. Emacs has ways to work with all those, but that requires a new skill set that I don't need at the moment. Maybe after I graduate from college, but right now isn't the time for me.
For me I set it up to not allow more than 2 steps in any given direction to remind me to use jumps instead.
It's worth noting that, after searching with ?, you can still move back and forth through occurrences using N and n, in the same way you would after using / for a search.
Begone with your heresy!