Vim Anti-Patterns | Hacker News Reader

Vim Anti-Patterns

sanctum.geek.nz

458 pointsmicrosage238 comments

I never got into the habit of using { and }. I just use H M L (high/medium/low) to get approximately in the right part of the screen, then go line-by-line. You can also do 5H or 10L to get "5 lines from the top" or "10 lines from the bottom". I make pretty good use of vim features, but I like to mix some sloppiness with the precision. I don't often count things before typing commands, because that breaks the second-nature quality of navigation. If something is more than 2 or 3 objects away, I approximate. I do use counting with t, T, f, and F a lot to hop around, including things like c2f). Very frequently that combines well with spamming j.j.j.j.j. I use . with trivial movement (like j or n) at least 10x more than @a. Another way to move fast sloppily is W and B. I guess I'm saying: learn all the cool stuff you can do, but don't feel like you have to find the most precise way to do every little thing. If you're just starting out, relax and don't try too hard. You can always just pick one new thing every couple weeks and try to add it to your habits.

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.

Sounds like you've got something mapped to a key sequence that starts with O.

You can look through :map and try and find it -- not sure if there's an easier way.

So this prompted me to Google for it (Googling for one-letter vim commands works better than I thought!), and this looks like the issue:

http://stackoverflow.com/questions/2158516/delay-before-o-op...

I share some of your sentiments. I find that I so frequently want to go the first and last non-whitespace characters in a line that I remapped H to go to first non-whitespace character and L to go to the last. I think of these as "linewise-h" and "linewise-l", which almost fits with vim's other conventions. Then I substitute ctrl-d and ctrl-u to go up or down by half-screens.

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.

I think ^ goes the the first non-empty character on the line already. Think of it like the regex. Then 0 (zero) goes to column 0.

I have two tricks for better movement, add the following to your .vimrc:

    " for scrolling up and down quickly
    nnoremap J 7j
    nnoremap K 7k
    vnoremap J 7j
    vnoremap K 7k

and the second (which requires a third party plugin):

    " 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 first one originates from recognizing the problem from the antipatterns article: that spamming j j j j to get down to the line you want is dumb. But I choose not to follow the advice of most vim articles I read which is to learn built-in tricks such as typing 10j or :<line number>. The milliseconds it takes for me to count the number of lines I want to go down or assess the line number of the line I'm interested in aren't worth it, I'll just tap j if the line is close enough or J if it is five or more lines down. I think it is a good solution.

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.

[1] https://github.com/easymotion/vim-easymotion

Have you tried using :relativenumber? You still have to type eg 12j or whatever but at least vim does the counting for you. If so, can you share why you like easymotion more? Thanks!

Yes, I use :<line number> very occasionally, mainly if I know I need to edit a certain line number in a file and just opened that file. But for regular use the time to type in a line number is just too long since I can't touch type numbers very quickly (when do we ever get practice typing in long numbers after all?).

I use easymotion because it's the fastest way to go from my eye spotting something on the screen to my cursor being there. It's two button presses consistently, you can't really beat that with some combination like 5j$2b, especially since that combo is different every damn time.

For better scrolling:

    nmap <C-j> 3j3<C-e>
    nmap <C-k> 3k3<C-y>

(replace "3" with whatever number you like best). These shortcuts will enable you to scroll the text, while keeping the cursor fixed. It's similar to web page scrolling. It helpls you type in code while maintaining an overview on what's going on below and above it. Add these to your .vimrc and use them for some time. You'll thank me later.

I could see using that with J and K because I use c-(hjkl) for moving between open buffers in a tab. Nice tip though.

   map <C-h> <C-w>h
   map <C-j> <C-w>j
   map <C-k> <C-w>k
   map <C-l> <C-w>l

I have some similar mappings in mine. Capital J and K go up or down 4 lines, capital H and L move by words instead of characters. It feels like holding down the button to run instead of walk in Super Mario Bros.

Ahg, no I couldn't do that, I need to keep J as Join lines. That's pretty useful to me. Kinda the inverse of gq.

Ah, I bound join lines to :join since I don't use it that often. I still encourage you to try binding something to 7j (or whatever number of j's feels right). One of the best shortcuts of my life.

I tried to use J, but it's somewhat tied to my muscle memory already (and I'm surprised I use it quite often joining comments and stuff). If you're like me, remember that you can abbreviate :join to just :j.

The advantage of using J and K is that they're very vim movements, but if can't because of :join, another workaround would be to use <PageUp> and <PageDown> since they're redundantly bounded to <Ctrl-B> and <Ctrl-F>:

    nnoremap <PageDown> 7j
    nnoremap <PageUp> 7k
    vnoremap <PageDown> 7j
    vnoremap <PageUp> 7k

I use that a lot as well, along with K to look up the current word in the man page.

I started combining {} with zt zz zb. I feel like it mimics physical handling of a scroll. This requires some empty lines though. In case I work with dense text, I usually switch to H/M/L also (combined with zt zz zb).

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

I have similar habits, but use zz to recenter the cursor (instead of z.), and gg (instead of 1G) to move to the top. Very quick.

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 remap { and } so I they land on the first and last lines of a block of text between blank lines, rather than the blank lines themselves. I find this is usually what I want then I just move/ take action in a more targeted fashion with f, t, w or the vim-sneak plugin.

I use the same sloppy methods. What matters to me is speed and staying in the zone while editing. Trying to get the positions precisely right forces me to think consciously and takes me out of the zone.

About the 'O' problem, try ':set noesckeys' and see [1] for more.

[1] http://stackoverflow.com/questions/2158516/delay-before-o-op...

I find normal mode much more pleasant with space mapped to 10j and backspace mapped to 10k. This combined with / and ? make navigation pretty quick without having to mentally switch context to think about the vimgolf way of getting places.

My favorite "secret" vim feature, that no one has mentioned yet:

    set scrolloff=999

That will keep the cursor in the middle of the window always, except at the start and end of the file. Before discovering that I used to `zz` after nearly every movement; that's all gone now, saving a ton of time and frustration.

I would go nuts; I prefer to use the whole screen to see what I'm looking at, and if I've just searched a buffer for a function name or whatever, there's a good chance I want to see the whole function and not the (screen height / 2) lines above it. (In emacs this is done with `C-l C-l`, in vim it's `zt`)

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.

Oh guys, thank you so much for new food for my vim-addiction. I'd hesitate to call myself anything but an interested beginner, so it's always very welcome to learn new stuff. I distinctly remember running vimtutor the first time as a teenager fresh of whatever Windows came before and thinking 'goddamn, whyyyyyy is this hot mess so popular among my mentors and idols?'...

Quite some years later, I don't think I could ever do without vim. Not saying that emacs wouldn't probably fill the same role, editor wars considered and all. I just had somebody tell me to pick an editor and get good with it, some blog or forum posting made me go with vim and it's been one of my favorite pieces of software since.

To contribute a little bit, what I've really come to learn recently is the 'hybrid line numbering mode' that was added with 7.4 iirc. When you add both. set relativenumber

set number

to your .vimrc, you get relative numbers for all lines except the current, which is displayed as absolute. Helped my navigation game a huge deal. Just in the unlikely case anyone here hadn't heard of it.

I tried this very briefly and thought "This seems useless." 1. It's annoying how they all change every time my cursor moves (though it'd be fine if I also did "scrolloff=999"), and g-4 doesn't work to jump up 4 lines.

Then I realized I could do y6k to pull the next six lines, rather than "told on, let me count/do the math on the line numbers". Took me another moment to realize "4j" is the way to move.

I think I'm going to like this.

on the O thing: check :nmap and friends to see if you have a 2-letter mapping set up that starts with O. This has caused issues for me in the past when I wanted to use a key that was doing double duty already—vim has to wait just a sec to see if you keep typing and it needs to act on that.

I've found it helpful to use relative numbering in normal mode and switch to absolute numbering in insert mode:

  set relativenumber nonumber
  autocmd InsertEnter * :set norelativenumber number
  autocmd InsertLeave * :set relativenumber  nonumber

IIRC this tip was from the Practical Vim book

I can't remember or find what the "slow O" is about, but it's definitely real; I think I read about it in relation to it being fixed in v8.

> If something is more than 2 or 3 objects away, I approximate

set number + set relativenumber is pretty awesome for line counting. This marks all lines with relative numbers, except the current one.

These are all good tips but most of the anti-patterns seem to skew towards beginners (e.g. don't use the arrow keys, don't navigate in insert mode). One that I think is more common among intermediate, and even advanced, users is the misuse of tabs, windows, and buffers.

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

[3] - https://github.com/junegunn/fzf.vim

For any Windows devs that happen to use vim inside of mintty (that comes with downloading git), you'll discover that installing fzf doesn't work out so well. It'd be fine on cygwin, surely. In mintty, though, it'll yell about missing ncurses and then offer to install the legacy Ruby version, which also fails for curses related reasons.

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>

> vim inside of mintty (that comes with downloading git),

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.

This looks really promising. Thanks. And Git for windows is using mintty, which is a terminal emulator for cygwin, msys, and msys2, but I'm not really sure what is being provided/used. A buncha unix tools and definitely not a package manager.

And for those unaware:

> MSYS2 is an independent rewrite of MSYS, based on modern Cygwin (POSIX compatibility layer) and MinGW-w64 with the aim of better interoperability with native Windows software.

> The name is a contraction of Minimal SYStem 2, and aims to provide support to facilitate using the bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains.

> We wanted a package management system to provide easy installation of packages, and ported Arch Linux's Pacman. This brings many powerful features such as dependency resolution and simple complete system upgrades, as well as providing the build system - makepkg{,-mingw} - which is used to make these packages

Also: http://stackoverflow.com/a/25023611/463678

Github: https://msys2.github.io/

Msys2 also has mintty, and I can attest that tmux works great, if that's a consideration. This is pretty much where I spend my days (Msys2 / mintty / tmux / vim) when I have to work in Windows.

Is there a popular convention for using something like this or cygwin, in that it has its own $HOME, and I have a buncha dotfiles in my Windows user home?

Possibly just symlinking it all over to MSYS $HOME?

I am definitely happy about being able to install tmux.

edit: just seems like I should ditch what I was doing in windows home, because git bash used the same home and I had everything there. ssh stuff, git config, inputrc, .vim, etc. But if I'm no longer using git bash, no need.

edit: sadly git runs very oddly in this. not sure what git bash is doing differently, but I'm comparing .64 seconds for a git status, versus over a minute with MSY2. weird.

> edit: sadly git runs very oddly in this. not sure what git bash is doing differently, but I'm comparing .64 seconds for a git status, versus over a minute with MSY2. weird.

Yikes! I work on a fairly compact codebase, so I've never waited more than a minute for anything except sometimes when fetching. (For that I blame the network, but I could be wrong.) Other operations seem snappy, and tig is pretty responsive. That being said, I haven't benchmarked against git for windows, so I could be wrong about that. Sorry to hear it's so laggy for you!

Personally I just never use tabs. Things like ctrl-p or the built-in tab completion for :buffer and :edit make switching files so quick I don't really need multiple workspaces.

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.

Thank you! you just sent me down a rabbit hole of figuring buffers out, but it was totally worth it. That second link is especially nice.

Yeah, I dunno. I see your point and will certainly explore it, but I easily use tabs for both. I mostly use marks to skip around in a file and tabs for opening different files. Why? Because I can see them. The drawback with buffers (and too many marks and registers etc.) is that it's easy to lose track of where things are. So tabs make buffers easy- you can glance up and see where the file that you need is.

The numbering system is a little screwy (starting at 1 instead of 0) though.

Well, I've been using vi and it's brethren since about 2002 and I've pretty much always used the arrow keys; after some point it becomes muscle memory...

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

> Do you see any big advantage of using a lot of buffers/tabs/splits over running multiple vims inside tmux?

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.

> Do you see any big advantage of using a lot of buffers/tabs/splits over running multiple vims inside tmux?

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.

Thank you for the tabs and buffers reminder, that is something that I should keep in mind now that I'm using Vim on a 4K monitor. At that scale, it feels perfectly natural to have 9 to 12 windows open, so that all of the sources that I might need to even consider are within my field of view.

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.

> One that I think is more common among intermediate, and even advanced, users is the misuse of tabs, windows, and buffers.

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.

I was originally a die hard Emacs user, but I started to feel a bit of strain on the whole holding Ctrl+p, Ctrl+n etc. I was trying to find an editor/plugin that can reduce keystrokes or at least the strain. I ran across EVIL for Emacs which is just a Vim emulation and keybindings for Emacs users. Unfortunately I did not like it at first the entire hjkl felt awkward and all those modes - OMG. But after toying around with it a bit and playing the online interactive vim learning game I started to see the benefits of Modal editing.

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 love vim but admittedly ctrl-backspace-backspace is just as fast as d2b and works in nearly any editor. The stuff i really like is stuff as dt. which will delete until the end of the sentence, ie until the period. Or di( which deletes everything inside the parenthesis.

also for html cit and the rest for general purposes ci), ci', ci", interchangeably with d, or y. that was probably the first time I just has to sit back and take a second.

Try Ctrl-w in insert mode it is similar to Ctrl-backspace. Also in normal mode try db. where '.' just repeats the last command 'db'. I find I'm never really using counts in vim but instead using the repeat command '.' since it provides better visual feedback.

I decided one year that I would force myself (a vi die-hard) to use emacs for everything for an entire year, to see if I ever got used to it. One thing that never stopped driving me crazy was that there's no efficient way to duplicate a line like yyp in vim. The closest I could ever get in emacs was ctrl+k k ctrl+y ctrl+y (that is, delete the line and then paste it back twice). Looking online for a solution leads me to believe that the only way to really effectively use emacs is to learn lisp and reprogram it yourself.

...Which is actually quite simple. Here's my function for doing that that I wrote just now:

  (defun duplicate-line 
    (interactive)
    (kill-whole-line)
    (yank)
    (yank))

Five lines, and it took me all of ten minutes to write, including looking up the names of all the functions. Of course, there's probably a better way to do this, but I don't know what it is. Now all you have to do is bind it to a key.

Or, of course, you could just record a keyboard macro to do it instead.

I have mine set up like this:

https://gist.github.com/asummers/7784d40b1bc53ee309777274e9d...

That way I can hit M-w when I don't have a region and get the copy behavior for the whole line.

That's cool. I have no idea how that works, but it's cool.

You could use C-S-<backspace> C-y C-y, which uses kill-whole-line (C-S-<backspace>) instead of kill-line twice (C-k C-k).

I think that's reasonably short (same number of non-modifier keys as vi!). Of course, if you find yourself doing it a lot, you can configure Emacs however you want.

> feel a bit of strain on the whole holding Ctrl+p

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 enables you to hit "ctrl" with your thumb (next to the spacebar), and capslock becomes the new "alt". so no more reaching for that hard to reach LCtrl key with your pinky.

it's a tad bit weird but all the other command power you get from vim is just really comfortable. But I can see that swap working out in vanilla emacs

sure - it's not a vim or emacs-specific re-mapping tbh, because many programs require liberal usage of ctrl.

the inability to press left ctrl with the top right of your left hand palm is an unfortunate side effect of most laptop keyboards.

Nah, swap Ctrl with Capslock. Alt is by far less commonly used. I swapped alt with RShift for a while, but Alt is fine as Alt really.

right. Alt is less used - which is why I mapped it to capslock: i find LAlt easier to hit with my thumb than capslock with pinky

I find the opposite. I don't know why. But whatever works...

I got some basic muscle memory in Vim, then tried for a long time to learn emacs. Now I've found spacemacs, and couldn't be happier (which uses EVIL mode under the hood). If you haven't tried it, you should check it out.

Unfortunately I'm using windows for my main os, and emacs does not work as smoothly on windows as it does on mac/linux. But now you got a beefy framework with all the bells and whistles from spacemacs, I really like to keep my plugins lean and specific to my needs. also now you need to worry about layers being maintained in spacemacs, which can be a good/bad thing.

I have tried it out loved the ease of it, but not the trade off for hangs and crashes.

I've been using emacs on Windows at work for the last few years (at home I use macOS (nee OS X) and linux). What issues have you found, in particular, that were hard to adapt to with emacs on Windows?

I was referring specifically to Spacemacs, vanilla Emacs I don't have any issues aside from missing a few features such as ssh on a clean machine (I had to install plink from putty to use with tramp but spacemacs would have the same issue). Everything else I use mainly for golang or front end and it works really well, I don't crash or hang on anything including autocomplete, eldoc, godoc. I would sometimes freeze in Spacemacs for unknown reasons on start up or even opening a .go or .php file. I didn't feel the need to learn the ecosystem of Spacemacs for the small benefit of layers. I just install EVIL and configured it as I wanted and learned the packages I found useful from Spacemacs and just installed them from Melpa.

I found that on windows Emacs feels sluggish, load times (first open + os files or Ctrl+r+l, scrolling), GUI update on scroll, colors and overall speed of things like shell/auto-complete work 'faster' in mac or Ubuntu/Arch. I don't have any benchmarks to prove it but I do notice a difference between the environments I work on and the machines are relatively close in hardware specs.

as a side note, I did try to use Emacs as a SQL client but it becomes really difficult really quickly, for db development SSMS/VS, or pgAdmin would be better. Unfortunately I was still unsatisfied with those tools until I found Data Grip from JetBrains, it's worth every penny and has an a-okay vim plugin that allows me to work on databases a lot easier. Sadly there are limits to what I can develop inside Emacs productively.

I find myself to use the numeric movements rather rarely in vim, instead going for visual mode more naturally. Especially if n > 3. I don't need to count and have a visual confirmation on the active region.

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/\//?).

If you look at the Keyboard that Bill Joy developed vi on, the esc keybinding actually makes sense, and the caplocks keybinding is basically what he used.

https://en.wikipedia.org/wiki/Vi#/media/File:KB_Terminal_ADM...

I guess it'd be more like tab, but whatever.

> shift+ctrl+left arrow x 2 + delete

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

horrible example on my part but in every day editors to delete 2 word backwards it would either be (what i'm used to is shift+ctrl then left arrow key 2 times + delete or start typing to change. Someone else mentioned ctrl+<Backspace> works just as fast. I probably should have given a much better case. However, my point still stands that pressing db or d2b is within home row or as other mentioned db. and then how ever many '.' you want to repeat also works nicely without have to "strain" my hands out of home row. I find having to extend my pinky constantly to backspace after an 8 or 12 hour day just really adds up I'm trying to find the best way to stay comfortable for prolonged hours with the least amount of key strokes.

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

Home row? I understand you completely: Ctrl+bbdd does what you asked for.

Vim's d2b actually moves far away from the home row (note the "2")!

Not wanting to do the finger acrobatics? I'm even more with you here: I remapped Ctrl and Alt to be just next to space, and space to serve both as space and shift.

And, to point out that vim absolutely requires pinky acrobatics all the time with its reliance on : and ESC, so IMHO it is even more demanding than emacs there.

My fingers feel more comfortable by using numbers but also I should mention using relative number line is important to go up and down quickly (pinky on backspace is a bit far vs over 1 key for me to use unlike the distance to :) or holding down ctrl + pnfb. Caps is so close to 'a' that it really doesn't feel strained about 1-3cm movement at most to change modes. Everything is a learning process :) but to say it's more demanding as in quantity sure, however the work that's involved is much less than going a further distance.

and I do believe all the numbers are within home row distance not like <Esc> which way up in the Artic on most keyboards before being remapped.

Esc is the bad one in my view, but I never press it at all while using vim. This comes down to two factors:

- I use "jk", typed quickly, to exit insert mode. Most vim users I know use either this or "jj".

- I have rebound Caps Lock to Ctrl, and in the few situations where I would otherwise hit Esc, I hit Ctrl-C, which causes much less strain. (This is technically different than Esc, but the difference doesn't usually matter; if it's necessary, Ctrl-[ functions exactly the same as Esc.)

I switched to Spacemacs a few months ago and didn't look back since. Its basically Emacs+Vim+Steroids+More.

Just the leader key and layers alone are incredibly powerful concepts Spacemacs brings on top of Emacs/Vim :)

Did you switch to Spacemacs from Emacs or vim? I tried getting into Spacemacs from vim and found it quite overwhelming with all the config files and additional configuration that I had to do so instead I went for just Emacs + EVIL mode and built from there. I've gotten pretty used to Emacs and Elisp now, would it be worth it giving Spacemacs another shot?

i tried switching from vim to spacemacs but all i got was a bunch of keybinds brought back to my .vimrc such as <space>fs instead of :w (:update) that saves my right pinky for less used commands.

I switched from Emacs, had already read https://gist.github.com/nifl/1178878 a few months prior which got me REALLY curious about Vim. I was using Emacs Prelude before and spent vast amounts of time customising my Emacs.

Then coworkers suggested spacemacs after I talked about an Emacs/Vim hybrid and tried it afterwards, oh boy :)

The main advantages of Spacemacs, IMO, are its community creating good quality layers, the concept of layers itself (think of it as a group for a major mode and its associated minor modes - makes config a lot cleaner), running almost everything through helm-mode (which isn't fun to integrate that well yourself), and its space leader key (hence spacemacs) on top of helm-mode giving you self-documenting navigation through every single command.

So saving files becomes "space f s" opening files is "space f f" and if you idle a few seconds at any point helm-mode shows you all the possible options, so its very easy to learn gradually.

I gotta admit I jumped headfirst into its tutorial and when I had completed it went on to read the full Spacemacs documentation, so most of the the learning curve was rather easy over a week or two, yet months later I'm still learning new things :)

I can't stand Spacemacs. It's too complicated. I'd rather write my own config, thanks.

I also tried spacemacs multiple times. It helped me completely re-designing my vim config into layers but in the end I wasn't 100% happy with it. It is way too heavy, comes with too many batteries and does so much magic that troubleshooting a problem becomes increasingly difficult.

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

Shameless plug: I wrote a small guide about how I switched to Vim, after having “tried” for years. It’s not a universal approach, but maybe it can be useful for people here: https://github.com/bpierre/switch-to-vim-for-good/blob/maste...

This is a great resource, but the article is pretty strict on the arrow keys. I would recommend `nnoremap`, over `noremap`, because it only disabled the arrow keys in Normal Mode.

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 don't really disagree with your overall point, the arrows keys are not horrible, but I think for beginners removing all arrow keys is the best approach. I used vim for a while just relying on the arrow keys, and it wasn't until I disabled them completely that I really started to use vim. If I left them on in insert mode, I would have just ended up using them that way, just due to muscle memory.

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.

Absolutely agree. I completely disabled arrow keys for a short time; ~3 months. It started out after reading a similar recommendation. It was difficult for a few days, but then I completely forgot about my arrow keys and the fact that I disabled them. It wasn't until months later that I was in one of these situations that I wanted to use the arrow keys, but they didn't work. Which was confusing.

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

I tried and failed to make myself use `hjkl` instead of the arrow keys. It was a perpetual hindrance to my brain that up (`k`) and down (`j`) did not spatially reinforce their functions.

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 then added two more keys beyond left and right to skip forward and back by words.

      i
    hjkl;
    
    h -- skip backward to the beginning of a word (ordinarily `b`)
    ; -- skip forward to the end of a word (ordinarily `e`)

There were some echo effects since I had to replace `i`, but they were manageable. On machines where I don't have my vimrc available I'm still functional, just clumsy. It was definitely worth it.

My vimrc: https://github.com/rectang/dotfiles/blob/master/vimextra

Oh god... doesn't this mess with plugins or something?

Speaking as someone with a similar setup, I've never had many issues with plugins assuming the use of hjkl. The only one I can think of offhand that has issues is indent-object.

The thing that really causes issues is my attempt to swap the roles of [ and {, using [] to jump between paragraphs and {} to do fancy function jumping. Vim plugins really don't like that...

Someone else has found the wisdom of ijkl! :D

My setup uses "u" and "o" the same way you use "h" and ";". I also extended it so you can use modifiers on I and K to get page up/page down behavior, or to navigate between indentation levels.

I've tried not using the arrow keys, but my problem is that I use the dvorak layout at home, and typing jcvp to maneuver around (what hjkl maps to) confuses me too much. Especially since I use vim at work as well on the normal qwerty layout. Maybe I'll try again soon. In the meantime, I'll try to incorporate *, #, and gi into my muscle memory (for both layouts).

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.

Or, get a keyboard that allows for the thumbs to be used for more than just the spacebar! :)

Something like this: https://ergodox-ez.com/collections/frontpage/products/ergodo...

Personally, I NOP-ed all arrow keys _and_ hjkl also, after I found myself keeping j pressed to get to an area at the bottom of the window. Which would be an L. Then NOP-ed, bit by bit, many other things which could be done faster. 90% of my movements are search, BWtf{} and some scrolling with zt zz zb. The only case I found the lack of hjkl problematic so far is in block visual mode.

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.

Either way, mapping the arrow keys to <nop> seems wasteful. In normal mode I map up/down to :cprevious/:cnext and left/right to :colder/:cnewer, which makes error list navigation effortless. Some other good targets are the buffer, tag and location lists (with a little work you could make them context-aware too). I don't remap the arrow keys in insert mode though, it'd be annoying to have to exit insert mode only to move the cursor a few characters.

While it's unarguably fun, I can't believe the effort required to become actually good at vim (as opposed to just using a few of the easier features) will ever pay itself off. (These days, at least - if you spend your days editing code in a terminal over a dialup connection, then it's absolutely worth it!)

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.

Did you take the time to learn vim? Just start using it. With only a small subset of commands you can be pretty damn efficient. The fact that you can compose actions means that you don't need to remember every command - you can just create them yourself. After a very short while you will "get" it. You can say to yourself "I want to change the next three words" and immediately do it by pressing "c3w". Or you can move around with your mouse. The former is much faster.

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.

Oh, I've been using it for years and I'd consider myself an adequate vim user. I'm quite comfortable in it, just using the basics - but given the small amount of time I spend using it these days, the added investment to learn the more seems redundant.

It's not really about adding up time saved, it's about staying in the flow. I think you can probably achieve that by being really good at almost any editor, but vim probably does it a little better than most and it has the advantage that it's everywhere (including IDEs).

For me, it is definitely worth the effort. But I didn't try to learn it all at once, so it didn't feel like that much of an effort. I got good enough at first, then as I kept using it and found something I was doing repeatedly, I'd figure out the easier "vim way" to do it. Over the years all those little improvements has made me able to edit code far more quickly than I could possibly do with another editor.

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.

  Any extraneous cognitive load just takes focus away from what I'm actually meant to be doing.

And Vim is the tool to do just that. It saves your cognitive load spent to edit text so you have more for thinking.

> "If you have to move more than a couple of lines, moving one line at a time by holding down j or k is inefficient."

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.

As an Emacs user I want to plug ace-jump-mode to move around the viewable part of the buffer more efficiently than many of the commands mentioned in the OP's post.

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

I have got to try AceJump one of these days...

This reminds me of easymotion.

Just a question of practice, I found. I was a regular vim user in the past, and this was my criticism of in when first starting out - but after a while I found myself unthinkingly coming up with surprisingly complicated sequences of keypresses. It's possible to get very good at subconsciously sizing up editing operations.

These days I use emacs, and I pretty much always move the cursor using the mouse.

While I use j and k a lot for local moves, for bigger jumps I almost always use other means: jumping to a mark, searching for a string, :123 to jump to a line, gg and G to go to the start and end. Or, less often, I fold and navigate around the folds, although I'm not a big fold user. I very rarely hit hjkl more than ten times in a row.

Well I got really good at it after like 5 years of using it, and that muscle memory never kicked in for me. So maybe it's possible that it can be done, just not by everyone?

Honest question: How does Emacs help with this particular problem ?

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 ?

> How does Emacs help with this particular problem?

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.

Normal vim users aren't thinking about the most efficient way to perform an edit, but rather just go with muscle memory. Said vim users also don't write blog articles on how to be more efficient with vim.

Well after 5 years of using Vim, the muscle memory for more efficient operations never kicked in. I was either holding "h" and "l" to move around, or I was consciously thinking of the more efficient combined operations like "f.ce.com^[". And that conscious thinking was very distracting from the actual code I was editing.

I used vim for everyday use for almost ten years before I realized that navigating around with the keyboard would never be as good as clicking a mouse. All the mental overhead of trying to be efficient with vim, for me at least, ended up being a bit of a false oasis.

I happily switched to Sublime for two years and then VS Code. I still use emacs with Clojure though.

Emacs is unbeatable for editing lisp code. Geiser, Quack, SLIME, and CIDR are all excellent.

Similar story here. I use IntelliJ for Java and Emacs for Clojure. We're porting our codebase from Clojure to Java at work, so soon it'll all be IntelliJ, which will be pretty sweet. I do kinda miss Paredit, but IntelliJ makes up for it with lots of other pretty sweet features.

Out of interest did you try using the Vim plugins for Clojure?

I'm only playing, but found a good set-up with vim-fireplace; vim-clojure-highlight; vim-sexp; Vim-sexp-mappings-for-regular-people; vim-surround and luochen1990/rainbow

What prevents you from using vim inefficiently in the same manner?

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

IME, you do develop muscle memory in terms of using more "efficient" ways of navigation and text manipulation after using vim for a while. I guess it's sort of like learning how to drive a vehicle equipped with a manual transmission. At first, you're thinking more about how to shift through the gears and use the clutch. After a while, you don't really think about it too much while you're still doing it. After driving a bit longer, you start to get a feel about which gear to choose for a given traffic situation.

So, similarly, you get a feel about which keybinding to use to change certain types of text or do certain movements without having to think too much about it.

Of course we do: You can jump by searching for line contents with C-s, you can do an operation a certain number of times with M-<number> <operation>, and do an operation four times with C-u <operation>, which chains, so you can do an operation 16 times with C-u C-u <operation>.

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.

> "But you can also just use C-n, etc. and we won't judge you for it."

This is probably the biggest selling point of the Emacs community. They're not going to try to guilt or shame you into using more efficient or more advanced commands. If C-n works for you, use it!

Of course. We can't judge you. Your configuration and setup is likely so different that unless we meet up in person, it's impossible to tell who is more efficient.

Wait, how’s this different from Vim? You can use :<number> to go to a line and C-o to return to where you were.

It's really not different, except that we have more, better options for how to go about it. The difference is, you can just use C-n, and nobody will complain that you're doing it wrong. Well, not too much, anyways.

Sounds like the options are the same. Note that it isn’t some kind of Vim standard that j shouldn’t be used repeatedly, just this author’s opinion. I do it all the time.

Does vim have the ability to jump to compiler errors, ctags integration, cscope integration, and integration with sourcecode parser based tooling?

1. place hand on mouse

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.

:set mouse=a

Personally I think some people just go too far with that kind of /efficient movement/ thinking. There's nothing wrong with pressing j or k a few times, and I agree it's a waste of brain energy to think hard about how to get wherever. (I also think hjkl vs arrow keys is overrated, though I've learned to use hjkl)

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.

Not trying to start a flame war here, but I in recent few years I am seeing Vim being more popular, and I feel it adoption in terms of younger developers (those who weren't programming when original Vi was around) grows. (Ok, please forget about GUI editors, they have their audience, and I am not comparing any of those facts to them) I used Vim for 3 years, and found philosophy and implementation of modal editing amazing. Writing and manipulating code in it went like bread and butter.

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.

Emacs was far easier for me than Vim was. To this day, I have no idea how people learn Vim. And the scripting is awful, especially compared to Emacs, which is really a script interpreter that has a built in text-editor script and some useful primitives for text editing.

> I have no idea how people learn Vim

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?

Yeah, scripting a huge focus in emacs: they say it's a scripting environment that happens to have a text editor embedded in it. I don't know who "they" are, but they're quite perceptive.

Some lisp experience (especially CL) can help with learning elisp, but it's entirely possible to do so without it.

The process of learning emacs is roughly this:

-Launch emacs

-Run through the tutorial

-Learn the shortcuts and gain gradual proficiency in the editor (this step can optionally come later)

-Find something you want, or that annoys you (I wanted to have Solarized Dark as my theme)

-Google how to fix it, introducing you to .emacsrc and .emacs.d

-Copy snippets into your .emacsrc (or .emacs.d/init.el)

-Gradually learn elisp as you customize your emacsrc and snippets to your needs.

-Start writing your own snippets, with the help of the excellent documentation.

-Begin writing about how great emacs is online (I am here)

-Eventually start writing full-fledged emacs packages.

-Master the intricacies and horrors of elisp. Begin to despise the language. Comfort yourself by saying, "at least it isn't vimscript."

-Start supporting xemacs in your emacs config and packages. At this point, your config is a large hierarchy of directories. If it wasn't, it is now. If you didn't hate writing elisp already, you will now.

-Under the pressure of the demands of your users, spend more time working on emacs packages and other improvements to emacs than your actual work.

-Snap, and spend the rest of your days improving emacs and writing tributes to RMS.

Most do not follow this learning curve to its conclusion.

hehe - I made it to step 4, anyway.

The only thing that sort of scared me off of customizing emacs is that if I, say, SSH into a remote box or go to another co-workers computer, my customizations won't be there. That's why I do my best to stick with "out of the box" vim defaults (and vi defaults if possible): I know they'll always be there, wherever vi is.

Well, that's the drawback to emacs. It's also why most people don't change the default keybindings too much: some functionality may be missing, but muscle memory won't betray me if I ssh into a fresh emacs setup.

However, there are some ways to combat this.

Firstly, you can keep your .emacs.d on github, and pull it down to whatever machine you're working on. Indeed, this is what many emacs users advocate.

Secondly, many emacs users will ask: Why are you launching emacs over SSH at all? Instead, use TRAMP or SSHFS, bring up the folders under dired if you need to see the folders, and edit the files with your local emacs.

You can become compotent in emacs without customizing it, but the customization is a big part of why emacs is great.

Haha, you described many things perfectly! But what drove me the most towards emacs despite being suitable for FP, huge amount of tweaking and customizability it provides. And it felt much better doing it in Elisp than Vimscript. Everything has it's good and bad sides, that is normal imho. But really nice comment! :)

Of course.

Although emacs is no more suitable for FP than vi really, other than having better support for some of the functional languages, and for Scheme and CL (which aren't functional, but are often associated with FP, and are sometimes written in that style.

> Vimscript

I'd go so far as to say that if you _don't_ feel comfortable using vi "out of the box", you probably should steer toward something else - vi is just not customizable like other editors/IDEs are.

Best of both worlds: http://spacemacs.org/

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

I can't stand Spacemacs: it's far too complicated, and I'd rather write my own configs, thanks. Also, I could never get used to Vim-style modal bindings.

It works until one wants to create their own configuration stuff and functions and stuff. Much rather just stick with normal emacs configs and stuff and put in EVIL-mode once my pinky finger can no longer reach Ctrl (Not a worry seeing as I need Ctrl for gaming as well).

Also, installing plugins requires one to create one's own layer? Eww.

It's complicated, true.

But it does a lot of work for you.

I started to create my own setup from scratch with Evil etc.

But recreating all that Spacemacs has, especially with customizing all the plugins for Vim keybindings, is countless hours of work.

You can skip the layers and side-install custom plugins quite easily though.

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

actually they aren't. At least for me. I mean, C-p I won't be pressing with one hand, I use both. I have pretty long slim fingers. I am touch typist too, so yeah sometimes my pink is used a little bit more than I would like, but I didn't feel pain or discomfort. Vim is far far better in that term.

Sure, I'm touch typist too, and use both left and right ctrl keys, never chorded with one hand.

You won't feel anything now, but 3-5 years down the road you might start to feel the strain.

Couldn't agree more. I just recently switched over to Spacemacs after having used Vim for over 5 years, and the transition has been so smooth. With Spacemacs, everything just works, whereas with Vim, I had constant struggles. Of course all of the smoothness can be pretty much attributed to Spacemacs. Looking forward to learning Elisp :P

I’m primarily a Vim user, but I use Emacs for some stuff like Common Lisp programming, Org mode, etc. But what I sometimes miss from Vim is the filtering with external commands. For example if I want to pipe my file through awk, I can just do

    :%!awk '<do some awk stuff>'

Does Emacs have something like this out of the box?

C-u M-!

of course it does, as said by nemoniac! Here: https://www.emacswiki.org/emacs/ExecuteExternalCommand

> I tried EVIL mode, and it is amazing, but something just felt wrong using it inside Emacs

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.

My main focus is on modal navigation, editing and dealing with text as objects - that's the real long-term benefit Vim gives me.

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.

Useful stuff. I'd add typing J to move the next line to the end of the current line. A move I normally do by being on the next line and then type 0dwiBackspace.

Only just figured that one out by mistakingly having the capslock on when moving around.

That's how I discovered "K". Which is usually not what I want, and tends to provoke a moment of "where did this garbage come from and where did my code go?" panic. I'm close to masking it out, but I remap very reluctantly.

> It’s always useful to jump back to where you were, as well, which is easily enough done with two backticks, or gi to go to the last place you inserted text. I

And here I was undoing and redoing the entire time.

Ha, I do the same - you always learn something new in vim.

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.

Hah, me too. Also yank-then-undo instead of finding out how to actually select and copy text.

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.

For anyone who wants to build muscle memory in Vim I'm writing 10 Minute Vim, a book of pre-made exercises for practising advanced macros, RegEx, and navigation. It's already helped me learn a number of new commands in just a short time.

https://leanpub.com/deliberatevim

This is good solid advice -- I have a problem with vim advice that golfs more unusual circumstances to save a keystroke or extensively remaps the keys. (Generally the only thing I remap is F1 to ESC, because I use laptops that place them inconveniently close together.) Devoting too many cognitive resources to text entry is also an anti-pattern!

I highly recommend not using the Esc key, remap to jk or caps lock that you can reach without moving your hands. It makes a pretty big difference.

Even easier to use the default Ctrl + [ instead of ESC.

I've somehow gotten in the habit of using ^C for Escape. Guess it feels natural from using it in Bash to restart typing my command or to kill a program.

That's not equivalent...

Easier than editing a config file, but not easier than hitting jk or kj. Just take the second to map it.

The reason I'm so reluctant to remap it is that I use vim in a gadjillion different environments, and I don't want to have to worry about managing .vimrc everywhere. Or is it _vimrc? Especially under Windows, when I have cygwin and msys2 both installed, keeping .vimrc synchronized is terrible. I'm more inclined to adopt ^[, since that should work anywhere, even in vi.

Fair enough I suppose. I fall back on ctrl-[ if I'm in another environment, but it's rare enough for me to not care about it being an untrained motion.

This. Hitting that wall when you're hacking on a file and discover after the fact that your fancy keybind remap isn't on this machine and now it's doing something weird...

Customizations are baggage. I try to minimize them as much as I can, even if it means being a little less efficient on my home system. A side effect is that if a program doesn't have sane defaults I'm not likely to use it, even if it can be made to work better with some tweaking.

I don't go much beyond :syntax on and :set si with Vim.

Note that d2wi and c2w are not exactly equivalent: d2w will consume trailing whitespace after the second word, while c2w will not. FAFAIK, there is no exact equivalent of d2wi using c. I usually end up using c2aw, but that will also consume any word characters preceding the cursor (not a problem for me since I usually navigate using b and w).

> d2wi and c2w

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.

Indeed. I try to come back to pages like this every few weeks, and to start training myself to use one more of the tips from it. Today it's * and # to go to the next/previous instance of the word under the cursor.

"Hitting Escape is usually unnecessary; Ctrl+[ is a lot closer, and more comfortable."

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

I suggest remapping Caps Lock to CTRL if you haven't remapped it already.

Yeah, I've seen that suggestion for many many years, but unlike evidently almost every other programmer in the known universe, I still use Caps Lock for its intended purpose (and yes, I know all of the ways I could avoid using it, but I still want to use it for that). I understand why people would like using Caps Lock for a CTRL key, as it reduces the stretch distance for many key combinations, but I don't find it enough of a problem to justify the change.

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.

I've always liked Control just fine where it is. Maybe my hands are weird, but I find it easier to reach than Caps Lock. I just curl my little finger a bit, and push the key with my knuckle.

The layout is also symmetrical.

I prefer remapping Caps Lock to Escape. Ctrl is already positioned pretty conveniently.

Plug for Karabiner on OS X, which lets you use capslock as a control if you press it with another key, and escape if its released on its own. It has ruined me for other computers that don't have this set up. There's also a way to do it under Linux, but I can't remember what the package is that lets you do that.

You're thinking about xcape: https://github.com/alols/xcape.

FYI, Karabiner is incompatible with MacOS Sierra. There's a project (Karabiner-Elements) to replace its (and Seil's) functionality, but I don't believe it has feature parity yet: https://github.com/tekezo/Karabiner-Elements

Wow thanks for the heads up... that would have been a shitty thing to discover the hard way!

Actually hitting escape is one of the things I most disliked, so learning CTRL+[ is great for me!

The first thing I do on any new computer I get is to swap the mapping for the caps lock and left ctrl keys. This makes ctrl+[ super easy (double pinky flick), and it also makes using the vim window commands (ctrl+w) easy to access, which I use a lot.

I double tap j to get out of insert mode.

ctrl+[ is closer but with an already over-used right pinky it is a bad idea. i much prefer jk as <esc>.

yeah, and with the only Ctrl-[ option that I would consider, you are having to use both pinkies simultaneously. I have a feeling I would just end up missing all the time and getting irritated.

> I could not possibly disagree with this quote more. Ctrl+[ is WAY more uncomfortable than using the Escape key.

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

"Did you try it with one hand or two."

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

> I guess I could see someone trying to type it one-handed with their right hand

That's exactly what I was thinking of. Years ago, I used to press key combinations like ctrl-c, ctrl-x by moving my left hand away from the home row and using my pinky on the ctrl key and my index finger on the c or x key. I thought you may have been doing something like taking your right hand off the home row and pressing the key combination with your thumb and index finger.

But I do find that using the modifier key on the opposite side of the keyboard requires less contortion for a given key combination (e.g., the shift-v or ctrl-v combinations for linewise or blockwise visual mode).

I'll just drop my 2 cents here as a vim user. I've tried emacs a number of times, but I've gotten too familiar with what vim has on offer.

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.

While these tips are good per se, in retrospect I don't think it's that a good idea to tie your muscle memory that much to a single piece of software. I'd say enjoy the cursor keys. Moving around in insert mode is ok too.

This is normally true, except that in order to be good at your job as a developer, you have to be good with your tools.

It helps that vim is installed by default in every modern OS.

But in reality you'd constrain yourself to using Vim just because it is the lowest common denominator (i.e. it is available - vi - in Sun OS 5.2 & co).

Otherwise, if it's a really modern OS, there's a plethora of modern, fast, cross-platform editors that follow CUA conventions.

Right, but a common characteristic of modern editors and IDEs is that they attempt to be uncontroversial and follow the 'intuitive' keybindings because they're what people are used to from word processors.

These editors have sparked a holy war and a cult following not just because they're powerful, but because they're opinionated. They prefer efficiency and customization over familiarity.

I will freely admit that there's only only so many of those programs that I can handle in my life, but my text editor is one so frequently used that it's worth the investment.

I sort of agree, but still ended up in the opposite corner. I use a keyboard which has no arrow keys and instead use <fn>-hjkl in every app with no (non-keyboard) configuration needed.

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.

Alternatively, you could just run :set mouse=a and then use your mouse to do things like scrolling, moving the cursor and selecting text. It's definitely a bit faster than using the arrow keys, but not as fast as knowing the most common vim normal mode keybindings.

Instead of

c2w

I prefer

  v2ec

selecting with v helps me avoid making mistakes.

The advantage of c2w is that it combines everything in a repeatable (using .) operation.

and so does v2ec

It's not the same. That will only repeat the change of the number of characters of the length of those 2 words. c2w, when repeated, will change 2 words, no matter how long the words are.

For example:

    This is a string of text.
    This is a string of text.

If the cursor is at the "i" of "is" on line 2, and you type v2echello<Esc>, you will have:

    This is a string of text.
    This hello string of text.

If you move the cursor to the "s" of "string" on the first line, and press ".", you will get:

    This is a hellong of text.
    This hello string of text.

However, if you had used c2w, it would have replaced "string of" with "hello" like so:

    This is a hello text.
    This hello string of text.

Visual mode is lossy in terms of text objects. It only remembers counts of character movements, that's why it replaced 4 characters with "hello" instead of replacing 2 words with "hello".

ct" or even ci" (or ci) ci] etc) is really useful to reset the inner contents of text delimited by ")] etc.. I use these a lot - http://fuckyeahvim.tumblr.com/image/122372862496

ci", ci), ci]... I love these, and use them all the time.

I find that marking my place with "ma" and returning to it with "'a" is a huge productivity boost. Of course the "a" is just a label, you can use any character (this allows multiple marks as well).

if you only browse code use gi, that saves me a ton of time. gi brings you back to last inserted text.

So I have used ST3 for years now, and I realise that I'm slowly moving toward Vim. I started using Vim shortcuts in Chrome, and now I use Vintageous in ST3. Vintageous is good, but it is incomplete. It can't even do the first examples on this article (ctrl+f / ctrl+b) correctly.

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

Vim has “multiple carets” out of the box with visual block mode.

Note sure about a guide but I would start without any plugins at first. Otherwise you never learn what's vim and what's a plugin, and working on remote servers will be a pain. Also for a lot of plugins, there's a better way of doing things in native vim if you learn it properly.

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.

For 1: ctrl-n

[ed: a little more context and detail: http://usevim.com/2012/07/06/vim101-completion/ ]

I can recommend vim-hardtime [0] for anyone wanting to force themselves to learn the "vim-way" of navigating. It disables n subsequent presses of hjkl where n is any number you want.

For me I set it up to not allow more than 2 steps in any given direction to remind me to use jumps instead.

[0]: https://github.com/takac/vim-hardtime

<C-c> works likes escape almost all the time. Mapping the caps lock key to Ctrl makes hitting <C-c> super easy. I usually use that instead of escape.

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.

This is why `f` is really my workhorse key in vim.

Movement is an important part of vim, but so is auto-competing. Probably the biggest thing that helped me greatly improve speed in vim was learning the C-x keys and that they are context aware. Having to repeat an entire or similar line/s becomes quick without having to go back to that place. Why move in the file when vim can find the text for you?

Pretty funny. I found myself asking "What does C-x do when autocompleting?" I took the 'x' literally, instead of realizing you meant C-n, C-p.

In insert mode, C-x actually lists the different completion methods, so it's actually accurate.

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

yeah, see my reply to the parent below. :D

x is literal. For context aware auto complete of a word try C-x C-n/p. For a line try C-x C-l. For a directory do C-x C-f. And remember that this is context aware, you can hammer C-x C-n C-x C-n or C-x C-l C-x C-l. Stuff is really powerful. Changed the way I program and I never see enough articles mention it.

Ah, this should really be easier to find in the vim docs. I did ":help ^x" and only came up with:

CTRL-X Subtract [count] from the number or alphabetic character at or after the cursor. {not in Vi}

After trying again today, I could not find any thing on context-aware completion no matter what help commands I tried. And I can usually find what I'm looking for there.

When I tried C-x in insert mode a couple of days ago, I'm not sure how I missed the: "-- ^X mode (^]^D^E^F^I^K^L^N^O^Ps^U^V^Y)" string that appears in the mode line. Perhaps I saw it and didn't grasp what it was.

I'm always amazed after so many years of using vim how many new things there are to learn about it.

> If you happen to know precisely where you want to go, navigating by searching is the way to go, searching forward with / and backward with ?.

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.

While I prefer vim for text-mode editing, it is so frustrating that it just has to use its own damn keyboard shortcuts and that the ones burned into muscle memory from 20+ years of using pretty much every text editor under the Windows/DOS sun don't work without significant hacking.

My favorite is mapping '()' to 'vi)', '[]' to 'vi]', '{}' to 'vi}'. So I can read is as "grab parentheses" instead of "visual inside parentheses"

> don’t forget you can yank, delete or change forward or backward to a search result.

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.

I agree it is very nice, although you should know one caveat:

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?

You might find vim-sneak useful: https://github.com/justinmk/vim-sneak.

https://github.com/easymotion/vim-easymotion is another plugin that does something slightly different, but also useful.

Page loads very slow and uses Wordpress. In case it goes down: http://archive.is/JaOXd

My eyes. Good content, but very hard to read.

I have a programmable keyboard, so I just map escape to be right above tab, where tilde usually is.

I use Karabiner + Seil to make my Macbook Pro's Caps Lock be Escape when hit by itself and Control when hit with another key. Unfortunately this doesn't work on Sierra yet so still on El Cap.

the lack of tilde doesn't drive you mad?

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.

They are working on a new version that for sierra: https://github.com/tekezo/Karabiner-Elements. I'm using it. It works, but you have to configure it by editing a json file, and there are some bugs still

Are you using a US-QWERTY keyboard layout? If so you're losing "switch case" (~); close alternatives are 'gu' lowercase, and 'gU' uppercase, not quite the same. And, "goto mark" operator (`); close alternatives is "goto mark, beginning of line" operator (').

Yes, I use an Ergodox keyboard. My `-=\ keys are right below my zxcv keys.

I have xmodmap. All keyboards are programmable. I do the control-capslock rebind, as is traditional among Emacs users.

I also typically use a Unicomp Model-M style keyboard, complete with springs. But that's an entirely different flame war.

Yeah, it's just nice to have the layout in hardware. And programming your own keyboard can be fun.

I recall reading somewhere that Stallman's keyboard had the CTRL key where the (totally useless) caps-lock key is on modern keyboards, and that's why he used CTRL+ combinations throughout emacs.

The most perfect keyboard ever envisioned (whose name shall not be mentioned) has the CTRL key there. It has no dedicated caps-lock key at all.

No, the Model M had a capslock there. It's one of its great failings.

;-)

This is a really good guide.

I started off using Emacs a lot (like tons and tons of Emacs with tons and tons of custom modes, functions, and craziness - network pong anybody?). For almost a summer, my xinitrc at the school labs literally opeed up a full screen Emacs; it was my window manager too.

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.

evil-mode

vim keys in emacs.

I don't want vi modality. I find it more annoying than emacs yoga-esque bindings. I want more sane emacs bindings.

You can make them yourself, and I think there are some packages for that as well.

Coming from evil-mode, I often have to make them myself, and it is a pain. Every mode needs new keybindings to fit in with whichever scheme you use. I imagine it would be worse with custom keymappings that aren't evil-mode, because I can at least use the default keybindings in input mode as-is with evil.

> I wonder if you could make a vim code golf puzzle set

http://vimgolf.com

Moving to the far left-corner of the keyboard to reach Escape has been a major annoyance for me. On the other hand, the Caps Lock key on my keyboard is almost useless. I never use that key. Is there a way to map Caps Lock to Escape in Vim?

I map Caps Lock to Escape, but I had to do it system-wide on MacOS.

Run setxkbmap in your .xinitrc if applicable:

  setxkbmap -option caps:escape

Linux desktop environments’ keyboard configuration tools should also let you do this.

I am using Windows. Is there a lightweight solution to map Caps Lock to Escape on Windows?

Copy and paste the below into a .reg file and run it. I used Sharp Keys ( https://sharpkeys.codeplex.com/ ) to create it, but since every major Windows 10 update resets your key mappings I just extracted it from the registry and double click the reg file after each update.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout] "Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,01,00,3a,00,00,00,00,00

> Vim isn’t the best tool for every task

Begone with your heresy!

Reply on news.ycombinator.com