Vim: Takeaways from One Year of Typing | Hacker News Reader

Vim: Takeaways from One Year of Typing

sankho.github.io

81 pointssankho96 comments

The thing about Vim is that I cannot imagine creating it and thinking, "This will be much faster and easier than a mouse eventually". But, I also wouldn't think that I could learn how to type fast without looking at the keys if I just stumbled across a keyboard, but both are undoubtedly true. Like anything physical, it requires practice and muscle memory. Would you rather go back to looking at every single key to type? That's how vim users feel about regular text editors. Try it out.

Doesn't vim (or similar schemas) predate the mouse?

Yes, it does. Well, actually vi, which is its predecessor.

yes it does, but I was just making an example from my viewpoint.

Absolutely - and you can say the same thing about a piano. A flexible, open-ended interface, combined with learning and practice, will vastly outperform any attempt to replace effort by an "intuitive" set of controls.

vim overhyped as an editor? It might be overhyped as a programming tool (you won't write 2x the same amount of lines in a day; you will not be 5x more productive), but as an editor, it deserves every single bit of hype that it has.

No other editor stands next to vim. A lot of people dislike editors. It's fine. There are a million tools out there that help people become more productive programmers. You might enjoy IntelliJ or you might not. You might like cscope or hate it. Tt doesn't matter. One needs to find the tools that helps him in their day to day job. But if you need an editor, vim is no doubt the single best out there.

nonono read the rest I love the VIM!

But... there's an abundance of internet quotes like "No other editor stands next to vim" (see parent comment), so I wanted to make sure the reader didn't think I was proselytizing.

I've switched from vim to kakoune some time ago. vim does have the advantage of a bigger ecosystem, but I do believe it is possible to have an editor better than it.

I've taken a look at kakoune. It's very similar to vim, isn't it? When I say vim, I also mean neovim, which currently is already superior to vim in a lot of ways.

The author of kakoune initially intended to rewrite vim from scratch, so there is definitely a similarity. A big difference is that kakoune operates in terms of selections rather than motions, with built-in support for things like multiple cursors as well. I find it more intuitive to use than vim, and just as powerful.

Interesting. I've already given it a short try and I can see some differences. Do you use it as your main editor when you need to use an editor?

Yes, I do use it as my main editor (I have "vim" aliased to start kakoune instead). Knowledge on how to use kakoune doesn't seem to interfere when I need to use vim for some reason (such as ssh-ing into some machine that doesn't have kakoune).

I too find kakoune interesting and have recently begun to add multiple cursor/selection support to my vim like editor.

https://github.com/martanne/vis

> No other editor stands next to vim

And no other operating system stands next to emacs.

I knew someone would answer that. It was just a matter of time.

We need some sort of variation of Godwin's Law when it comes to text editors. Something like 'the probability of someone mentioning emacs as great operating system in any discussion about text editors = 1'.

The great think about VIM is that it lets you do the same about of work with less effort. Over your lifetime, you might type half as many keystrokes to do the same amount of work. Look at VimGolf and the following video to see what I mean.

http://www.vimgolf.com

https://vimeo.com/53144573 - Precision editing at the speed of thought

All editors should place an emphasis on minimal typing.

Emacs has a few cool precision features too:

http://emacsrocks.com/e10.html - AceJump

The thing I appreciate the most about vim is not the fact that you can be a little bit faster with a lot of things; it's the fact that you can edit code for hours and you won't get tired at all. At least you won't get even close to as tired as you would were you using a mouse. It's simply the least painful of all the ways out there. I guess it's the main reason I use it.

Thank you for the links. I do use the AceJump equivalent for vim, and I have it mapped to <space>. It's quite nice, actually :). The only difference is that instead of pressing <space> and getting all the jumps available for each word out there, I press <space> followed by two letters, and it jumps directy to the word which starts with those two letters, or it simply shows me links to words that start with said letters if there's more than a word starting with those letters.

Yet the ancient Evil* from the elder world that is Emacs plots to consume Vim and absorb it's functionality. When that day is fulfilled what other editor will be able to stand?

* http://emacswiki.org/emacs/Evil

Here's the thing: when you're coding, how much time is spent on reading vs writing? For me it's probably 90/10. Since most my time is spent concentrating on understanding code, the last thing I want is an editor that forces me to consciously think about text operations. "d[downkey]4" might be theoretically more efficient, but I spend way less cognitive energy holding down the shift key and pressing the down arrow 4 times.

The other thing is efficient navigation within one file isn't super useful to me. I spend most my time doing find-in-files or jump-to-definition or rename-across-this-project. Vim kind of sucks for all those use cases. There are plugins of course, but that just brings it up to par with popular IDE's, except with a clunkier interface.

I say this as a person that knows vim well. If I'm SSH'd into a server and I need to edit a config file, vim is the first thing I'll reach for, but for coding, I'm pretty much only using it if I'm using a language that doesn't have a nice IDE already.

>Since most my time is spent concentrating on understanding code, the last thing I want is an editor that forces me to consciously think about text operations. "d[downkey]4" might be theoretically more efficient, but I spend way less cognitive energy holding down the shift key and pressing the down arrow 4 times.

The point is well taken, but don't forget that for most people that downside of increased cognitive pressure goes away after a few days or weeks of regular vim usage. I've been using it for about a year and all the combos I normally use are second nature to me (and have been for months). Don't underestimate the human brain's ability to grow and adapt and for incredibly complicated things to quickly turn into routine.

For the record, I almost never use vim's much touted hit a number key then an action to do it n times feature. I have modified it so j and k do the normal down/up one line and J K go down/up seven lines or so for scrolling. [1] If I'm doing something like deleting a line and have to delete a bunch (common case), then I'll "dd" to delete line and then hit "." (which repeats the last action) three or four times until satisfied. Way easier than counting the number of lines to delete then typing "4dd" imo.

[1] Note for anyone who wants to duplicate this: it was still unbearably slow to just hold down J or K to scroll because the default delay between depressing a key and when OSX decides you are actually holding it down and not just pressing it once is too long. Decrease it in the native settings of your OS for a smoother experience.

I used it as my primary editor for two months, which IMO is more than enough time to give to a project like that. I was efficient in it, but none of the supposed productivity gains came about. On the other hand, in my IDE I can control-click on a method name to jump to it, or hit ctrl-r to rename something across the entire project, or hit alt-enter to automatically import a symbol when I know the name of a class I want but I can't quite remember the namespace it's in. Those things really do save me a lot of time; but the efficiency comes from the development environment being able to understand the code structure, not from being able to stack key commands.

If someone wants to use vim I'm not saying they shouldn't, I just think it's vastly overhyped.

I found I had to go a bit beyond the settings that OSX's native manager allow for to get the key repeat that I was after. Karabiner has a setting for adjusting it properly in ms (so you ~ match other machines). would recommend.

https://pqrs.org/osx/karabiner/

I think your example is somewhat badly chosen.

If I had to delete four lines, I'd most likely mash dd until done, or maybe Vjjjd. It would be completely automatic and not require reaching for numbers or the arrow keys, making it significantly faster and more comfortable as well.

I find that vim is extremely good for reading code, since navigating around a file is very easy (and I am in no danger of accidentally editing code while not in insert mode.).

Not having to reach for the arrow keys while navigating is a huge plus as well, since it keeps my fingers on the same position whether I am typing or navigating.

EDIT: Vjjjd, not Vjjjjd. Drives home the point that it's automatic, since I can't get it right if I think about it...

Great point about reading the file. I feel paranoid when using a text editor like sublime now just arrow key-ing or scrolling around a file since hitting practically any key will insert or delete a character!

This is why any decent text editor or IDE has an UNDO method.

And in true TMTOWTDI fashion, I'd add that depending on what the four lines were (in relation to my cursor and their content and, frankly, whatever pops into my head first), I'd probably do 4dd, or d4j, or d] or d} (if the final line was the end of my current sentence or paragraph) or d2] if it was two sentences.

My favourite bit is that I use which one pops into my head first. If I think "until the next occurrence of 'nded?'" then that's what I do, with d/nded?<RET>. If I think "up to line 438" then I can do d438g. It reduces the number of decisions I have to make, which increases my mental stamina.

After using vim for a while, you don't think about text operations consciously, it's all subconscious / muscle memory. It's possible to do something like "shift+press the down arrow 4 times, backspace" in Vim by the way: "Vjjjd" or "dd...". In fact, as I was typing this comment I couldn't even remember what the right key strokes were and had to open Vim, delete 4 lines and try to consciously pay attention to which keys my fingers were hitting! So even if you have to think consciously about text operations in the beginning, don't let that scare you off as it will almost certainly become muscle memory after some practice.

As someone who uses vi mostly for reading and not writing, its almost no mental load. pgup, pgdn to scroll; ? and / to search; and G :0 to goto bottom/top. I use these without even thinking.

"""an editor that forces me to consciously think about text operations"""

"""I say this as a person that knows vim well."""

These two phrases don't go together.

Would you say you knew how to play a piano well if you were still consciously thinking about where each note was?

If you don't use vim to the level that it's subconscious and "in your fingers" it might not seem all that useful...

Fwiw "ag" and the various plugins around it make your use case pretty trivial.

> These two phrases don't go together

Sure they do. VIM has such a culture of minimizing keystrokes that pretty much anything you do, you start wondering if you could have done it with fewer key strokes, or if you could have done it better. It's hard NOT to think that way because that's the entire point of getting into VIM in the first place.

Speaking of minimizing keystrokes in vim, you might enjoy this puzzle from the 2012 MIT Mystery Hunt

http://www.mit.edu/~puzzle/2012/puzzles/william_s_bergman/in...

(because it's about minimizing keystrokes in vim!).

Edit: I didn't know about vim golf, which is a slightly different take on a similar phenomenon.

The goal is to be able to FLUENTLY edit text. Lowering the number of keystrokes can aid that but is ancillary.

Fluency comes after learning it well enough that you aren't thinking about it anymore.

Yes you should occasionally reevaluate where you are on that scale but I don't see that as what you are saying.

Enjoy your ide if you have it figured out to your satisfaction.

Cheers

For what it's worth, the author (sankho) mentions that he uses other editors for project-wide find and replace. This can be done in vim too (although I do not --- I'll return to this). You can check out the typically great vimcasts post on this: http://vimcasts.org/episodes/project-wide-find-and-replace/

For whatever reason, I find it easier to use commandline tools to do large search and replaces. I do embrace the vim-as-text-editor within the larger Linux-program-composability philosophy, but I understand that not everyone else does. So I use ack and perl, as mentioned in this StackOverflow post: http://stackoverflow.com/a/8744108/1141805

(Actually, sometimes I distinctly do things the wrong way. I open a scratch buffer, `:r! ls` to get my file names, restrict to those that I want, create a macro that does what I want on the file under the cursor, and then repeat the macro. I am not proud.)

Here's my find-and-replace command, copied from some StackOverflow answer at some point in time: https://github.com/tubbo/home/blob/master/bin/repl

It uses Ag to search over each file and Perl to perform the necessary regex. It also creates *.bak backup files in case I replaced something that wasn't supposed to be replaced, but will remove those backup files if I'm in a Git repo (because I basically had to `git clean -f` every time after using this command...so I just wrote it into the command)

It's possible to run a macro on a list of files? I usually just open the files one by one and @@:wq (oops)

Yes, it's quite possible:

  :args *.cpp  " or any other list of files
  :set autowrite
  :argdo normal @@
  :wq

The key to learning vim for me was to create my own vimrc from the ground up. I decided to not add anything to that file that I didn't understand what it was for. That and time. As long as you can open a file in vim, add a couple of lines of code and save it, you're good to go. Just keep using it and that vim magic will come to you ;)

> Relax! No other text editor has as many developers working on plugins than VIM.

What about emacs?

I thought this too when I read the article. Then it occurred to me that I don't have any idea how many developers work on plugins for either. Looking naively at github files by type is unreliable, since so many people do things like keep their .vimrc and .vim files on github which artificially inflates the number of .vimL repositories.

What I do know is that if there's something I want done, I suspect there is a plugin that does it. So at least morally, there are sufficiently developers for both emacs and vim (in my experience).

> What I do know is that if there's something I want done, I suspect there is a plugin that does it.

Maybe it's just my anecdotal evidence, but I've looked for alternatives to certain emacs plugins used by my co-workers (such as org-mode and ensime) and couldn't find a suitable replacement (I know there are some alternatives for vim, but they pale in comparison to their emacs counterparts).

We're talking about text editors, not operating systems.

(Sorry. I had to. Don't hate me!)

I know it's the old cliche, but I love emacs largely for that reason. When I'm ssh'ed into one of my boxen, I can do a simple scp and have all my configs for IRC, eww, org-mode, EmacsWget, my custom scripts, etc, everything in one place and managed under one system ecosystem, and from a terminal without having to touch/forward X. The longer I spend in it the less convoluted simple text editing becomes, I just think there is a high barrier to entry that is daunting even for command line jockeys.

I still vi/vim everyday too though, mostly because some things, like embedded stuff I work on, emacs would be too much, so it's very much situational.

> When I'm ssh'ed into one of my boxen, I can do a simple scp and have all my configs for IRC, eww, org-mode, EmacsWget, my custom scripts, etc, everything in one place and managed under one system ecosystem, and from a terminal without having to touch/forward X

And you don't even have to bother with that, thanks to TRAMP mode, which lets you open files on a local emacs from a remote system. You can even do it with sudo[1]!

I believe vim does have rudimentary sftp/scp support, but tramp can make it seem like a remote system is just an extension of your local system.

---- [1] http://irreal.org/blog/?p=895

>What about emacs?

From this, and I think HN is a good place for such a poll, it looks half as many people use Emacs compared to Vim.

https://news.ycombinator.com/item?id=8678339

And it actually should be even less, judging from people in my university and in every workplace I've been.

The great advantage of vim is that it forces you to use only the keyboard. No mouse at all! Mouse is slow. Keyboard is fast (once you get used to it).

Exactly. Recently, I switched to i3[0] and Vimium[1] and it's just wonderful. Now I'm way faster than before and hardly ever use the mouse.

[0] https://i3wm.org

[1] https://chrome.google.com/webstore/detail/vimium/dbepggeogba...

As a slight aside, how did you choose i3 over the other tiling window managers?

I chose xmonad at one time, but it was more or less by chance --- someone else used it that I knew, and so I tried it. But I haven't actually compared any.

I've read the name a few times and people seemed to be happy with it, so I gave it a try. I liked it immediately, not least because of the simple but powerful customization. To be honest, I haven't tried any other TWMs yet, but I will soon.

Depending on your background you may be pleased to see StumpWM (https://stumpwm.github.io/).

It's a tiling window manager, as minimal as ratpoison in interface but fully configurable and hackable on runtime, to the point of rebuilding parts of the system as it's running. It's the best WM experience I had since the old Enlightenment and I'm now using it full time. I even wrote some posts about it: https://klibert.pl/#stumpwm-better-modeline https://klibert.pl/#stumpwm

Ah, forgot to mention: it's in Common Lisp, so YMMV by a lot :)

I was a one-time Xmonad user, but switched to i3 recently. The enormous complexity of configuring Xmonad is what got me to switch, honestly. Perhaps if I A) needed enormous configurability or B) knew Haskell well I would have stuck around, but i3's config is much simpler to manage. i3 is also slightly prettier, but that's orthagonal :)

I used to use ratpoison - I very much like its mode of having a tree of key bindings hung off a single root, so that there's nothing I can't send to my applications. The fact that it largely works like screen/tmux is also quite nice.

More recently I had occasion to get xmonad working sufficiently like ratpoison to be usable. I expect my setup will grow in interesting ways in the long term, but it's still fairly minimal.

It can be used with the mouse though, through `:set mouse=a`. I sometimes use it for quick jumping, because yeah, `45G6w` will also get me where I want to be but if the cursor happens to be near where I want to end up, clicking is just easier.

I've wanting to move keyboard keys onto the mouse for decades. The closest I've got is with a Razer Naga Epic - the gaming mouse with the 12 thumb buttons:

  F5    Up    F2
  Left  Down  Right
  Tab   Del   Backspace
  Enter Space ESC

This speeds me up greatly. Especially in mixed GUI/keyboard input situations.

That's beautiful.

I might just get one to try out something similar. I'm thinking it might also be useful to have a different mode on the mouse that have the buttons map to keys on the numpad for calculations.

I've tried switching to VIM (from few years of using Sublime) few times already, but failed every single time: bare VIM is too dysfunctional to my taste and ways of working with text editor (missing tabs, file/folder treee view, easy switching documents, easy visual copy/paste and so on, missing code expanding/completion...).

Last time I tried spf-vim[0] but while it looked 'cool' (it has colors, it does code completion, it somwhere have the folder/file tree view and maybe eve tabs/panels...) yet it is overly complicated, quite badly documented (there is no intro like tutorial on getting you up to speed with what you may want from a text editor, just some strange sounding plugin list with few shortcuts here and there) and overloaded with plugins I am not interested in (PHP related ones) not to mention having few strange issues requiring googling and writing additional configuration just to make VIM behave...

So, while I'd love to use VIM for its speed, the fact its easily portable with the configuration and is available on almost every OS (BSD, Mac, Windows, Linux, you name it) I still write 99% of my code in Sublime, and only use VIM on servers to change this and that. Perhaps another time ;)

[0] http://vim.spf13.com/

Some thoughts:

What you call tabs are what vim calls buffers. (EDIT vim has something called tabs as well but they do something else.)

Completion press e.g. control-x (although I actually use a plugin here so I don't know how good vim's built in is).

Visual selection add set mouse=a to the .vimrc

Or using the "v" command

What he calls tabs are actually tabs: :tabe create tab :tabn next tab, :tabp previous tab, :tabm move tab.

I have tabn/tabp bound to <leader>l and <leader>h for easy nav and <leader>t for create.

Tabs in vim are actually just views of buffers. Ie: a workspace more than an editing window.

Buffers are the proper solution to the mentioned comment.

One thing I'd stress: Start with Vim for side tasks, not to replace Sublime. Once you have the basics down, you can then layer on the IDE features (addons like Ag, NerdTree, CtrlP) that make Vim comparable to what you are used to in Sublime.

I'm happy to act as a coach for you (and anyone else), if it's helpful. If you have a good plan of attack, you can get Sublime-like functionality pretty quickly.

+10 to the suggestion to layer IDE features progressively.

My setup is after trial and error: vim + (nerd tree, command-T, tagbar, Gundo) inside a tmux session. On another tmux window, I use 'find ... exec...' to search. So far excellent for me, I feel Zen like coding with this setup with no IDE noise :-).

Thanks for the coaching offer, its really nice of you! However, you could consider writing a set of ramping up tutorials on using vim/spf13 and publish them somwhere, so that more than one person at a time could use your hard work.

> there is no intro like tutorial on getting you up to speed with what you may want from a text editor, just some strange sounding plugin list with few shortcuts here and there

You should try `vimtutor` (it usually ships with vim). For the first 1-2 weeks of using vim, you will be less productive than with your usual editor but you have to force yourself to use it. Eventually, you will not want to go back.

In my personal experience (fwiw), people who try vim and don't get it either 1) just don't want/need what vim offers, or 2) don't approach it with the "vim is an editing language" approach.

If you're in the #1 camp, chalk it up to experience and move on.

Otherwise, at some point consider giving it another try, but Google up some articles specifically about the language aspect of vim. It's a lot easier to get up to speed and make better use of vim that way.

I'm pretty sure the base install of vim has everything you're looking for, it just requires a little reading. One problem that vim does not have is a lack of documentation. My favorite uses of tabs is scripting a work space based on context. You can start vim with several tabs already open: vim -p file0 file1 file2

I use vim on a daily basis and think it's a great editor, but it's definitely overhyped. Plugins in particularly are pretty disappointing if you're coming from an editor like sublime. Off the top of my head, syntax checking, fuzzy searching and multicursor options are all perfectly usable but very limited compared to sublime's offerings.

There is another element in using Vim that's not mentioned -- it's a super fun journey, full of surprising discoveries, handsome rewards for a little effort, and generally the happy experience in continuous getting nice things from a seemingly inexhaustible source.

As an example, having used Vim for ten years, just within the last few weeks I started to seriously learn and use Ultisnips, SkyBison, Vim-swoop, etc. It has been pure fun and rewarding.

To be clear, I don't use that many plugins. Often time I discover something already built into Vim proper which can replace a plugin (after some light scripting/configurations), then I usually uninstall that plugin. This has happened more frequently in recent years, possibly because of my improved Vim-fu (still a mediocre user I am sure). So both productivity and portability get improved while I am having fun learning new things.

Does anyone know if Vim has the power of multi line editing / multiple cursors like w/ Sublime Text? The large majority of my productivity involved copying and pasting with multi line select, and jumping words and different boundaries on multiple lines at once. Anything that matches ST for Vim?

I think there does exist a way to enter a visual block mode, but i is kind of a pain. You might try looking around for some third party modules. Here is one I found by doing a github search: https://github.com/terryma/vim-multiple-cursors

There is a plugin for that: https://github.com/terryma/vim-multiple-cursors

But I find that I can usually accomplish the same thing with macro or a targeted search and replace.

An another alternative to the vim plugins, here's a vim-like text editor that concentrates on selections and multiple cursors: https://github.com/mawww/kakoune

Vim does have the ability to insert text on multiple lines.

in visual block mode (CTRL-V or CTRL-Q), select a column of lines you would like to edit. Then, you can enter insert mode or paste and it will do the same thing on all the lines selected.

so to edit 4 lines at once it would be (CTRL-Q)3jI and then type in whatever i want and when I exit back to normal mode the text will appear on all 4 lines.

I don't actually program all that much, but I find that for text editing, vim (or even vi) is hard to beat.

As a sysadmin, I appreciate the fact that some form of vi exists on any vaguely unix-like machine I log into. Even without a .vimrc, the basic commands for line editing and searching work and they match with tools like less (or does less match vi?) and using vi has become second nature over time because it's everywhere and it tends to be the default (I hate it when someone makes nano the default $EDITOR so that eg. sudoedit doesn't do the right thing)

I wish Windows servers shipped with vi, too. A decent text editor is the one thing I consistently find myself missing. Notepad most definitely does not count.

Eventually, I'm hoping for some keyboard/mouse hybrid like this to catch on:

https://www.kickstarter.com/projects/1666150716/keymousetm-t...

I didn't end up backing it though because I didn't want to dump $250 on a v1 product would likely have many issues to sort out. That and the ergonomics of the typing didn't look that great.

Personally, I think this one looks better: http://www.combimouse.com/

I agree with everything here except the idea that you shouldn't start with MacVIM. The main issue with new users getting into modal editors is the learning curve. If you can reduce the upfront difficulty by accepting OS-specific hotkeys and mouse events, why not?

Using VIM saves you time and a smart user will search out the ways the editor can help her, but there's no value in making the user go cold turkey.

The main problem I have with suggesting starting with MacVim is that using it doesn't translate well when you're SSH'd into another system running a different OS. I've been using Vim for a while (and now neovim) and recently tried out MacVim and it just didn't make any sense to me. The menus are totally non-intuitive if you're used to doing everything from the keyboard. Conversely, I wouldn't expect someone who started by using MacVim to be comfortable with the keyboard shortcuts either.

Opening up a virgin vim session on a new system kind of makes you realize how much you'll miss out on if you don't know about :set number, :set wrap, :set syntax <whatever>.

> The menus are totally non-intuitive if you're used to doing everything from the keyboard

You can disable the menus, and using MacVim doesn't require you to use the menus. I use Vim 100% with the keyboard, and I still use MacVim.

If anyone is looking for a good book on using vim effectively, this one is great:

https://pragprog.com/book/dnvim/practical-vim

Any tips on learning the internal configuration/control language? I've been using vim for quit some time now (I like it a lot), but never have been able to grok anything about it besides entering code :)

  No other text editor has as many developers working on
  plugins than VIM. Virtually anything that exists in
  another text editor which isn’t mouse driven has some 
  very popular, very supported, very documented plugin 
  you can use.

And the Vim equivalent of org mode is what again? I'm a Steve Litt fan, but Vim Outliner isn't even in the same league as org mode.

As a Vim user of many years I still believe it to be superior to emacs when it comes to editing text. That said, emacs is a vastly superior programming environment. And like many people I find org mode to be indispensible.

Happily, these things aren't either/or situations. I still use Vim for quick text editing tasks, but for other matters evil+org mode lets me have the best of both worlds.

Edit: typos

> And the Vim equivalent of org mode is what again?

VimWiki: https://github.com/vimwiki/vimwiki

Not 100% of the same functionality, but close enough for me as to not matter. For the missing features, I have the rest of the OS.

One year? That is like "Takeaways from riding a Superbike in first gear, for one minute - Verdict. Super bikes are way overhyped!"

So let's assume that, by using vim as the primary editor as a coder, the author used it roughly 8 hours a day for 5 days a week. That's 1,920 hours.

I daresay it's impossible for someone to not use a tool, however complicated, for nearly 2000 hours and not become quite familiar with its operation.

This is also 1/5th of the (disputed) "magic number" of 10,000 hours to master a skill.

It's very possible to use a tool for a year or 10 and not be quite familiar with it's operation. You have to actively make the effort to learn new things to learn new things.

Well, I did manage to get through the first year or two (not 40hrs per week but close) with blissful ignorance of what vim was capable of. Only then did I start picking up new commands beyond the basic insert, append, delete stuff. And even much later did I really grasp vim's concept of text-objects. Of course, this was absolutely the wrong way to go. Would I have spent more time upfront learning, my productivity wouldn't have sucked as much. But then again, typing usually is not the bottleneck.

What I'm trying to say is: Yes, you can very much get through a year or more of using vim without leveraging it's power. (And you probably will, given how much there is to learn.)

SublimeText has a vim mode called "vintage" that allows vim commands to work.

Yeah, and its not as good. Try VIM's block selection in sublime, it doesn't exist. Also, the whole point is getting your hands off the mouse, and sublime still needs it.

now you should try Spacemacs

+1 for Spacemacs. Former vim user, now using smacemacs for past few months.

I found a number of things just work way better in emacs than in vim. For example, web-mode was a revelation for me. I could never get vim to get syntax right in mixed HTML-JS files.

Ability to edit very large files with ease was another one in favour of emacs. Vim would freeze up for a seconds or two while saving even half a megabyte file.

helm and family blew my mind away.

Another win spacemacs is it does not hide default emacs functionality. All default emacs keyboard shortcuts would always work, so learning vanilla emacs is still helpful.

Once I got to know spacemacs shortcut layout, it was surprisingly intutive.

(YMMV)

I know this is going to sound silly, but I'd go so far as to say that Spacemacs is one of the best editors ever made.

But it's not nearly as portable as vanilla vim. Even vim with several plugins, including vimproc and Unite, I've found is a lot more portable than Spacemacs. Spacemacs is a lot slower as well.

For me, unfortunately portability is really important, which is why so far nothing has been able to sway me away from my trusty tmux + vim + Unite combination.

I've tried Emacs + Evil and Spacemacs, but eventually just came back to Vim.

I've picked it up three times now, and every time the plugin combination I chose (nothing outside if what's included in Spacemacs, and using a fully supported install) would lock up the editor while using full CPU 3-4 times a day.

The minor upgrade in functionality wasn't worth the instability.

Reply on news.ycombinator.com