Hacker News new | past | comments | ask | show | jobs | submit login
Coming Home to Vim (stevelosh.com)
204 points by PopaL on July 9, 2012 | hide | past | web | favorite | 118 comments

I took the dive into Vim about a year ago. I was at the stage where I'd become proficient with some command-line tools in Linux, but I didn't yet have an editor I could use fluently from the command line. I tried out both Vim and Emacs, and found Vim to be slightly easier to grok, plus my pinkie got kind of sore from holding down the Ctrl key in Emacs.

I changed my default editor at work to be Vim, and started doing all my dev work at home through Vim. I started off just using the arrow keys to move and just using insert mode to edit text the normal way. Each day I tried to add one new command to my repertoire; I learned about how to structure vim commands (c-change i-in w-word, etc.) and move using hjkl and the higher order movement commands like w and b. Now I can maneuver my way around vim quite confidently, and although when I started off I was much slower in Vim than other editors, I now find that Vim is just as fast or faster for most tasks, particularly where I can make use of Macros.

At the moment I still have to get my head around markers and a few other concepts, but I've definitely become proficient enough for it to be worth the effort and time invested so far.

My tips for anyone learning to use vim for everyday development would be some common tab commands: :tabnew <path> to open a file in a new tab, :tab sball to show all currently open buffers in separate tabs, gt and gT to jump to the next/previous tabs.

Yea, tabs are a very useful feature in vim that many people don't seem to use. I know people that use the panes. This isn't really useful for me though. I use tmux as my window manager for my terminal, so I have not use for panes in vim. I just have a bunch of vim processes running and use tmux for the window management. The great thing about this is my development environment completely mirrors my production environment. I have found that one of the best productivity gains you can get is having one mental model for everything. Unfortunately I'm still coding in PHP (don't think PHP fits into this idea).

Opening two files in a split-pane in Vim is different from opening two Vim's and panning them with a window manager.

This is because all the state is shared within a single Vim: buffers, copy-paste information, and so on.

> Yea, tabs are a very useful feature in vim that many people don't seem to use. I know people that use the panes.

I don't use tabs because I don't find them useful at all. If I need to see 2 files at once, split panes it is; if I am switching between files, I have them open as buffers(NERDTree and BufExplorer makes it pleasant).

> I use tmux as my window manager for my terminal, so I have not use for panes in vim.

I use tmux as well. The only times I use tmux panes is when I need to run shell in the same window.

> I just have a bunch of vim processes running and use tmux for the window management.

And I have one vim process running for one project root. Coding rails? Open vim in top folder and open all files from there using rails.vim navigation commands(:Rcontroller, :Rmodel...) or NERDTree and switch between them using BufExplorer.

I use tmux too, but I prefer the way vim handles panes. When I'm in mental-vim mode, it's easier for me to not have to jump out to thinking in tmux terms when editing several files.

attach/dtach/dvtm perhaps then......

Wow, the bit about seeing vim commands as sentences composed of nouns, verbs and adjectives blew my mind. I thought about learning vim, but I didn't know about this, so vim commands seemed like some arcane language that I would have to gradually get proficient at over months.. this might make the transition a lot easier.

Learning to see the commands as a language is helpful; but, it doesn't really reach its full power until you start to see files in terms of the various groupings that Vim affords you (either the out of box things or custom text objects). If you stick with Vim, you'll start seeing things like whether or not you want a word or a WORD, or around (a) or inside (i) an object. Moreover, start to pick up on when you're hitting the same key multiple times or repeating a command. There's almost always a faster way to do something than repeating a command N times.

I'll be totally honest, it takes time and a real commitment to using Vim as your only editor. But, over time, you'll start to think in this text objects and, combined with the "commands as a language" concept--that's when Vim will really start to show it's power.

I agree on everything.

You didn't mention the fact that all of this becomes addicting rather quickly: going to a more "normal" editor or textarea can be extremelly frustrating some times.

Incredibly frustrating. I have trouble when I have to use other PCs or devices. I can no longer use the "arrow keys" and get momentarily confused when hjkl are showing up in the textarea instead of giving me movement. And I can't tell you how many times I hit escape in LibreOffice/Calc/etc.

This is one reason why I don't use online editors like Google Docs. They don't have great vim keybindings. Even extensions like Vrome and Vimperator fall just a little short. And for apps that do have a subset of the bindings--they are almost worse than having no bindings at all; evince has hjkl, but no gg/G, etc. It drives me mad.

I've configured AwesomeWM to be vim-like, but how I wish there was window toolkit-level support for vim bindings! In fact, I wish I could run everything from vim.

I've IM'd :wq to my wife more times than I can count.

:x is virtually the same as :wq, except vim won't write the file if you haven't changed it.

Hopefully more than you've typed ":q!" :-)

If you make a habit of typing :q!, you're going to have a bad time.

That's great! Such a simple anecdote, but it made me smile.

try ZQ :)

QuickCursor on OSX does basically that in just about everything... (like this post) It's not free (bummer) but it lets you take just about any text input area and by some clipboard trickery fire it up in your favorite editor (macvim being one of the defaults, but not limited to that) then writing back to that field when you exit/save.

So you can quite literally edit in your editor of choice, 100% in the environment you want.... pretty much what you just asked for right?

(Basically it's just cutting/pasting and opening applications in an automated way rather than have you do it - but bind it to a friendly key and you're good to go.)

Vimperator/Pentadactyl are not really editors, but they are awesome if nothing because of Ctrl+I : it opens the current textarea in GVim, and then you just need to save & exit and the contents are automatically loaded back.

This is why I don't use vim.

As nice as it may be, there are just too many other text editing tasks I have to do outside an editor I can control and none of them grok modal editing.

True... I see myself as just an average vim user but already - can't remember last time I had to manually bash keyboard repeatedly. Recently - got quite blown away with simple macro that picked up some keywords, automatically downloaded list of WSDL`s through curl, tidied up a bit and saved in according files. Watching it spin feels like magic.

Yep, that's the zen moment right there with Vim. Once you understand this, you will be able to 'speak' to your editor and bend it at your will.

E.g. 't' is a motion command which takes you 'till' a particular character. The same command even works with 'Visual Block Selection'. Most of the other editors have a different work flow for 'Block selection' and they are not friendly at all.

And if you are starting out, I would HIGHLY recommend the book 'Practical Vim' http://pragprog.com/book/dnvim/practical-vim . The book teaches the 'The Vim Way' and to be a good Vim user, you have to understand the 'The Vim Way', there is no way around it. Good luck!

I'm a hardcore nerd and I spend many hours with a text editor during the day. Yet I find vim beyond my nerd level. I just can't be bothered with fiddling with config files and installing little bundles and packages for every functionality.

On top of that the whole "language of editing" and combining noun,verb,adjective commands, etc... doesn't really appeal to me because I'm too visual when I'm editing code. I can't stop to think about the right semantics about what I want to do, I just do it visually.

>>I can't stop to think about the right semantics about what I want to do

After the initial learning process, you don't think about the right semantics of what you want to do. Learning vim's normal mode really is very analogous to learning to touch type. In most text editors, when you want to delete a word, you don't really think about hitting backspace a whole bunch of times. Of course, you did think about hitting backspace when you first started. With vim, you don't really think about hitting dw (or cw), you just do it. You did your thinking a while ago, and now it's just how your fingers move.

Of course, there are plenty of valid reasons why vim might not be for you, so please don't take my comment as a "No, you really should learn vim" piece of evangelism.

Yeah, I initially learned vim because I didn't really have a choice (it was expected for the class that we would use vim), and I remember it being very painful in the beginning.

However, just like any other tool you use on a regular basis, those commands become muscle memory very quickly and you don't even think about it.

Now I use vim for work, mostly editing c code. I have a very barebones vimrc and have never installed a little bundle or package. I use it mainly because of its simplicity and terminal integration.

I can't say I'm a very visual person though. I get distracted with too many bells and whistles and often times even just switching windows causes me to get distracted by the interwebz (...i'm a bit add), so I like the simplicity of a blank screen.

Point being, vim isn't for everyone, but using vim doesn't have to be this big giant complicated endeavor that everyone seems to make it out to be.

(Small confession: I also really feel kind of bada$$ when I'm sitting behind a black terminal with green text...)

> I just can't be bothered with fiddling with config files and installing little bundles and packages for every functionality.

This is exactly the reason I decided to make what is probably a lifetime choice to use vim going forward. The vim defaults are ideal for general purpose editing. It's true an IDE or the right modern editor might have things set up with nice defaults for x or y language, but pick five editing tasks at random and you'd be hard-pressed to find a better editor out of the box than vim.

Being able to competently edit any file out of the box on any system affords me a great mental flexibility. It lowers the barrier for learning new languages, or even switching platforms (I like OS X now, but I don't want to be locked in forever when Apple dials up the consumerification to 12). The main disadvantage is that vim really can't compete with IDEs for boilerplate-heavy verbose languages like Java, but I'm not particularly interested in learning languages like that.

Now it's true that I will tweak my config and go and seek out some plugins to enhance my core workflows slowly over time, but that's just the icing on the cake. Mainly I focus on mastering core vim and I do with reasonable confidence that the investment I'm making now will pay dividends 10, 20 and 30 years from now.

> On top of that the whole "language of editing" and combining noun,verb,adjective commands, etc... doesn't really appeal to me because I'm too visual when I'm editing code. I can't stop to think about the right semantics about what I want to do, I just do it visually.

It's one thing if you like a polished GUI and you just can't feel good about vim's lack of polished OS integration and GUI features, but with regards to thinking about semantics, these commands all become muscle memory and you end up doing most of them on a subconscious level that is hard to describe unless you've experienced it. I wouldn't write it off based on the assumption that it wouldn't work for a "visual" person.

I think that a lot of these "Intro to Vim"-type posts do Vim beginners a disservice by recommending a whole bunch of plugins right off the bad. Instead of just learning the Vim basics now the reader needs to also learn how to use all those recommended plugins.

You can get awfully far with just the built-in application and maybe something like CommandT to help navigate projects, especially if using a GUI editor like MacVim to make tab navigation easiest.

As much as I respect Steve Losh, I must admit you are right: this very post put me in a plugin/remapping frenzy when I switched from TextMate. After a few weeks, my Vim was a mess and… it wasn't Vim anymore. Eventually I decided to go back to square one and learn Vim properly but I certainly lost a couple of months chasing fantasies.

I just can't be bothered with fiddling with config files and installing little bundles and packages for every functionality.

While this is obviously a matter of taste, I do like vim's minimalism in that you start off with a simple core with sensible defaults and just add any features you want (I use tcomment, command-t, and fuzzyfinder for switching buffers - that's pretty much it, my .vimrc is less than one page). I found vim much easier to get into than emacs (which I'm currently using for most heavyweight coding sessions) where the defaults are (imho) not as sensible and you have to dig through tons of stuff that comes bundled with it, instead of understanding everything from the beginning and building from there. Of course, it's great to be able to extend emacs with elisp to do any stuff you feel is missing, and I've generally felt it easier to integrate the whole dev experience (minus the browser) into it than with vim - but such usage was of course never in harmony with vim's philosophy in the first place.

On top of that the whole "language of editing" and combining noun,verb,adjective commands, etc... doesn't really appeal to me because I'm too visual when I'm editing code. I can't stop to think about the right semantics about what I want to do, I just do it visually.

Like the rest of vim, these things just become muscle memory - you will completely stop thinking about what command to use after a bit. The reward is getting all those micro-level text editing tasks done with fewer keystrokes, minimizing the time you spend typing and therefore the disconnect with the thought that preceded the typing. I think this dynamic is really great when you get into the zone and want to let stuff flow out with as little neuromuscular obstruction as possible :P

I think the vi/vim editing model is a genuinely important contribution to text editing technique, much more so than vim the program, but of course you can use vim keybindings in lots of other editors and IDEs and still get the core benefits, assuming the most important vim-powers have been implemented.

You don't have to make Vim your primary editor although if there's any chance of having to muck around on other people's servers some basic vi skills would be welcome.

By the sound of it Vim might just not be your thing. I switched to Emacs 15 years ago after many years of advanced vi & Vim usage and never looked back since I never really liked modal editing.

I'm skeptical that Ack is "far, far better than grep." Different? Ok. Better? Maybe, based on what you're doing. Far, far better? Probably not. Omitting correct results because a file extension isn't white-listed sounds like a pain.


FWIW in ack 2.0 (currently in alpha) this behaviour will be different: it will search all text files by default.

I like Ack more than grep, but I agree: whitelisting file types isn't fun. I wrote a mostly drop-in replacement for Ack in C (https://github.com/ggreer/the_silver_searcher) and the biggest difference in behavior is the file filtering. Ag searches all text files by default, with the exception of those in .gitignore and .hgignore. You can also add patterns to .agignore files if you want finer-grained control. Oh, and Ag is much faster than Ack.

Ack isn't the only thing better than grep. If you're searching in Git repos, you might want to check out git-grep. Another useful tool is Exuberant Ctags: http://ctags.sourceforge.net/

Where did you see ack as "far, far better than grep". My Ctrl+F finds nada.

The reason I took "betterthangrep.com" as a domain name, besides it being catchy, is that I want people to think beyond stock grep as a tool, to know that they have options. The page http://betterthangrep.com/more-tools/ is just a listing of other tools that may be better than grep, depending on the use case.

  If you’re a programmer and you don’t know about Ack, you need to start using it now. It’s far, far better than grep.

Original discussion from a couple of years ago can be found here http://news.ycombinator.com/item?id=1710702.

this keeps coming home once a year :P

Sigh, I keep seeing this article, and ones like it, and keep thinking maybe I should go back to vim. I'm happy with Sublime, though I like the idea of vim.

I've used vim a great deal in the past and it really is exceptional for editing a given file. The thing that really tipped me to ST2, though, was its management of multiple files in a project. The sidebar and Goto Anything are indispensable. I know vim has command-t, but I just haven't been able to browse a family of related folders as easily. How do others do it?

Also, I just can't get used to the line-by-line scrolling of vim and emacs vs. the pixel scrolling of Sublime, or TextMate, or even TextEdit.

CtrlP(1) is a recent alternative to Command-T: you can use it to quickly jump to another buffer, a nearby file, a recently used file… all this with a very consistent interface and a neat feature: you can configure it to look up and up for a .git or .svn or other VCS artefacts and start from there. This makes the whole "open a file in the current project" business an almost seamless experience.

Also what's the point of displaying a third of the height of a line?

(1) https://github.com/kien/ctrlp.vim/

Nice tip on the Ctrl-P link; but I'm curious, is there anywhere that sums up why Ctrl-P would be preferred over Command-T? Aside from being written in pure Vimscript, I haven't seen anything touting any specific advantages or disadvantages in a head-to-head.

Just for you:

                                             | Command-T | CtrlP
     files                                   | OK        | OK                 
     buffers                                 | OK        | OK                 
     tags                                    | OK        | OK                 
     jumps                                   | OK        |                    
     lines (vimgrep)                         |           | OK                 
     MRU files                               |           | OK                 
     mixed                                   |           | OK (new, untested)
     open in tab                             | OK        | OK                 
     open in vsplit                          | OK        | OK                 
     open in hsplit                          | OK        | OK                 
     open multiple items                     |           | OK                 
     matches with filenames                  | OK        | OK                 
     matches with filepaths                  | OK        | OK                 
     execute command on opened file          |           | OK                 
     create new file and parent directories  |           | OK                 
     project root finder based on VCS        |           | OK                 
I'd say that both are quite close in terms of features. CtrlP's strong points for me are:

* no dependencies

* project root finder

* overall UX

The "lines" feature (fuzzy incremental search across buffers ) is also very nice:

John Coltrane wins the points--way more than I expected (a link to a quick summary would have done fine)--thanks for the detailed look!

You are welcome.

I should add that CtrlP is getting better and better over time. Some new (to me, at least) features:

* Bookmarking

* Quickfix mode

* Undo mode

* Change mode

* RTS mode

`:CtrlPBufferTag` is a killer.

This plugin seriously rocks.

Command-T is known to be quite the pain in setting up.

It's a pain if you don't have a version of Vim compiled with Ruby support; I was just wondering if there was anything beyond the language choice that made is superior (or inferior).

Is it just me or is Ctrl-P really slow for me?

The moment I start Ctrl-P in Vim, it takes about 20 seconds just to index and then when I began to type, the letters I type appear really slow and it takes ages for it to actually type out the whole word. Same when I delete a word by hitting backspace.

Command-T is, I would say, 40% faster for me but there is the same lag when typing/backspacing.

There's a good chance you need to invest in your wildignore or ctrlp ignore settings. I run: https://gist.github.com/67de417c5c38f0ff8093 in the end of my ~/.vimrc to ignore the SCM directory, the tmp directory and my data-dirs (you can adapt as required) - this makes ctrlp really responsive for me. YMMV.

CtrlP (and other similar plugin)s doesn't have knowledge of your filesystem before you point them to a directory and it has scanned its content. Obviously, this operation can take some time on large/deep directories which will vary between implementations.

Luckily CtrlP gives you a bunch of ways to accelerate the whole thing. See `:h ctrlp`.

Maybe I'm weird, but I want the scrolling animation to go by pixel, but then I always want my editor window aligned to the nearest line when I'm not scrolling. It's always a little annoying to have a half-obscured line at the bottom, or, even worse, top of my screen. This would just be compounded by the fact that I tend to split my editing window into fairly little blocks for running stuff like shells, so I would have a lot of lines obscured like that.

You are not weird but you want mutually exclusive things.

Not in the least: I want smooth scrolling that snaps to the nearest line. I don't see how this is mutually exclusive or even unreasonable (at least for a text editor as opposed to something more free-form like a web browser).

Well, you can't have smooth scrolling without hiding parts of the top and bottom lines.

Smooth scrolling means that, at any point in time, the top of the topmost line of the viewport and the bottom of the lowest line of the viewport may be hidden.

Line-by-line scrolling means that all the lines have some kind preserved visibility.

He wants the animation to be smooth, but once you finish scrolling, it should be align itself to the nearest line.

Thanks for clarifying the question.

I haven't really used it, but there's NERDTree for a Vim sidebar.

I'm not too familiar with Sublime, but I know that there are a few clones of Goto Anything for vim. Personally, I like CtrlP ( https://github.com/kien/ctrlp.vim/ ) since it is both very usable and written entirely in vimscript (so I can use it on servers without installing anything extra). I think it replicates most of the features of Goto Anything.

I've come and gone with various vim config changes, but this is the one non-standard one I've stuck with:

au! BufRead,BufNewFile * lcd %:p:h

This makes it so that when you open a buffer, you cd to the current directory (only for that window), so you can quickly open files in that directory.

[% is the current file relative to pwd, :p converts to a full path, :h takes off a path component, lcd does a cd but only for the current window]

Another tip is that when your internet connection sucks enough for SSH lag (tethered, free wifi, whatever), you can edit a file locally and have vim do the SCP back when you write:

:e scp://you@somewhere/path


A nice alternative is to do:

  " Allow easy navigation to relative files
  cmap %/ %:p:h/
This basically replaces everything before the slash with the directory of the file you're editing. That way, you don't have to necessarily cd, but can easily open files near the one you're currently editing. You can just do ":e %/foo.txt" to open foo.txt in the same directory.

    set autochdir
does what you describe.

Thanks for the laggy SSH tip.

Slightly tangential, but the author mentions remapping Caps_Lock, as I do (I've mapped it to Escape, as Esc used to be where Tab is on modern keyboards anyway). The moment I first did this, I realized how amazing vim really is, and why people always say that you can navigate the entire file without moving your hands from the home row.

However, both methods I know for doing this only work inside an X server - does anybody know a good way to remap keys without X?

I used to have it mapped to escape but once I started using tmux I mapped caps lock to control and never looked back. Much more versatile than escape and ctrl+[ will do the same thing (although it's proving hard to break the habit of pressing escape instead).

Best of both worlds: KeyRemap4MacBook has a setting where Control acts as Control when held down, but acts as Escape if typed alone. This in combination with setting Caps Lock as Control in OSX is all sorts of awesome.

Unmap your escape key, that will force the habit. I did this when I moved my control and meta keys to the left thumb of my kinesis keyboard, and it helped train me not to hit the old keys.

I've tried this in the past but it made both escape and ctrl+[ no longer function. What worked for you?

Under OSX I used a tool called KeyRemap4MacBook which adds an item to the control panel that lets you reconfigure keys. I just tested it, you can can disable the escape key, but Ctrl-[ still works like you'd expect.

imap jk <Esc>

Hitting jk in insert mode for escape is wonderful.

I had to create a modified keyboard layout, starting from one in /usr/share/kbd/keymaps.

Use the showkey command to find out what keycode the caps lock key generates (mine is 58), then add a line in your layout file to the effect of

keycode 58 = Escape Escape Escape Escape Escape

Finally, load your new layout using loadkeys /usr/share/kbd/keymaps/i386/{yourlayoutname}/{yourlayoutname}.map.gz

I finally tried this out today: (while TERM=linux) keys.kmap: keymaps 0-127 keycode 1 = CtrlL_Lock keycode 58 = Control

sudo loadkeys keys.kmap

This works, but I haven't set this up to load on startup yet.

I think you have to play with loadkeys and a custom mapping.

In linux you want to use loadkeys(1).

I'm a bit torn. I love the controls in vim, the way you navigate and manipulate text is a brilliant system. It makes it more efficient and more "fun".

However, I really don't like the configuration system for vim. Reading the article above, I lost interest when he started talking about his .vimrc file and the plugins he used. It seems arcane to have to have these cryptic settings, whose functions aren't immediately obvious, and write them to a file. I understand that part of the VIM philosophy is that it's almost like a language, or that it's like programming your text, but configuration is just something that you (ideally) set once, and then forget about. Even if I do learn what "nnoremap <leader>ft Vatzf", if I need to set up my environment again, I'll likely forget what it is and why I needed it in the first place. And even if I configure VIM to have the things I want (for example, NERDtree for project navigation), it'll never look or feel as intuitive as having a graphical interface.

So it seems when people talk about VIM, it seems that they're really talking about two things: the control scheme (keybindings) and the editor itself (the environment).

Being an android developer, I use eclipse. I use the "Vrapper" plugin, which gives me vim keybindings in the eclipse editor. I love it. It gives me the vim navigation that I know and love, but the environment and tools provided by Eclipse. I think this is how it should be - the environment of the editor is best handled separately, and although you can add a ton of plugins and configure the crap out of VIM to turn it into an IDE, it'll never really be a proper IDE.

This is why I'm still looking for an ideal lightweight text editor/IDE. My ideal for linux would be Geany, but with Vim keybindings. I discovered Vico yesterday, which looks interesting, but is OSX only at the moment. Might be what I'm looking for, but we'll see.

Try Sublime Text 2 for a lightweight editor with Vi keybindings. It's not Vim but it's quite powerful in its own right and is cross-platform.

With some experience and the right mindset, Vim's language becomes second nature and a mapping like yours is very easy to understand.

The thing is that too many people, me included at the beginning, follow the "learn -> customize" path in the wrong order: "customize -> learn"; often because of articles like this. This lead to a non-productive mix of plugin-addiction and mappings-dependance that's rather obviously counter-productive.

The ideal path would be to first learn how to use plain Vim then use this knowledge to customize it. This path leads to a short .vimrc and a lightweight .vim directory while the other leads to a miles-long arcane .vimrc and a bloated .vim directory.

You can do a lot more in vim without plugins than with most text editors. In fact, I'd say that was one of it's major advantages over the competition. Relying too much on plugins and configuration makes things hard when you're switching machines or using shared logins a lot.

I started off with Textmate, then Emacs, then Vim, then back to Textmate, then Vim (for real that time), then Emacs (for real, that time).

I am tempted by Sublime Text and Vim, but can't live without a few Emacs features these day. But sometimes I miss the fluidity of Vim.

That said, I found the most important influence on my productivity is fun. I am most productive when I enjoy what I am doing. And this is very directly influenced by the way I do the clickety-clack thing with my keyboard.

In fact, I sincerely think that Vim is the most efficient text editor out there. Nothing else comes close. The thing is, me personally, I am having more fun elsewhere, for reasons that have little to do with text editing performance.

Mind you, this is not critique against Vim. But I would like to discuss text editing productivity in terms of fun instead of keypress efficiency. Whenever anyone argues about the relative merits of EditorX against EditorY in terms of key presses I feel like he is missing the point.

What do you think about this idea/argument?

I really like Vim as a concept, but the implementation is somewhat laking and not so easy to extend.

At the moment I'm using Emacs with EVIL (Vim layer) and loving it. You should check it out :)

I did and I could not cope with it. My brain can either do Emacs or Vim, but not both. Whenever I used Evil, I would fall back entirely into Vim mode and more or less ignore all the Emacs goodies and miss my favorite Vim plugins. Mixing Emacs and Vim did not go well with me. However, maybe I should try it again now that I am comfortable with Emacs.

I think the point that (judging from the responses) I managed to miss is that I think that text editing productivity is bound by an entirely subjective measure that has next to nothing to do with the objective key-by-key efficiency of the editing commands the text editor provides.

It really does not matter why your text editor of choice is making you feel good, but as long as it does, you will be more productive in it than in any other one.

Have you tried Evil? I've heard good things about it.

I'm actually a die-hard Emacs user. I like the idea of Vim's modes and more efficient keyboard commands, but I can't leave all my Emacs features and plugins and customizability (I've even written some simple major modes). However, I'm really considering learning how to use something like Evil one of these days and (hopefully) have the best of both worlds.

Evil is absolutely awesome. It is hands down the best Vim emulation I have ever seen in any text editor and even manages to not clash with stock Emacs much.

That said, my mind is incapable of handling both Emacs and Vim at the same time. When I used Evil, I would forego all the greatness Emacs provides in favor of Vim.

Still, maybe Evil makes more sense coming from Emacs than coming from Vim (aka maybe I should try it again).

I don't know--as I said, I haven't tried it. In fact, I've never even used Vim beyond :wq. But if it's even half as good as you're describing, I might just try it--all the power of Emacs combined with Vim-style commands sounds like a very good deal.

It reminds me of the joke "Emacs is a great OS, but it needs a good text editor".

> In fact, I sincerely think that Vim is the most efficient text editor out there. Nothing else comes close. The thing is, me personally, I am having more fun elsewhere, for reasons that have little to do with text editing performance.

> What do you think about this idea/argument?

Unless you can tell what is the fun part, and what are the reasons you are having more fun elsewhere, I don't know what do you want to discuss.

Well, start the discussion, then.

What do you think is fun in Emacs and not in other editors? What was unfunny in Vim?

This blog post recently helped persuade me to switch to Vim (from TextMate). The two things that most helped me learn Vim, beyond the very basics, were Drew Neil's excellent Vimcasts [0] and Steve's own Learn Vimscript the Hard Way [1] (a work in progress). Learn the basic movement commands and text objects, then spend ten minutes every day watching a Vimcast or doing a chapter of LVHW and you'll quickly be past the steep part of the learning curve.

0. http://vimcasts.org/episodes/archive

1. http://learnvimscriptthehardway.stevelosh.com/

In addition to the vimcasts, I also found Derek Wyatt's video series very helpful (as well as entertaining).


Excellent. I've been a long time user of Vim and never saw this until the blog post.

It goes without saying..... check out vimgolf if you haven't - whether novice or expert, competing or just reading, you learn new stuff.

Don't become too plugin dependent too early, but a quick browse through some other's dotfile repositories (yadr is worth looking at, especially if you are on a mac - not necessarily to use, but definitely to see what's possible). Things like EasyMotion really make you think. As do things like persistent undo files. (gundo and other stuff)

At some point you should be buildilng up your own set of dotfiles from scratch.... not just relying on someone elses (some day some bug hits you and you have no idea where to start otherwise)

After using Vim for couple of years, I recently made a switch to Emacs. Sometimes I regret it. I definitely miss Vim modal design and keybindings. Compare Vim's J (join lines) with Emacs go to the lower line and press ^ to join it with the upper one.

To copy a line in Vim you just have to press 'yy' but there is no copy line command in Emacs out of the box. What you can do is C-k, C-y, i.e cut a line into clipboard and paste it back to have copy line effect.

But trying and learning different tools is obviously useful. Emacs introduced me to ido-mode and org-mode. Now that I know of the possibilities, I can search for and use similar plugins in Vim.

"No copy line command in Emacs" Did you try "Alt/Meta-w" ?

You have to select the text first for that to work. The quickest way I can think of is Ctrl+a, Ctrl+k, Ctrl+y.

Or you just roll some elisp to do the job.

> "If switching to a different editor can increase my efficiency by even 10% it would save a good chunk of my time and let me get back to making cool things."

> "I don’t buy the “you’re thinking 90% of the time and only typing 10% of the time, so your editor doesn’t really matter” argument. Even if the premise is true, the conclusion is wrong."

Interestingly to me, people never (or rarely) attempt to improve their thought process, which would probably result in a much higher increase in productivity than editor proficiency.

> nnoremap ; : > I don’t remap : back to ; because it seems to break a bunch of plugins.

That sounds like another good trick. But then how do you jump to your next f,F,t? I find myself frequently typeing "f=" to find "=" and then hitting ";" to jump through all the "=" in that line and reach the one I want.

When people overwrite things that are basic like that they usually don't have an alternative. They overwrite them, because it doesn't fit their common usage pattern.

But, for example, I use ',' as my <Leader>. So that I can still use ',', I also map ',,' back to ',' functionality:

  let mapleader = ","
  let maplocalleader = ","
  nnoremap <leader>, :normal ,<CR>:<CR>

repmo.vim[0] lets you repeat movements with semicolon as well. I only use two vim plugins, and this is one of them.

[0]: http://vim.sourceforge.net/scripts/script.php?script_id=2174

" If switching to a different editor can increase my efficiency by even 10% it would save a good chunk of my time and let me get back to making cool things."

Instead of taking us on a long biographical journey of how you found the One True Editor (this week), why not familiarize yourself with Amdahl's Law?

Where can I get clones of myself willing to concurrently enter text so that Amdahl's law about parallelization performance somehow becomes even the slightest bit relevant to text editing?

Okay, fine - law of diminishing returns, the point still stands (although I deserved that for being a smart-ass).

I'll bite. What do text editing and thinking (both serial tasks) have to do with Amdahl's law?

Amdahl's Law isn't necessarily applied to parallelism.

Even though I really enjoy pecking away in BBEdit, I find Vim to be so wickedly fast. Manipulating text in Vim is nicely handled without having to stretch the fingers very far. By the time I go to the trackpad in another IDE, I could have accomplished so much more within Vim.

Is there anyone on HN not using textmate and sublime no Mac OSX?

Yes, there are plenty of people using Vim or Emacs as they're primary editor. You don't always hear from them though, because they've already lived through several rounds of editor wars.

I'm really embarrassed that "their" ended up "they're". I'm not sure if I typed it out of muscle memory, or if I mistyped it and Lion auto-corrected to "they're".

This is why I never stoop to pedantry. I know the difference, I swear!

I made my editor choice over 20 years ago, before these things were even a glimmer in their creators eyes. The key sequences I use for editing are cast in stone into my muscle memory, and serve me in nearly every command-line tool I use, as well as every text entry widget in OSX. My editor is part of my hacker DNA.

I use Emacs on OSX, just like I do on every other operating system I have to use.

I'm more than happy using a combination of Vim (not MacVim) and tmux on OS X. I was spending more and more time in the terminal (running tests, committing changes, etc.) so it made sense to me to incorporate Vim into the window as well.

FYI my transition was Notepad++ > TextMate > Sublime Text 2 > Sublime Text 2 + vintage mode [1] > Vim.

[1] http://www.sublimetext.com/docs/2/vintage.html

I'm a quite happy MacVim user.

Great tip for using Perl/Python-compatible regex syntax:

  nnoremap / /\v
  vnoremap / /\v
This will save me a lot of time. Thanks, Steve!

One thing I can't understand - why people remap leader to comma? How they use fFtT without it?

[fFtT], still works even with comma mapped to leader.

Does anyone know what the author is using to display carriage returns at the end of each line?

in ~/.vimrc :

    set list
    set listchars=tab:▸\ ,eol:¬
it's in the getting started section.

Thanks! Don't know how I missed that

mid eighties till 1992 on Qedit, Emacs till 2002 then VIM to the present, no desire to switch for the next decade of coding :-)

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact