Hacker News new | past | comments | ask | show | jobs | submit login
Vim, you complete me (thoughtbot.com)
193 points by Croaky on July 12, 2012 | hide | past | web | favorite | 114 comments



Vim reminds me of an example from Bret Victor's excellent talk Inventing on Principle [1] (which you should watch from beginning to end if you've somehow been hiding under a rock and have missed it).

Bret mentions Larry Tesla (starting at about 38:10) who made it his personal mission to eliminate modes from software.

This is the problem I've always had with Vim and I suspect I'm not alone in this. I find the concepts of modes jarring, even antiquated. Everyone who has used vi(m) has copied and pasted text in while in command mode and done who knows what.

Emacs is better in this regard but I find Emacs's need to consecutive key presses (or a key press followed by a command) to be longwinded.

The advantage of either is they're easy to use over ssh+screen (or tmux) for resuming sessions.

That all being said, give me a functional IDE any day. IDEs understand the language syntax. Vim can do a reasonable job of this. Emacs (with elisp) seems to do a better job (or so it appears; I'm no expert) but IDEs (my personal favourite being IntelliJ) just make everything easier. Things as simple as left-clicking on a method and going to its definition.

For statically typed languages (eg Java/C#), IDEs (quite rightly) rule supreme. Static code analysis, auto-completion, etc are just so much better than text-based editors.

Dynamic languages are more of a mixed bag and its certainly the norm for, say, Python and Ruby programmers to use one of these.

Still, give me an IDE any day.

One objection seems to be that people don't like using the mouse. I tend to think the speed differences over not using the mouse are largely illusory.

Anyway, I can use vim but I've never felt comfortable in it and I don't think I ever will and modes are the primary reason.

EDIT: I realize there are plugins and workarounds for many of these things but that's kinda the point: I don't want to spend hours/days/weeks/years messing with my config to get it "just right".

Also, instead of archaic commands to, say, find matching opening/closing braces (which tend to involve an imperfect understanding of the language), IntelliJ just highlights matching braces/parentheses, where a variable is used and so on.

[1[: http://www.youtube.com/watch?v=PUv66718DII


The way that most Vim users use modes is like using "StickyKeys" on your Shift/Control/Option keys. You smack "i" or "a" to go into insert mode just for the duration that you need it, and then you smack Escape the moment that you stop typing, even if it's just pausing to think.

Also, if you use a GUI version of Vim, then it knows about "paste" and doesn't make the mistake of interpreting your paste buffer as keystrokes.


I think this is the key to vim. It's a revelation or a turning point in how you use it. You change to insert mode to insert text; you don't change to normal mode (to do text operations) as you're already in normal model.


Emacs is better in this regard but I find Emacs's need to consecutive key presses (or a key press followed by a command) to be longwinded.

These consecutive key presses ("chords") are just there to provide default bindings and are one of Emacs' weakest points since they're universally horrid. However, there's no single best way to use Emacs[1]: everyone should configure it how they want it to. After years of using my own key bindings I've streamlined them with the rest of my OS[2] and couldn't be happier.

[1] Opposite IMHO to Vi(m) where one should use the default key bindings.

[2] CTRL/CMD-o to open a file, C-s to save, C-f for incremental search, etc.


I used to use IntelliJ when I programmed in Java and loved it. I was still learning Java and its ability to show help, check syntax and refactor was excellent. But then I did less Java and more Python and returned to vim. One issue was that I was not only editing code, I was writing documents in LaTex, I was editing large 'data' files (ascii text), I was editing blogs and other notes in Markdown etc. Unfortunately, IntelliJ seems to regard everything as a project and does not make it easy (at least back then) to simply create or edit a file that is not part of a particular project.

Another advantage of vim is that most of the time at work I am working on a PC but editing files on Linux boxes. At home I am on a mac. I know I could run X, but I prefer running Putty, and I enjoy the lightweight nature of just bringing up vim. So, currently, vim is my editor of choice.

Also, I must admit that after 20+ years of using vi/vim, I still make the occasional mode mistake and type 'i' when in insert mode, or ':wq', but vim is still my favourite editor.


Given that emacs (and I expect vim) can do all of that and then some, for languages both static and dynamic while taking a fraction of the resources of a monolithic IDE and permitting to use the same editor across all your projects, it seems that your only actual problem is that the default configs are not to your taste.


My laptop can run a full-featured IDE (IntelliJ) without breaking a sweat and it supports all the languages I need and then some.

I guess I could go back to trying to hack together an IDE in emacs or vim with a bunch of buggy, half-supported third party plugins that interoperate poorly if at all, but why?


> My laptop can run a full-featured IDE (IntelliJ) without breaking a sweat and it supports all the languages I need and then some.

I've had a quad-core desktop chug under Eclipse (employer required I use it) and still had to fall back to a real editor regularly.

> I guess I could go back to trying to hack together an IDE in emacs or vim with a bunch of buggy, half-supported third party plugins that interoperate poorly if at all, but why?

Well, mostly people use the well-maintained, integrated, and first-party ones instead. Each to his own, I suppose!


"real editor"? As opposed to what?


As opposed to IDEs, which are characterized by having tightly constrained domains and weak editing features beyond whatever language-specific functionality they bloat up their GUIs with.


An editing environment that makes it easy to develop in a specific domain doesn't make it any less "real" than any other environment.


> Everyone who has used vi(m) has copied and pasted text in while in command mode and done who knows what.

If you are using vim, you should play per vim rules. When you are entering text, you enter insert mode. When you are done, back to command mode. Once you have that mental model, you don't try to c-v(or c-shift-v or whatever) in command mode. Also, if you are willing to try vim, grab a vim build with clipboard support and copy-paste from within vim(=+p paste clipboard, =p paste x selection, =+y{motion} copy to clipboard ... in command mode; or ctrl-r+ paste from clipboard, ctrl-r paste from x selection in insert mode)

> I find the concepts of modes jarring, even antiquated.

The thing I like about vim is translating intent to vim commands - delete 10 lines and then move to the top of the file 10ddG, delete everything inside these parens and put me in insert mode cib etc. Without modes, these won't be as short and sweet. You will be left with long key combinations - the way emacs does it.

> Emacs is better in this regard but I find Emacs's need to consecutive key presses (or a key press followed by a command) to be longwinded.

Isn't that obvious? If you always want to be in insert mode, how else will the special instructions be entered?

> The advantage of either is they're easy to use over ssh+screen (or tmux) for resuming sessions.

And they are very good at editing text, and majority of programming languages, though might require some configuration.

> For statically typed languages (eg Java/C#), IDEs (quite rightly) rule supreme. Static code analysis, auto-completion, etc are just so much better than text-based editors.

I generally am able to find something for Vim which makes language specific stuff easy.

Clojure - http://www.vim.org/scripts/script.php?script_id=2501 Java - http://eclim.org/ Go - https://github.com/nsf/gocode C - http://www.vim.org/scripts/script.php?script_id=3302 Python - http://rope.sourceforge.net/ropevim.html

And a lot more...

> I tend to think the speed differences over not using the mouse are largely illusory.

Doesn't that depend on the task? What will be faster - ctrl-f on this page or clicking edit(or some menu)->find?

Also, for me, it is more about having my fingers on home row is the sweet spot and moving my fingers from my sweet spot is irritating.


>If you are using vim, you should play per vim rules.

This issue is that studies show us vim's rules are wrong: modal editing is a source of confusion and error. I used vi[m] exclusively for 8 years or so and until the very last day I could still make major modal based errors.


> This issue is that studies show us vim's rules are wrong: modal editing is a source of confusion and error.

The so called studies show people who aren't used to modes are confused when using a modal editor.

> I used vi[m] exclusively for 8 years or so and until the very last day I could still make major modal based errors.

I have been using vim exclusively for 5 years now. And I stopped making modal based errors after 2 weeks. My anecdote cancels yours?

From what I have seen, people who leave vim in insert mode are the ones making mode errors. Insert mode isn't the rest mode for vim, normal mode is. You are bound to make errors when starting because out of habit, your mind assumes insert mode as the rest state.


>The so called studies show people who aren't used to modes are confused when using a modal editor.

"Don't listen to this study, listen to my firmly held belief". That's not how this works. If you want to combat a study you need to do so with another one, not by just saying throwing out untested assumptions.

>From what I have seen, people who leave vim in insert mode are the ones making mode errors. Insert mode isn't the rest mode for vim, normal mode is. You are bound to make errors when starting because out of habit, your mind assumes insert mode as the rest state.

Thanks for the condescension. Have you ever started to type a word and had your hands just finish it for you? Sometimes there will be some relatively large word that I type out commonly enough that when my hands notice the first few letters of it they'll type it out automatically with me having to go back and delete it and type out the similar starting word I meant to write. I even recall having my hands do it again on the correction once.

Having this kind of muscle memory is a killer for vi usage. Lots of times I have intentionally left the editor in insert mode for just a second while I grab some text from, say, a website to paste in. What I didn't realize is that my hands knew to always get back to command mode when changing screens so even though my mind had tried to save keystrokes my hands defeated me. The result? Pasted a huge document into command mode. Great. Similar sync issues came up regularly enough that I typically mashed Esc 2-4 times (in case there was, e.g. a command active that would write in the Esc char) rapidly before starting anything to ensure that I was where I thought I was.

In my experience, I wouldn't get the time savings I should have been getting due to having to slow down for the mode management.


> "Don't listen to this study, listen to my firmly held belief". That's not how this works. If you want to combat a study you need to do so with another one, not by just saying throwing out untested assumptions.

Yeah. Combat the studies that you totally provided the link to. Throwing claims around saying "scientists say that" or "studies have proved that" is surely not how it works.

> Thanks for the condescension.

What part was condescending? Leaving vim in insert mode causes errors? The rest state of vim is normal mode?

> Having this kind of muscle memory is a killer for vi usage for you

You are extrapolating personal anecdotes to absolutes.


To be fair you didn't link these studies you speak of either. Modes never seemed to bother me very much and I've been using vim for a while but I can understand the difficulties with it.

Also it occurs to me that I may do some of those things like mashing esc repeatedly just to be sure subconsciously.


> If you want to combat a study you need to do so with another one, not by just saying throwing out untested assumptions.

You can just show that the methodology is flawed, no need to repeat the experiments in all cases


"This issue is that studies show us vim's rules are wrong:"

If using vim is wrong, I don't want to be right.

Honestly, I can believe such studies, and I still would use vim.

One, my shoulder gets tired and sometimes hurts if I move back and forth between keyboard and mouse too much.

Two, by the time I move to the mouse and back, I could have done the equivalent twice on the keyboard and moved on.

Three, there is nothing sweeter than "How did you do that?" :)


>One, my shoulder gets tired and sometimes hurts if I move back and forth between keyboard and mouse too much.

>Two, by the time I move to the mouse and back, I could have done the equivalent twice on the keyboard and moved on.

Vim got this part right, and it ends up being better than Emacs in that regard: in Emacs you also don't need the mouse but all the chording requires moving the hands too much. Ideal would be to take Emacs' non-modal editing and combine it with Vi's simply edit mode: for example, say you are in "command mode" only if you hold down Caps lock, but when the button isn't held down the editor is always in insert mode.


> Everyone who has used vi(m) has copied and pasted text in while in command mode and done who knows what.

try to set mousemode (vim) if vim is compiled with x11-support.


It all started out innocently enough. You experimented with it once or twice in your first year of college, but Nano and Pico were easier—closer to what you had already been using during high school on the Windows machines and Macs. But as time went on and you got more experience under your belt in the college-level computer science courses, you started to notice something: All of the really great programmers—the kind who churned out 4 line solutions for an assignment that took you 10 pages of code to complete; the kind who produced ridiculously over-featured class projects in a day while you struggled with just the basics for weeks—none of them used Nano or Pico.

Staying late one night to finish an assignment that was due at midnight, you happened to catch a glimpse over one of the quiet uber-programmer's shoulders. Your eyes twinkled from the glow of rows upon rows of monitors in the darkened computer lab as you witnessed in awe the impossible patterns of code and text manipulation that flashed across the screen.

"How did you do that?" you asked, incredulous.

The pithy, monosyllabic answer uttered in response changed your life forever: "Vim."

At first you were frustrated a lot, and far less productive. Your browser history was essentially a full index to the online Vim documentation; your Nano and Pico-using friends thought you were insane; your Emacs using friends begged you to change your mind; you paid actual money for a laminated copy of a Vim cheat sheet for easy reference. Even after weeks of training, you still kept reaching for your mouse out of habit, then stopped with the realization that you'll have to hit the web yet again to learn the proper way to perform some mundane task that you never even had to think about before.

But as time went on, you struggled less and less. You aren't sure when it happened, but Vim stopped being a hindrance. Instead, it become something greater than you had anticipated. It wasn't a mere text editor with keyboard shortcuts anymore—it had become an extension of your body. Nay, an extension of your very essence as a programmer.

Editing source code alone now seemed an insufficient usage of Vim. You installed it on all of your machines at home and used it to write everything from emails to English papers. You installed a portable version along with a fine-tuned personalized .vimrc file onto a flash drive so that you could have Vim with you everywhere you went, keeping you company, comforting you, making you feel like you had a little piece of home in your pocket no matter where you were.

Vim entered every part of your online life. Unhappy with the meager offerings of ViewSourceWith, you quickly graduated to Vimperator, and then again to Pentadactyl. You used to just surf the web. Now you are the web. When you decided to write an iPhone application, the first thing you did was change XCode's default editor to MacVim. When you got a job working with .NET code, you immediately purchased a copy of ViEmu for Visual Studio (not satisfied with the offerings of its free cousin, VsVim).

Late one night, as you slaved away over your keyboard at your cubicle, working diligently to complete a project that was due the next morning, you laughed to yourself because you knew no ordinary programmer could complete the task at hand before the deadline. You recorded macros, you moved entire blocks of code with the flick of a finger, you filled dozens of registers, and you rewrote and refactored entire components without even glancing at your mouse. That's when you noticed the reflection in your monitor. A wide-eyed coworker looking over your shoulder. You paused briefly, to let him know that you were aware of his presence.

"How did you do that?" he asked, his voice filled with awe.

You smile, and prepare to utter the single word that changed your life. The word that, should your colleague choose to pursue it, will lead him down the same rabbit hole to a universe filled with infinite combinations of infinite possibilities to produce a form of hyper-efficiency previously attainable only in his wildest of dreams. He reminds you of yourself, standing in that darkened computer lab all those years ago, and you feel a tinge of excitement for him as you form the word.

"Vim."

:wq


Rudism originally posted the story here: http://www.rudism.com/s/vimcreep . Just submitted it to HN, upvote here (http://news.ycombinator.com/item?id=4235876) if you found this story insightful and beautifully well written.


What a beautiful story, thank you for sharing.

It is exactly how it happened to me. I looked over shoulder of one guy and when he changed some code in front of my eyes before I could blink, I asked him 'How did you do that?' And rest is history.


And it keeps happening. Everyone knows just a subset of Vim, and everyone knows a different subset. Watching another person use it, you'll ask them how they did something. And they'll have to do it again, watching the keyboard, because they don't know the keys that they hit. It has entered their muscle memory.


I am thinking of organizing vim user groups or tutoring sessions where an experienced vim user sits and watches a novice try to edit, and basically just yells at them (corrects them between NGGGGGHGHHHGHGBNNNN noises).

I look forward to being one of these novices. I'm faster in vim than any other editor by far, but I know I could still be 2x faster.



That sounds like a really dull anxiety dream. Or a really nerdy porn film.


Make them wear a drill sergeant hat too.


"I WANT YOU TO COME TO MY HOUSE AND EDIT MY SYS FILES!"


"everyone knows a different subset" This was pretty much my experience with a co-worker. We both thought we were vim gurus, but I was shocked at all the tricks he did that I didn't know, and vice versa. I'm beginning to think that I know less than 1% of vim, but it still helps me be very productive.


Which is one reason why little usage vignettes (vimgettes?) are helpful.

I've got a quarter century history with vi and its kin, and am still learning new tricks.


It wasn't like this but I would say my start was quite similar. I had just heard/read people being so productive with Vim and I always wanted to start but never could take the jump.

One time I had to do a college project in a language I had not used before, JESS (JRE cousin of CLIPS). Though its similar to Scheme in which I had coded a few years before, it has a few of its own syntactic idioms. I planned to do the project in VIM. As there was no baggage of using JESS with any IDE before, there was no such thing as a hindrance or inhibition which I used to have while trying to using VIM for coding C/C++, etc.

Within the next 2-3 weeks I learned the basics and a few intermediate use-cases of VIM (refactoring using registers, etc...). After finishing the project, I shifted to code in C/C++ using VIM has my primary editor and have never looked back since. I basically piggybacked my experience with VIM in JESS and the it took less than a day to translate all that and use it with C/C++ code :)

With regards to ViEMU, my use case is to open the same file in both VIM and Visual Studio quite sometimes as they both can detect changes made to the file outside of the editor. So far its worked without any issues :)


I've never seen anyone using vim... maybe that's why I haven't had the guts to switch yet.


In that case, let me point to my SO answer where I share a videos of a Vim guy in action.

http://stackoverflow.com/questions/1088387/what-specific-pro...


Having toyed with Vim in the past I was never convinced enough to switch. I guess I've never truly seen it 'in action'. I'll have to watch these videos. Thanks for the link.


If possible, start with a Vim plugin for your editing environment.


That's what I was thinking about. I use Sublime Text so vintage mode should do the trick.


I think this is a good route to go. My coworker started this way and asked questions to me and our other Vim user.

After a couple of months, he got used to enough Vim functionality to make the jump. He was also motivated by the vim-features lacking in Sublime Vintage mode, but I can't recall which ones specifically were missing


> your Emacs using friends begged you to change your mind

Stay classy.


$vi thanks.txt

i

Hi, Just want to say thank you for this beautiful note.

:wq

$sendmail <Rudism's mail> < thanks.txt

PS: had you provided the email in your profile. I might have actually mailed you :-)


:x


ZZ

(no need to hit <Enter>)


^Z

(no need to quit Vim ;-)


:shell

(Never ever leave vim)


:butterfly

;)


I have been using Vim for over 3 years and I didn't know about the whole line completion.

I think the best thing about Vim is that it will always keep surprising you. If only we could find a life partner like that, there won't be any divorces.


This is a little out of left field, but...

> If only we could find a life partner like that, there won't be any divorces.

Personally, I find that if you stop relying on your life partner to be the person you expect them to be or want them to be, then there won't be any divorces. This idea that you have to just find the right person and everything will be fine is pretty flawed and won't take you far. Sure, people are different, and you should find a good person you can get along with, but that's only the start. Any person will stop surprising you after a while, and you have to be prepared to start from there and still build something together. In other words, don't give up just because your partner is an emacs user.


I've been using Vim for over 14 years and never used whole line completion. It seems vaguely familiar like I might have seen it in the docs, but I've never thought "hey, I'm gonna look up the keystroke for whole line completion!"


Whole line completion is very useful when you write very repetitive languages.

In CSS, <C-x><C-l> is a gift of the gods.


Or maybe that's why there are so many divorces!


I understand Vim. Really, I do. I even know how to use it for the most part.

But I guess I just don't get it. It's too obtuse. I don't feel connected to my editing while using it, I feel... connected to Vim. Which, I think, might explain why others feel so connected to Vim too. They get attached to it because it's an investment, and as we know from various psych studies, we get attached to things we invest in.

This isn't a bad thing, just wanted to throw my 2¢ out there. Vim's a cool language for text editing, but it's not the only one.


I completely understand where you are coming from.

For me and others, we actually feel connected to our text instead of Vim. Let me give you an example, let's say I have following sentence.

"Why, oh WHY, do those #?@! nutheads use vi?"

my cursor is on the letter 'h' of 'nutheads'.

Let's say I decide to change the whole word to 'crazy people'.

Here's how you would do it in conventional editor (using EditPlus as an example).

Ctrl + <- (to jump to n)

Ctrl + Shift + -> (to select the whole world)

Shift + <- (to remove the space which was selected. )

Type in "crazy people"

Here's how you would do it in Vim.

ciw - (change inner word), it gets rid of the whole 'nutheads' word and puts me in INSERT mode.

type in "crazy people"

As you can see, EditPlus forces to you to navigate the text using conventional method. It doesn't have a concept of a 'word'.

Compare this to Vim. I told Vim what I exactly wanted to do ('change inner word') and it let me achieve that without any fuss.

As I wrote in my other comment, Vim lets me 'talk' and 'interact' with my text at a semantic level. Vim is like a translator which completely disappears when I am working with my text.

The example sentence was borrowed from another excellent article on Vim:

http://www.viemu.com/a-why-vi-vim.html


Excellent comparison, thanks.

It's important to note that many modern text editors do have concepts of "words" and "lines" and such that can be used in similar ways. Granted, not near the extent of Vim, but they're still useful.

In sublime for example, I can Ctrl+Shift arrow to select words before and after. This even works with multiple selection (multiple caret positions). It's pretty cool.

Again, I understand that Vim is more of a language to describe editing text and is very efficient, I'm just saying you can get close with modern editors, and personally I find their visual language to work better for me.


Mainstream editors get close to Vim only if you use Vim as it were a mainstream editor. Yes, on a mainstream editor you can use Ctrl+Shift+Arrow to select words - which already requires you to move your hands way more than Vim would - but - among other things - how do you cut/change/copy text:

- up to a specific character?

- up to a specific string?

- up to the beginning/end of a document?

- up to the beginning/end of a sentence?

- up to the beginning/end of a paragraph?

Good luck ;-) Maybe these examples are lame because I haven't edited text in a while and I couldn't think of anything better, but I hope you can see what we are talking about.

Read PG's essay about Blub languages and Lisp, then replace Blub with mainstream editors and Lisp with Vim and you'll understand why Vim is better. My colleagues used to ask me why I kept using a weird editor, and when I answered they replied the same way you have done, yet they always marveled at me editing texts at insane speeds. Go figure.

With Vim, you also have a reduced mental load, as its command set relies on intuitive and flexible composition.

Actually I don't even use Vim. I use a Vim mode for GNU Emacs, which gives me these added advantages: - learning a Lisp (ask Eric Raymond why this is advantageous); - having a powerful batch text processing tool (no need for Perl, Awk, and the likes); - a box of tools for several tasks which are more powerful than mainstream ones.

Have fun.


I love how every Vim user speaks to non-Vim users as though they're novices that are just "not there yet." It's cute.


Non-Vim users are novices that are just "not there yet", when it comes to text-editing. The Vim way is the most simple and effective way to edit text by means of a keyboard. Like Lisp and the Dvorak keyboard, it's alien, but it's actually simpler. Maybe, now that touch-screens are becoming commonplace, an equally or more effective new way will be developed.


My guess is GP knows how to use Vim, and yet he's happy to use something else... but many Vim users can't imagine that scenario.

I personally know and like Vim and Emacs, but I'm using ST2 because those editors lose some of their greatness on vanilla Windows. And Emacs keybindings do hurt my wrists.

Also, I could never get really fast at editing multiple files inside a single Vim session. Nothing near Emacs with ido.el or vanilla ST2. I already tried Lusty* packages and Nerd* packages... It's also kinda hard to prevent :q from quitting the whole editor, which always bugged me.

When I open it from the terminal for a quick fix on a single file, Vim works very naturally and I think, once more, "hey that edit was easy and fast - why not switch to it as my main editor?"...


You've proved my point. In your words Vi-style editing is "natural", "easy" and "fast". Vi-style is better than Emacs-style because the latter "do hurt my wrists", thus discarding the only worthy contender.

The only reason you are using another editing model is because you've found the tools offering Vi-style editing to be lacking in important areas.

Sublime may be better than Vim as an overall editor in your particular case even when the editing model of Sublime is less efficient than the one of Vim. We agree on this: we don't live in a perfect world. Indeed, even Vi-style editing is not perfect, as it was designed for a different keyboard than those which are commonplace nowadays.


RIght, right. Unfortunately I can't convince my brain to accept that Sublime+Vintage works like Vim. I need to be in Vim to trigger the Vim mode of thinking in my brain...

I'm curious though: I thought it was Emacs that had a special keyboard in the old days. What do you think could be easier in Vim with a different keyboard? (I can only think of ESC position).


Not much, actually, besides : which was unshifted. But we shouldn't overlook people who try to use Vi(m) on keyboards other than the US one. For instance, on the Italian layout, / and ? are both shifted, and on different keys, thus causing their relationship to be less intuitive, and further from the home row.


Well, there is Vim and there is the Vi-editing style. My understanding was we were talking about the latter. In such case, I admit I couldn't think of a proficient Vi-clone user switching to any other editing model.


>Non-Vim users are novices that are just "not there yet", when it comes to text-editing.

Religious war nonsense. Vim still uses modal editing, which we've known to be a mistake for how many decades now? Sure, vi is better than Notepad. Congratulations.


Mmmmm... Modality a mistake? Seemingly, it depends on whom you ask. People have been using it for millennia in their languages (many words change meaning according to their context, context being the "mode"). Musicians have been using it proficiently for centuries for their music sheets(notes on the music staff change according to tonality, tonality being the "mode"). Nowadays (most? many?) people use modality every day on their mobile phones (e.g. T9 has a modal keyboard). Could it be that studies about modality were flawed? I think so. For instance, if you teach modality in the wrong way, I agree you will "realize" that modality is ineffective. I had an hard time using T9 before being told how to use it effectively, and I have helped a couple of people who hated it as well. And I had an hard time using Vim before being told how to use it effectively.


There is at least one study that talks about this. I'm talking about modal editing. Obviously I'm not against context.

>Could it be that studies about modality were flawed? I think so.

This isn't how we progress. Do you have a study that demonstrates the opposite? Then claiming the study was flawed is meaningless.

>And I had an hard time using Vim before being told how to use it effectively.

Stay classy. I knew how to use it just fine, but mode management slows everything down.


> There is at least one study that talks about this.

I couldn't find any. Could anyone provide some pointers, please?

> I'm talking about modal editing. Obviously I'm not against context.

When scientific proof lacks, appropriate analogies can be our only tool in analyzing a issue and reaching a conclusion. My point is that people don't seem to have issues with modality in other contexts, provided that they know how to cope with it, thus why should I doubt their ability to cope with modality while editing?

> This isn't how we progress. Do you have a study that demonstrates the opposite? Then claiming the study was flawed is meaningless.

Sadly, progress is slower than we wish. If a study contradicting empirical evidence is flawed, it doesn't prove anything, for empirical evidence wins and we are back to square one.

> I knew how to use it just fine, but mode management slows everything down.

This proves that some people have issues with modal editing. Why? Maybe: - they didn't approach it effectively (in the case of Vim, they lingered in Insert mode); - their tools were inappropriate (in the case of Vim, the Esc key was too far). - or modal editing requires some mental capability which not everyone possess (some people can type on Dvorak and Qwerty, indifferently); - or modal thinking is a learned skill; - or... If we can solve this problem, instead of saying that modal editing is better, we could say that modal editing is better when some conditions are met.

EDIT: I've also thought about reasons for Vi-style editing not being as superior as it was in the past: - keyboard layouts do not resemble the keyboard layout used while designing Vi; - keyboards with integrated touch-pads and/or track-pads are available to make switching to a pointing device quicker.


When your cursor is in the center of the word, you can't use ctrl-shift arrow to select that word [it will only select part of the word]. Therefore first you need to move cursor to a side, then start your ctrl-shift work that you described.

GP highlighted this special thing. I guess you missed his main point.


In terms of finger travel, if I've already moved my right hand to the arrow keys, and my left hand to ctrl and shift, then it's simply hold-ctrl, left, start holding shift, right. While not quite as simple as ciw, my main complaint is moving my right hand all the way over to the arrows and back; complaining about the comparative complexity of the sequence seems ridiculous.


What annoys me about the arrow keys is that I can't reach them without looking, and they also change position on different keyboards (standard keyboards vs laptop keyboards, for example). Having to look to the keyboard distracts me.


Agreed - needing arrow keys in the middle of doing anything else is bad. My point was that, in this particular case, the fact that the arrow keys are needed is basically all of the bad, and that the parent's complaint of increased complexity/typing is certainly not strong and perhaps not valid.


As z92 mentioned in reply, you missed my point about the fact that EditPlus or Sublime will force you to move to the beginning of the word before you can select it. Try the above exercise in Sublime and then in Vim so that you can see the difference clearly. May be that will kick in that bulb in your head and you will see Vim in a whole different light. Trust me, it took me a long time before Vim 'clicked' for me.


As the other reply mentioned, it's Ctrl+D, and there are many other ways to accomplish the same things that Vim can do in general. Maybe one is slightly better or more efficient, but they're really not that different.

Not to get into a holy war, but that's is one of the things I don't really like about Vim—the community is pretty religious and Vim "can do no wrong" in a sense. The process of conversion is just an epiphany and if you haven't realized that, then you must just not have used it enough, because it's factually better. Not really true. I'll leave it at that.


I am sorry if you get the impression that we are trying to suggest that Vim can do no wrong.

Your original comment was exactly how I felt when I was learning Vim. I also thought that Vim is obtuse and it gets in my way. And now after using Vim for over 3 years, I now know why Vim is the way it is and I was sharing my epiphany.

By all means, use the editor which makes you most productive (you are already ahead of 70% folks who don't even care to find better editor). But at the same time, if you think that Vim is crazy, at least listen to the other side of an argument with an open mind.

PS: I also replied to comment by 'recursive' on the Ctrl + D shortcut.


I think you just embodied the entire sentiment the GP was criticising: the whole concept that Vim is not an editor; it's a state of mind.

I compel you and anyone else who is quite dogmatic about their choice of editor to try explaining it in such an objective, non-patronising way, so that the layman can think, "oh, it sounds like it's worth learning then."

I'm not a Vim user per-se, but I'd find more value in something like this, possibly with a more specific follow up:

Vim works a bit differently than other editors. It cares more about manipulating existing text than creating new text, and so it tries its best to let you make changes without just deleting and re-typing from scratch, or using your mouse to point and click and drag and highlight.

It has a steep learning curve so it's initially hard to adapt not just to this change in perspective, but also to the commands and shortcuts that allow you to be more efficient and productive.

Such is the investment of time and effort required to do be good in it, you might consider grokking Vim a commitment as big as grokking your programming language of choice. However, you will in return acquire a life-long knowledge of working in Vim, and using it will become second-nature and infinitely preferable to manipulating text by hand.

As a developer, knowledge of Vim is valuable because of two things:

1. Portable configuration: what you learn, and how you personalise your editor, is transferrable to other machines, as it's just text. No modern editor has adequately replicated such basic functionality.

2. Ubiquity: you can't load Sublime Text, Textmate, Eclipse, {$gui_editor} on the VPS you routinely SSH into. You will, however, have access to Vim, or its predecessor Vi. You can thus have a somewhat familiar environment when working on remote servers, without any faff.


This is a sublime comment. Thank you for writing it.


> Sublime will force you to move to the beginning of the word before you can select it.

Only if you don't know how to use it. Ctrl + D does it in fewer keystrokes than you can in vim.


Sure, there could be a short cut to make this particular example easy. But can you combine this knowledge and use it everywhere?

Let's say your sentence was like this:

"Why, oh WHY, do those #?@! 'nutheads' use vi?"

[Notice that word 'nutheads' is enclosed in single quotes.]

If I am on the letter h, I can press [ciw] to only replace nutheads word with my target word, it will keep the single quotes as it is.

OR

If I wanted to replace the whole word including the quote, I would press [ciW] (notice the capital W)

Now, can you use that knowledge of Ctrl + D in this situation in Sublime?


I'm by no means a sublime expert, but I'd approach those scenarios like this. For replacing the inner content, Ctrl + D still works. To also replace the quotes, I'd use Ctrl + D, Del, Del, Backspace.

Yes, in the second case, Sublime is one additional keystroke. I know you could come up with examples that would show bigger advantages for vim.

FWIW I do believe that vim has advantages to some editors in certain scenarios, but I think those advantages are overestimated by the vim-inati. If you've spent years learning one editor, of course it will seem more capable than editors you have used less.


What if it's 'so called nutheads' that you want to change?

AFAIK, Sublime Text 2 doesn't provide a shortcut for that. You can do Ctrl+D to select "called" but then what? Extending selection to scope or brackets won't help and you are back to a series of Ctrl+Left -> Ctrl+Left -> Ctrl+Shift+Right -> Ctrl+Shift+Right -> Ctrl+Shift+Right. In Vim, that's ci', or ca' if you want to also remove the quotes. Hell, you don't even have to move the cursor to the quoted text to do that.

This scenario happens dozens of times in a given day around here and, as for many other little things, Vim and his "awkward" language and it's "antiquated" modality rule.

The irony, here, is that you actually can change the content of a pair of quotes in ST2.

If you activate its Vim mode.


This may just be me, but I feel that a lot of the productivity that Vim supposedly creates is a result of programmers spending lots of time learning one tool very well, as opposed to something inherent within Vim that automatically makes you more productive.

That's not to say Vim doesn't have an excellent ecosystem, and has tried and true ergonomic benefits, however I feel that if someone spent the same amount of time learning, say TextMate (just an example, may not be the best), they would be just as productive.


Absolutely not true. The best description for VIM is "programming your text". In VIM you have a set of commands that you use to manipulate text. Generally commands looks like nOm where n is number of times to repeat the whole thing, O is operator to apply, m is motion command/selection. So for example 3dw applies 3 times the d (delete) operator to motion command w move one word forward, i.e. delete next 3 words. The nice thing is if you learn lots of motion commands you instantly learn lots of ways to manipulate text objects based on those motions. Want to change inner if block in your code? Just type ci{ (change inner { which deletes everything inside the {} block the cursor is in and places you in insert mode. Etc.

In other editor you have keyboard shortcuts and there are only so many you can have. In VIM there are over 1500 commands (not shortcuts). People who say "vi key bindings" or "vi shortcuts" don't get vim.


My favorite form of this is when using regular expressions.

You have 'v' for visual mode, where you move the cursor around and can select stuff.

You have 'd' to delete things.

If I press 'v' then move around, then press 'd', I'll delete the selection.

If I press 'vf,' it means 'select until you are on a comma'. If I press 'df,' it means 'delete until you are on a comma'.

The problem with these two modes is that they're restricted to one line.

Now if I do 'v/,$', it means 'select until the first match of the regular expression ',$' (comma on end of line). If that comma is 5 lines below, it'll find it.

What's fun is that with this sublanguage, I can say 'dv/,$' and it will delete where the selection of the next comma at the end of a line, or more generally, <Command>v/<Regex> will do the command until a given regex. If I replace 'd' with 'c', it deletes and puts me in insert mode ('c' is change), and so on.

Even nicer? what if I'm writing Erlang (I usually am), and I want to delete, say 3 functions. I could delete one by getting to the beginning of the function and delete until '\.\n' as a regex (functions are terminated by a full stop). So the command becomes 'dv/\.\n' for a single function.

Rather than calling the same command 3 times, I can do it once, then press '.' twice to repeat the previous ones.

Or I can use the fact that vim has this sublanguage and instead call '3dv/\.\n', which will delete until the next end of a function (full stop + line break) 3 times.

Its command set is fully composable and at some point you find your sweet spot in there.


That is an awesome tip! One question: is there any reason why you do 'dv/,$' rather than just 'd/,$'?


They both work absolutely fine. I tend to use d/<regex>, but the dv/<regex> example highlights the sublanguage and composition a bit more :)


Genuine question: Couldn't this be accomplished by any scriptable editor?


Yes, it's true that it can be done in any sufficiently good scriptable editor. But once you have written all those scripts to do all those magic, your editor will look more like vim.

You have just built your own Vim.


Oh. Well that makes a lot of sense. I feel like I understand Vim a ton better now.


I will grant that "vi shortcuts" is strange, but "vi key bindings"? The operators/motions (or verb/noun) perspective is vital, but those operators and motions are not intrinsic properties of the keys they happen to be mapped to - indeed, you can remap them. The initial mapping is a totally valid question, particularly for lesser-used commands, and one that can quite reasonably be referred to by the phrase "vi key bindings".


I find SublimeText (and TM to a much lesser degree) have certain features that really help with efficiency, like multi-line editing and good key shortcuts for in-file search and replace and regexp replace.

Vim is like this but without having to take your hands off the keyboard, so you get a little extra. But using the mouse and having a very visual hand-eye-coordinated text editing representation is really intuitive, so it's definitely a tradeoff.

Vim takes a long time to get used to, is not intuitive, and gives an extra boost in speed by its very nature; pretty much comes down to that.

Sort of like a car: it takes a long time and investment to learn how to drive and get used to the completely new world of streets and driving rules, but once you're there you can get places way faster.

All that said, I still use SublimeText, because I don't necessarily need Vim to program efficiently (I admit, my main obstacle is my mind, not my editing speed), and the experience of SublimeText is very efficient and matches my intuitive mental model of text. So the moral is, use what works for you.


You might feel that way, but you're probably wrong :) Vim basically is the logical result of taking the idea of "how can I manipulate a text buffer efficiently using my keyboard" to its conclusion. Once you've burned in the muscle memory using arrow keys and a traditional buffer with the mouse is like having your hands chopped off.


I would imagine that with something like TextMate you'd soon reach a point where you pretty much know all the shortcuts. With Vim, it seems like this saturation point never happens, even if you use Vim proficiently for years there is still more you could learn and incorporate into muscle memory for better results. It even surpasses the "collection of shortcuts" that many editors are and becomes almost a programming language for text editing. It's uncanny how Vim posts like this inevitably reveal commands and methods I'd never known before, and I thought I was a Vim expert.


Even moreso once you realize that Vimscript, in it's most basic form, is really just a way to shortcut the clumps of commands you commonly use.


In some ways, Vim programmers are stuck in a local maxima of efficiency - we're really efficient at doing edits like "search for and change this word" and "change parens to square brackets" - but if you look at the sort of advanced features that other editors have, you find that they don't care about those edits, and have chosen to automate different tasks:

Example 1: TextMate users create bundles that drop in common boilerplate easily, and they have a really nice ways to jump between files in a large project. Vim users mostly don't do either of those.

Example 2: IDE programmers tend to have syntax-aware tools that implement common tasks like "extract local variable" or "jump to implementation". Vim versions of these tend to be crude approximations that use regexps instead of actually parsing files.

Personally, the cost of typing more slowly and having to use a mouse to edit text means that I haven't ever learned to use modern editors effectively - so I'm faster as an expert in Vim than I am as a novice in Eclipse or TextMate or IntelliJ or Sublime - but in many situations an Eclipse expert is probably faster than me.


It takes more effort in vim, but for each example you've mentioned some vim user somewhere stopped and thought, "That's useful I wish I had that AND had it in vim."

http://www.vim.org/scripts/script.php?script_id=2715 http://www.vim.org/scripts/script.php?script_id=1984 http://eclim.org/

Picking up Android development is the first thing that really made me consider switching out of vim. With eclim, I'm now half in half out. I do most of the actual coding in vim with eclim doing the menial work of basic error checking, automated imports, automated refactoring, etc. For debugging, and some of the layout tools I'll switch to the Eclipse instance that's already backing eclim and do it there. It's a nice compromise.


TextMate's learning curve is desperately short and flat. After 2 or 3 months I knew everything there was to know. The only dark corners could be found inside language-specific bundles which made them rather useless.

I've used it non-stop from late 2006 to late 2010 and I can attest that the last three years were extremelly boring. On the other side, 2 or 3 months is the time needed to have a firm grasp on the basics and, after 1 year and half, I still learn new tricks every day.

If you want inherent advantages, don't look further than Vim's modes and its language.


If you want something that is inherently superior and has a lot of effort invested in it, you use Emacs ;)


I used vim for about 10 years before I finally gave up, and it was completion that did it for me. It was just so ludicrously hard to customize vim (writing vimscript - although the python integration wasn't much better) that it hurt. I was held back by not being able to customize it, and the fact that I couldn't get any better completion than ctags was insane.

My startup Circle is written in Clojure, so I was pretty much forced to learn Emacs, and the world is such a nicer place. I really wish I had learned Emacs 5 years ago - with the time I spent mastering and then trying to customize vim, I could have mastered and learned to properly customize emacs.


Also, SuperTab is all of the win: https://github.com/ervandew/supertab/

It'll let you use <Tab> for all the completion types, and you can tell it the fallback order for various thing (i.e. try omni, then <C-N>, etc.). It's even slightly context aware, so it can guess a good first completion method for you.

All with <Tab> :)


Nice overview of vim's completion features, but...

This article is very incomplete, there are various completion modes. I also don't recommend mapping complete to tab (or even using SuperTab or other completion plugins). Vim has a total of 13 different completion modes (see :help ins-completion), all of which are useful. There's complete on local and global keywords, complete for complete lines or filenames.

In particular, this article calls Vim 7's omni complete (^X^O) "syntax aware complete" which it is not. It's a language specific completion, which can complete stuff like members of structs or functions. You need your language specific plugins to be installed. Vim ships with a decent plugin for C and C-like languages, which works if you have a ctags database generated (:help 'tags').

If you want syntax completion, you can map it to user-defined completion (^X^U) like this: set completefunc=syntaxcomplete#Complete

It's not particularly useful as such, because syntax complete completes keywords like "for" and "while" which we all have in muscle memory.


Using the article completion method it turns out that I can no longer use <tab> to insert a <tab> since it displays a list of word to be completed.

It might be due to my vim configuration but I doubt it (though I am not a vim script expert by any means).

Here is a function I found on the web a long time ago and that seems to prevent that problem:

  inoremap <Tab> <C-R>=MyTabOrComplete()<CR>

  function MyTabOrComplete()
    let col = col('.')-1
    if !col || getline('.')[col-1] !~ '\k'
      return "\<tab>"
    else
      return "\<C-N>"
    endif
  endfunction
No idea how it really works, I never investigated.

Credits/source: http://www.slideshare.net/andreizm/vim-for-php-programmers-p... slide 44

edit: formating and credits


Though this doesn't help with the holy wars, I do find it just fantastic that there are two editors that so many find, with an acceptable amount of playing, can be the near perfect tool for their craft. I played with vim first but never quite got a flow going...oddly enough I hit it off almost immediately with emacs, it was still damn confusing but I made much more progress much faster. I'm almost disappointed I didn't fall for Vim as it is always on any server I have to use and emacs muscle memory has only compounded my problem with Vim shortcuts! For those not fancying diving into vim or emacs are there any more traditional IDE's with a way to script new behaviours and have them feel native?


There's something weird about the ^P/^N menu - I always have trouble telling which possible completion is selected in the list, and I often end up picking the wrong one.


May be it is your colorscheme.

I took snapshot from my current editing session:

Selecting the last item:

http://i.imgur.com/dEkws.png

Selecting the second last item:

http://i.imgur.com/D6Icl.png

My vimrc is here: https://github.com/SolutionYogi/VimSetup


yeah, I should tweak it somehow. This is what the (otherwise amazing) inkpot theme looks like: http://imgur.com/TaUym - can you tell that the dark, bold entry is selected?


I don't know which entry is selected (because I don't know the color scheme) but those two items have very distinct colors and I would definitely be able to differentiate between them.

I think you should experiment with some other color scheme or try to tweak your existing scheme.


Moving to vim from TextMate, I found that I missed TextMate's autocompletion.

In Vim you have to specify whether the word you're looking for is above or below the cusror (using C-P or C-N). IIRC, TextMate just looks for the closest matching word, no matter where it is.

I wrote a little plugin to do make it exactly that:

https://github.com/sirdavidoff/vim-nearest-complete

Disclaimer: totally rough and not (yet) very customisable


> For example, in HTML vim should know that you can’t nest a div inside an a...

In HTML5, you can. See http://html5doctor.com/block-level-links-in-html-5/


That.

And isn't it the job of the programmer to know those things?


i'm a java IDE user (eclipse, then intellj).

in intellij, you can ctrl+w to select word, ctrl+w again to select statement, ctrl+w again to select function, etc.

you can also refactor replace all, shown if foo.gif actually exist in img src, ctrl+click to css, shown if a variable (in code/js/css) is unused, hinted if a line can be simplified, etc.

can vim do that?

if it can not, what's the compelling reason for people like me to use it? (i honestly interested, but wondering if it's worth the effort)


I use Intellij (and the derivative editors RubyMine and AppCode) as well.

IMO the main advantage of vim is it's instant. No waiting for the IDE to load. IJ takes quite a while to load and you have to have your project set up.

Another major advantage of vim is it's available everywhere. SSH to your production server and edit just like you do your code.

But I have to say: I much prefer coding in the Jetbrains editors. They offer a UX that can't be matched by vim. They are just smarter, esp for statically typed language. But even dynamic - they are damn good. And you can use VIM key bindings if you like.


Also checkout neocomplcache, https://github.com/Shougo/neocomplcache


We never saw poetry written about TECO.


I didn't know this one: ^X ^L


"Fuck VIM" -Richard Stallman




Applications are open for YC Summer 2019

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

Search: