This is an extremely awesome, fantastic, exhilarating use of hyperbole.
What I gained from the article wasn't any explanation of why Vim is great; indeed, there was little included in this respect, aside from moving "entire blocks of code with the flick of a finger." Even the cool feeling of proficiency you get from knowing a tool well, and the fun of getting to show off a skill to a "how did he do that!?" audience was secondary.
My favorite part was the implicit reminder to relax about my tools. The most effective use of hyperbole is not the emphasis of a particular point, but a caution not to take ourselves too seriously, and place our self-satisfaction in proper perspective. The most powerful instances border on satire, and in that respect, this piece was perfect.
Addendum: I use vim and pentadactyl. They are extremely awesome, fantastic, and exhilarating.
Also, years of evangelism will teach you that you cannot convince someone that Vim is better, let alone great. A lot of the propaganda out there starts by telling people "you're doing it wrong! Let me show you the better way!".
Vim is one of these tools that isn't obviously better, so that you don't really understand its power until you try it (for a few months or so).
I enjoyed this article exactly because the author didn't try to rationalize the superiority of his tool, rather depict in an entertaining way, a familiar (to me) feeling of empowerment said tool can give you.
Exactly. This is one reason why I never tell people they are wrong regarding a choice of text editors. Keep in mind I usually have multiple VIM instances open and an instance of gedit (because I do some things that VIM is a little clumsy at regarding my todo list).
What I usually say is something like:
There are text editors and then there are text editors. If you are only spending a few hours a month in front of a text editor, you are probably better off with something simple. If, on the other hand, you are going to be using it all the time, it is well worth your time to learn an industrial strength one like VIM or EMACS. These have learning curves, but they have big payoffs as well regarding productivity.
I haven't tried it. I will take a look. If it has a bunch of useful macros it might work. I might be able to program my own macros as well.
The thing is that Cut this text and past it here is still a very useful paradigm for my todo list, while remove line 47, change the "* " at the beginning of the line to "3) " and replace the current line starting with "3) " is a little less helpful. Note that items in the queue to make my short to-do list are coded either * for larger tasks or % for smaller ones. In theory VIM + macros would work. Just not sure I want to write the macros.
Many worthwhile revelations are inherently experiential. There are a very, very few people who are sufficiently gifted in communication to be able to sell large numbers of people on them. In most cases, though, people simply have to achieve enlightenment or experience the concept for themselves.
The Zen koan of the seeker told he would find enlightenment by acquiring the shirt of the happiest man in the world ... who turns out to be shirtless ... captures something of this essence.
I love Vim, but I don't ever recommend it to anyone. I think it gives me an advantage. Whey would I want other people using it and thus lose that advantage?
I'm pretty sure that "re-factoring" could've been accomplished equally fast with the mouse. In most editors, you can double-click to select a token and triple-click to select a line. So the mouse version would be: double-click 10, copy, double-click ten, paste, triple click the line you want to delete, press delete. Pretty fast, really; especially if you're using a laptop where the cost of moving your hand to the mouse is negligible.
I tried Vim for several months and got reasonably competent. But then I timed myself doing the Vim tutorial with Vim and Gedit, and Gedit won handily. For this reason I'm convinced that Vim is only popular because using it gives you hacker cred.
I'm open to changing my mind based on solid experimental evidence, but for now I only use Vim occasionally, for the macros.
Your first paragraph ignores the central point of the screencast: How would you record those mouse interactions as a general, reprogrammable macro? He signs off the video with an important statement which hints at the 'zen' of using Vim for a long time: "It's a nice thing to aspire to, to automate all of your interactions with the code in this way".
Gary Bernhardt (guy doing that screencast) also does [Destroy All Software][1]. Lot of useful Ruby/Rails videos, done with vim. He's just as fast as this video, if not faster, and he doesn't slow down.
I disagree for the following reason: I think of :w and :q as two concepts, and :x adds a third, which I personally feel adds some cognitive load, like I now have to differentiate between wanting to write, wanting to quit, and wanting to do both at the same time. With :wq it feels to me like I'm deliberately saying "let's write and then quit".
Muscle memory is not likely to kick in anyway because I almost always use :w and :q separately. I'm modifying the file in one tmux window and compiling/running it in another, so I keep the file open in vim. I don't want to replace :q with :x because I want to be alerted if I've made some changes that haven't been written yet, because that means I may have neglected to test them.
Same here ... I'd ask people why you wanna do two keystrokes when you understand when to :x. Creatures of habit.
One thing I dislike though is accidentally having my shift key pressed which converts the :x to :X and Vim thinks I want to encrypt the file.
I recently discovered a way to learn Vim without fear: learn undo ('u') first! If you know that, you can just mess around with Vim commands until you inevitably screw something up, undo the changes, relax, take a deep breath, and Google whatever you're trying to do.
... and this to go back to the state of the file 10 minutes ago:
:earlier 10m
and
:later 10m
to go back. Note: This is independent of undo/redo cycles as Vim keeps track of that in a tree-like structure. There's just no really great default way of accessing it. See Gundo for a plugin that tries to make it more accessible.
>Addendum: I use vim and pentadactyl. They are extremely awesome, fantastic, and exhilarating.
Hell yeah! In fact, I came to Vim through pentadactyl because I wanted a way to browse without using the mouse. I second the description of "exhilarating": navigating pages from the keyboard is much, much faster than clicking on links (except in those cases where the poor site design makes the clickable buttons undetectable to pentadactyl... Psst, HN search result navigation, that means you)
And the ring that binds them together is Pentadactyl's Ctrl+i, which opens the the textarea with focus in GVim, and then loads it back when you close the editor. I'm typing this in it ;)
Wow, and you learn new features every day. Thanks! (It probably teaches such a trick in the tutorial but early on I was busy de-Vimming the actual text input in browsers when I first installed it...)
This feels like an article about a religion or cult, not a software program.
I just don't get it. Ever since newer editors got block editing or multiple insertion cursors, and RegEx find & replace across multiple files, and searching filenames to open... I feel like I've already got everything I need!
What am I missing out on? I don't feel like my text editor holds back my productivity. Using something like Sublime, I never think, man, if only Sublime did x, it would save me five minutes, twenty times a week!
I've never had anyone explain to me what specific kind of code editing is so much more productive in vim than in any other editor. Can someone give me a real-world, commonly occurring example?
Or is it not about productivity? Is it an interface thing? People like the way it feels to use? The article explains the "feeling" I always hear about, how vim is so much better, but for the millionth time, fails to tell me why, in a way a non-vim-user can understand.
You really have to sit down and see a vim user work to start to understand.
In vim you don't just move around with arrows, then delete and then replace the text you want. What happens is you can use noun-verb associations to do things.
For example on a line like this:
var foo = "bar";
I could be at the beginning of the line and type the following keys to change the inside of the quotation marks:
ci"baz<esc>
In sublime I would do the following:
<cmd>→←←⌫⌫⌫baz
The difference between the two was an epiphany for me. In vim I could actually use verbs and nouns to determine how I will edit the text in front of me. I now have a language that I can use to edit text rather than editing the text using the most manual of tools and the verbs and nouns combination are only limited by my imagination and the plugins I install.
If you're into that sort of thing, you can do Ctrl + F, bar<esc> in Sublime too. Most of the comparisons in this discussion between vim and non vim demonstrate high proficiency in vim, but not as much elsewhere. Of course you are more proficient in the tool you know best.
Does your example include the action of deleting bar with baz?
Also, not having to move away from the home row makes me feel much faster. Having to use Alt/Control/Arrows makes me cry. (I know you can't avoid Control in Vim, but in this example it is not required.)
ci"baz<esc> is 7 keystrokes, only one of which is a jump.
<ctl-F>bar<esc>baz is 8 strokes and two jumps. It also requires typing the entire string in quotes. If the example were
var foo = "The quick brown fox jumps over the lazy dog";
The vim example would not change but yours would.
I'm not trying to be an a-hole, use what you like, I'm just saying, that for me the attraction to vim is the strive toward the minimization of keystrokes, especially ones that require me to move my hands.
However, if I was actually faced with this problem, I'd use End, Ctrl + Left, Ctrl + D, baz, which is a total of 7 keystrokes. (if you don't release Ctrl)
The vim example was 8 keystrokes. (" is shift + ') I have no doubt that you could manufacture an example that shows a benefit for vim, but I think that the advantages are overestimated by heavy vim users.
Edit: Your longer string example is a good example of a task that's more efficient in vim.
A commonly overlooked aspect to the vim way of describing what you're doing in verbs and nouns and prepositions is that the "." character in vim means "repeat my previous edit". So if you can find a way to "phrase" your edit as a single change (i.e., 6sasdf<esc> would delete six characters starting under the cursor and leaving me in insert mode, then insert the letters asdf and exit insert mode) instead of many (i.e., xxxxxxiasdf<esc>, deleting 6 characters separately, entering insert mode and entering the letters asdf) then you can go to another spot in the text and just hit . to repeat the edit. I've given a contrived example here, but this is enormously powerful. It's why there are several ways to enter insert mode: "i" to enter under the cursor, "a" for after the cursor, "I" for first non-whitespace character on the line, "A" for after the last character on the line, "o" for opening a new line below the cursor, "O" for above, "c"+motion for deleting through the motion and leaving in insert mode, count+"s" for removing count characters starting from cursor and leaving in insert mode. There are more....I'll stop :)
Sublime Text supports multiple cursors, which I find to be a more natural way to do things where you might use those tiny repetitions-- you select all the regions you want to edit first (usually by repeatedly adding the next match to the selection), then any typing or movements you do occur in parallel.
I don't know why other Vim users focus on number of keystrokes.
In his example, what is more important is that you are 'describing' what you want to do with text with commands.
So when you have
var foo1 = "bar";
var foo2 = "hello hi";
var foo3 = "when and why";
You can use the same command [cib"] to change the value assigned to foo1/foo2/foo3. You are describing your change semantically i.e. I want to change word inside the double quotes.
In Sublime and other editors, it matters what the assignment is and you have to use different approach in each scenario.
Frankly, as I type at 70wpm, I don't care about saving a few keystroke here and there.
Some Vimmers (like me) remap a key combination (pref one you rarely would want to add to the text) to Esc so you don't have to leave the home row. I use ;j or lkj. (and If you actually want to type those in insert mode, just do it a bit more slowly or with ;ji escape-inserts between the characters. Generally, it takes a long string of keystrokes before moving off the home row is faster.
As a heavy user of Sublime, Coda 2 and someone that is still getting to grips with vim, I'd say the real advantage of vim is you can do all of that over ssh with minimal keystrokes over a crappy connection.
Coda's "open quickly" is too slow to use over SSHFS (although is OK on a local network over AFP). Sublime's not too bad but it can take a while to build its file list.
Yes, but the set of brilliant people is larger than the set of brilliant people using the best tool in each area. We don't live in a perfect world, and brilliant people make trade-offs. Unless you know what kind of trade-offs they made, you can't generalize their choices. For instance, when Peter Norvig switched from Lisp to Python for his classes, many people argued that Python was an "acceptable Lisp". When asked about his decision, Norvig answered that Python was a better choice for his teaching goals, and nothing else.
Also, let's not confuse techniques with tools. It is unfortunate that, other than modal editing which is too generic, we don't have a name for Vi-style editing which does not involve Vi, so people confuse Vi-style editing (e.g. the technique), with Vi (e.g. the tool). The tool may have its own shortcomings which render it unsuitable.
i think it's easier to grab the mouse, dlb click bar, foo
with vim, it's still easier than grabbing the mouse. that's the litmus test of text editor interface effectiveness. the mouse is awesome, hard to beat. so if your editor beats it, game on!
And considering you didn't have to press <mode>: beforehand, it can be just as fast.
I'm a vim user, but using it for something like Objective-C in place of the wonderful autocomplete in Xcode would be a totally dumb thing to do. It's simply not smart enough to improve my productivity, even with the slight speed increases with text-manipulation.
First time users of vim would use the arrow keys too. Only after you gain some experience do you start thinking with motions.
The same holds true for Sublime Text. Instead of using the arrow keys, you could do any of the following:
Ctrl+H : Replace
bar : Find what
baz : Replace with
Ctrl+Shift+H : Replace first match
<esc> : Exit replace mode
or
Ctrl + I : Incremental Find (finds and selects finding)
bar : Find & select text
baz : Overwrite selection
or
Ctrl+<Right>+<Right>+<Right>+<Right> : Reach the word bar
Ctrl+d : Select word under cursor
baz : Overwrite selection
or
Ctrl+P : GoTo Anything
# : Goto word
bar : Goto word 'bar' & select it
baz : Overwrite selection
I agree that vim's vocabulary is very expressive and very powerfull. I switched to Sublime Text because tweaking vim to meet my needs was just too much effort, even for simple things. Couple this with even more effort to make it play nice with Greek (my native language), and the switch came naturally.
I'll admit that when I wrote this, I did intend it as both a tribute to my favorite text editor as well as a tongue-in-cheek response to the cult-like following that it has. For me, membership to the pseudo-cult is just another reason why I love Vim.
People will get into the whole verb-noun editing language, which is great, but the biggest and first real world improvement is much simpler:
You don't use your mouse to move the cursor around a document.
After a while you just look at the document and your fingers move and the cursor moves, you can get anywhere in the file in just a few jumps. It's not the same as using a mouse or a touchpad where you need visual feedback to place the cursor in a specific place and the movement is continuous. It feels like it takes less mental processing to do that and it is less distracting while you are concentrating on actual work.
It's hard to explain, and I'm one of those people who using vim, vimperator and vim keybindings in his shell. The only other times I've reached the same levels of muscle memory taking over complex behaviour (besides sports) is when playing video games or driving a car. You concentrate on what you want done and some lower level part of your brain and your hands just takes care of it.
A pointer based system just can't compete in terms of immersion.
I have a feeling I just typed a lot and didn't do any better of a job explaining it.
Explaining nifty Vim backflips is the wrong way to sell Vim. A 15 minute session of `vimtutor` was enough to enlighten me. If I had needed a proficiency in Vim to appreciate Vim, I would've never started.
I think you don't feel it, because vim doesn't save you five minutes, twenty times a week; it saves you 0.75 seconds, eight thousand times a week. Same time savings, but much harder notice the pain before you've solved it.
I never felt it either, back in my TextMate days. But one Thanksgiving holiday week, I told myself, you know there's got to be something to this if all these people I respect swear by it. I decided to use vim-only for two weeks, no matter what, and I'd switch back if I wasn't hooked. I was.
I switched to vim after years of IDE use, and I find it painful to go back to the IDE when I'm working on projects that require it.
The biggest advantage I find in using something like vim or emacs is that you never have to switch between the mouse and the keyboard — in fact its awkward to use the mouse and that makes it difficult to get accustomed to. It allows you to seamlessly transition between code navigation and code writing, and you develop a kind of rythme that I never felt like I achieved with a graphical text editor.
Other nice features are the ability to write custom scripts and repeat actions, but these can generally also be done in other editors. One huge reason I made the switch is I end up writing code on remote machines on occasion, and I can almost always do so in my everyday editor: vim. All my personalization can be transferred over to the remote machine in a single scp command and the experience remains the same no matter where the files live that I'm working on.
For me, it's about the interface. In descending order: intuitive, consistent, modular, comfortable, portable.
Intuitive: most commands resemble natural language, without awkward or arbitrary mappings. For instance:
- w: (forward) word;
- cw: change (forward) word;
- c2w: change 2 (forward) words;
- 2cw: twice change word;
- ciw: change inner word;
There is no intervening translation. For instance, to change a word in mainstream editors, you delete it first, then start entering the new text. In Vim, it's one command: you think "change forward word", you issue the "change forward word" command.
Consistent. For instance, double letters work on lines:
- cc: change line;
- dd: delete line;
- yy: yank line;
and capital letters work till the end of the line:
- C: change till the end of the line;
- D: delete till the end of the line;
- Y: yank till the end of the line (not so in vanilla Vim, but I've remapped it because consistency matters to me).
Modular: you compose commands. For instance, / is the search command and then:
- d/testo: delete until the next occurrence of "testo";
- c/testo: change until the next occurrence of "testo";
- etc.
Comfortable: limited usage of modifier keys. Vim saved me from RSI.
Portable: letters and Shift keys are in the same position on any keyboard, be it on a desktop, a laptop, etc. whilst each laptop manufactures has its own idea about where Control, Alt, Arrows, PageUp and PageDown should be.
I'm sorry, but although I'd agree vim is awesome, there's no way I would call its commands "intuitive." Take 'y', for 'yank.' Would anyone really argue that the word "yank" is a natural way of expressing "copy?" "Yeah mom, just yank and paste that into an e-mail... " And there's nothing inherently intuitive about '/' for searching, unless you're already familiar with unix commands like sed. Or ":" for go to line. Or "x" for delete letter. Or "jkl;" for movement, for that matter. Etc... etc... etc...
A lot of people here have made the point that vim has a steep learning curve that eventually pays off, which, to me implies that intuitiveness is either lacking or besides the point. Still, I agree with your other points. I'm thinking of going back to it to minimize hand strain.
It's not that individual commands are intuitive. Yes, you need to learn the verb for copying is y (and is called yank), the verb for deleting is d. The "intuitive" part comes once you have a basic vocabulary. You can then learn a new action and already "intuitively" know advanced ways to use it.
If I learn the new verb c, which deletes and puts me in insert mode, I already know that I can type c3w to change 3 words, or ci" to change the phrase inside quotation marks.
Because all verbs work on the same set of nouns and adjectives I can intuitively know what many commands do - even though I've never tried them - as long as I understand the parts that make up the command.
I agree that there are some trade-off, but other editors have their trade-offs as well. IMO, Vim's trade-offs are acceptable. Actually, / for search is traditional beyond Unix: Opera and Firefox understand it. And ? (which is Shift + /) searches in the opposite direction (a smart trade-off). x, while not literal, is descriptive: think about drawing an x over a character to "delete" it. hjkl, while not mnemonic, are so often used that that it is advantageous having them there and muscle memory develops fast. Goto line is also <line number>G, more mnemonic.
I think the steep learning curve comes from the need to learn a richer and more precise way of editing, while you may be used to get by with a sloppy one. I had a similar experience when I switched to the Dvorak keyboard: I learned for the first time how to touch-type, while the Qwerty grew on me from hunt-and-peck.
Since you are considering about going back, here are some useful custom mappings of mine:
- swap p and P;
- map Space as PageDown;
- map Shift + Space as PageUp;
The last two mirror the way most document-displaying applications work. Generally, don't think twice about remapping some commands either to correct historical quirks of Vim or make it behave consistently with other applications you may be using, hence lowering your memory load.
Change forward word is in a mainstream editor: [Shift]+[Ctrl]+[Right]
Change line: Home, [Shift]+[End]
...and so on...
Moreover you forgot to mention that you always need to switch modes...
Mainstream editors are pretty efficient, unfortunately in the UNIX World there are hardly any good ones. The best ones I can think of are Eclipse and gedit.
Unfortunately there is no Notepad++-like thing on UNIX. (And Kate just became messy and buggy when KDE4 came out.)
BTW: Has any vim fan ever used the refactoring feature in Eclipse? Or edited Code during runtime using the Graphical Debugger? I doubt it... ;-)
> Main stream editors work differently...
> Change forward word is in a mainstream editor: [Shift]+[Ctrl]+[Right]
I stand corrected.
> Change line: Home, [Shift]+[End]
Here there is a translation at work: the editor lacks an atomic "change line" command, so users resort to "move cursor to the beginning of line, then select text up to the end of the line", which is something you could do in Vim, too, if you wanted.
> Moreover you forgot to mention that you always need to switch modes...
I don't understand. Do you mean you have to switch between Insert and Normal mode? If so, this is where newbies - including me some years ago - make their bigger mistake: you don't linger in Insert mode, you hit Esc as soon as you end entering text. Either you are typing text, or you are in Normal mode. This is the reason you need the Esc key as easily accessible as possible. On my keyboard, it is on the Caps Lock key. And : is unshifted.
> BTW: Has any vim fan ever used the refactoring feature in Eclipse? Or edited Code during runtime using the Graphical Debugger? I doubt it... ;-)
I'm with you on this. Still, people confuse Vi-style editing with either Vim or other Vi clones. Vi-style editing is neither Vi nor Vim nor Elvis nor [name an editor]. I used Eclipse and Visual Studio, yes, and guess what: I had Vi-style-editing plugins on both. What people call "the best of both worlds".
EDIT: Vi-style editing rocks at editing text, which is a subset - or not the same - of editing code. A user editing code with a mainstream editor offering powerful code-completion and refactoring facilities may have at her disposal a more powerful tool than a user editing code with a Vi-style editor lacking such facilities.
Sure, vi-style editing is something I also find awesome. The key combinations are really smart and I love the shortcuts D and dd, or search through a file with n and N.
And yes, vi(m) is inferior to much less sophisticated editors when it comes to juggling large chunks of code. Or maybe not...
Anyways, now that I have a Macbook, I need to learn vim because it lacks all the cool keys you have on a PC keyboard :D At least I'm now using at nearly as productively as gedit or the like. (On average)
BTW: This caps-look trick is awesome, I'll set it up now!
It's mainly about muscle memory. If you're using Sublime, emacs, TextMate, or any other "real" text editor then you're fine.
I don't have to think about how to perform most tasks in vim. My fingers just execute what my brain wants to see happen. That doesn't mean that vim is the greatest thing ever, just that I'm used to it and it's fast enough to get the job done.
One concrete benefit to vim is that it works very well over crappy network connections, and it's installed on most every Linux system you're going to touch.
I don't see what is bad about having religious or cult like feelings around a tool. This sort of thing already exists for various programming languages. There wouldn't be any of the advancements we consider standard today in most high level programming languages if it weren't for LISP. If people weren't fanatics about homoiconic and functional features in their languages, we would be in a much worse place. Fortunately languages gaining popularity nowadays resemble LISP much more than they do FORTRAN. This probably wouldn't be the case if there weren't very smart people evangelizing the benefits of LISP over the past half a century.
For me it's the insert/command modes. The command mode allows me to do all sorts of things without contorting my fingers with combination commands, which is something that annoyed me about emacs. Also makes the macro recording easy for me to understand.
Not only that, it's also a point of view on computers/computing. Automate everything. Kinda like lisp macros. When you refine these manners you gain reduce workload, boilerplate, and focus on fundamental issues.
It is in a sense. For some reason, vi[m] gets more play on this site, but pretty everything you can say about vim also applies to emacs, with one critical different (and the reason I switched): vi* is modal editing. Every report I've seen on the subject says that modal editing is a no-no. As a vi user, after seeing this for the first time I realized that, indeed, it had happened to me several times that I thought I was in text mode but was actually in command mode.... oops. I type 80+wpm so by the time realized the mistake I had trashed my file beyond recognition and had overran the undo buffer. There was nothing to do but lose all changes and start again.
This can't happen in emacs because editing isn't modal (though commands are very contextual). vi* is certainly easier on the hands than all the cording but getting rid of modal editing means no more wasting time when your brain is out of sync with the editor.
Having said all that, I'd still pick a nice IDE over either of them, since the IDE understands the language I'm editing and can e.g. change from simple minded "mass edits" to actual refactoring.
It's all about building up a maximally powerful keyboard text editor from potent primitives. When it comes to out-of-the-box editors, nothing gives more bang for the buck on arbitrary text files than vim.
That's not to say it's the best overall. If you like to customize your environment, emacs is better. If you like tight OS integration and advanced GUI features, many editors are better. If you want the most productive environment for a specific programming language then some IDE is probably better.
But when it comes to raw keyboard editing, why is vim so powerful?
Well, it starts with normal vs insert mode. Because insertion is a specific mode, it means every single key on the keyboard is available for direct editing commands. Of course you can have modifier commands as well, but that's nowhere near the convenience and efficiency of plain typing.
So right off the bat you start with an order of magnitude more command possibilities in an easier to access position (chordless). The commands of the basic keys are designed to be a solid fundamental set of building blocks for all common editing tasks, and they are assigned mnemonically.
The power of the fundamental commands is then multiplied by the vim grammar, whereby commands are applied to objects, which again are a terse and mnemonic description of some chunk of the file.
In practice this means that very short unmodified alphanumeric strings you type can produce powerful changes. It's not just keystroke-counting, it's the fact that these keystrokes are also a meaningful language that makes sense mnemonically, not just through muscle memory. The more you practice, the more different ways you start to see to effect a given change. As you become more proficient, you can do more and more with a single command.
This is important because commands are atomic, and you can repeat the previous command by hitting '.'. The power of this isn't really apparent until you grok the breadth of things a single vim command can do, but have you ever wanted to do a regexp search and replace and spent a long time crafting it and still had to step through it because you were afraid it might screw something up? With vim commands you can often times use simple command repetition to avoid complex regexps ('n.n.n.n.n.n.n.n.' to find next/repeat command).
Sometimes I'm surprised by the mileage I get out of that, but it's really the tip of the iceberg. Because you also have macros, which are just recorded sequences of commands. But the cool part is that commands are made up mostly of regular characters, so the macros look like plaintext, and vim treats them that way as well. Vim has 26 clipboards called registers, and these registers function both as text storage and executable macro space. Meaning you can record a macro, and then paste it into a buffer, and tweak it via normal text editing, and then pull it back in and run it. Because the commands are so simple and mnemonic, it's actually astonishingly easy to do this. Once you are comfortable with it, you find yourself recording, running and dropping macros in less than the time it takes to write a single regexp. I have spacebar bound to a specific quick-macro slot so I can record and then hold down space to mass-apply a macro (my key repeat-rate is maxed as well :), this lets me do the types of things in seconds that previously would have me busting out the sed/awk book. It's very hard to communicate the impact this has on your editing workflows to someone who doesn't get it. It's sort of like a git user telling a svn user why easy branching is so awesome, the svn user just doesn't get it because they've already convinced themselves they don't need branches precisely because they are so hard to use.
In short, the vim advantage is about powerful editing primitives and easy ways to compose them. There are certainly many great editing ideas that are not in vim, but in terms of the fundamentals for keyboard editing, it's hard to imagine anything better.
Thanks, I really appreciate how you broke it down. One thing that I was wondering about that you don't address directly is: how do you compile/execute your code? Do you have to exit vim every time, run your compile/execute command, then relaunch vim? Sorry if this is really specific.
In vim, you can execute shell commands straight from the main command mode (the default mode starts in). For a C project, compiling might be as simple as typing:
:!make
Then run with:
:!./myprog
In both cases, the output will be viewable in a temporary window. You can also pipe the output of a shell command into a vim buffer (aka file) by prefixing you command with "r":
:r !./myprog
This takes all the output from ./myprog and lets you view/edit it in vim.
For longer and more interactive shell interactions you can use job control, if your shell supports job control (bash, zsh and pretty much every reasonable user shell in existence). Ctrl-Z will suspend vim and drop you back into your shell, you can then unsuspend vim by running "fg" (at least in bash).
Alternatively, my own work flow consists of using tmux to have a split screen terminal, Vim left, REPL right.
the most common example is moving up or down a row. most editors you have to reach for the arrow keys or the mouse. in vim, you use j key for down, k key for up. the most commonly used functions are near the home row.
That's why I use Evil (http://emacswiki.org/emacs/Evil). I get all the programmability benefits of Emacs with the more powerful editing model of Vim. In fact, the whole of Evil is actually greater than the sum of its parts, since it provides a high level interface for extending the Vim editing model itself in Emacs Lisp. Creating new text objects, for example, becomes trivial.
So what kind of stuff do you program inside of it? What kinds of problems do you solve?
I mean, I've never really felt the need to program an add-on to text editor. I download syntax highlighting packages, and there are common macros like "remove trailing whitespace" already installed. Keyboard shortcuts can be changed in lots of editors and OS's. In the past, I've definitely been upset that a particular editor didn't support a particular feature, but by now they've progressed enough that I don't really feel that anymore.
Looking through my .emacs for things I, personally, have written:
- A little hook to use an external Python program (cheating, I know) to look up the definition of the word under the cursor in the OS X dictionary.
- Several customizations for org-mode, which I use for anything where I want to make an outline, including and especially to-do lists.
- I actually still have some code to do "smart tabs" (http://www.emacswiki.org/SmartTabs) for some modes, though that's now probably obsolete if I would only configure up the code mentioned in that list for C modes. (I'm already using it for e.g. Python code.)
- Some configuration for LaTeX editing, like packages AUCTeX doesn't know about, converting words/phrases into \gls (glossary) references.
I actually have less custom stuff in .emacs than I thought. Having a programmable editor does mean that it's relatively easy for other people to write some really useful stuff which I then get to use. I have some local modifications to other people's packages which I don't have time to enumerate right now.
I can't answer your whole question or we'll be here all day. Here's one important example, which has the advantage of applying in vim as well as emacs:
"Common" macros are the least interesting. The most interesting macros are the ones with no name, the one-time ones that you build on the fly. You have a file with ten thousand lines of:
foo.rb
bar.rb
baz.rb
…
… [9997 more lines like these]
and you need to turn the file into something like this:
// Run the foo command
def foo()
end
// Run the bar command
def bar()
end
// Run the baz command
def baz()
end
… [9997 more blocks like these ]
That's 56 keystrokes in emacs: You record a macro that transforms one line appropriately, then execute it 9999 more times, all on the fly in about twenty seconds.
2. `command + shift + L` to split the multi-line selection into multiple single line selections (one curser at the end of each line)
3. `delete delete delete` to get rid of ".rb" on each line
4. `command + shift + ←` to select the identifier
5. `command + C` to copy each identifying word on each line (!!!!)
6. `←` to get to the beginning of the line
7. Type "// Run the "
8. `command + V` to paste each identifier on each line correctly (!!!!)
9. Type " command\ndef "
10. `command + →` to go past the identifier already there
11. Type "()\nend\n"
Also took about twenty seconds. This multi curser thing has been completely redefining how I mass edit code - it's quite fantastic, and as far as I know ST2 is the only editor that does it this wonderfully.
Multiple carots, the minimap and ST2 picking your indentation strategy automatically by looking at the file (I work with badly formatted legacy code a bit, there is no project-level strategy that applies) are the three reasons I bought it.
Some of my coworkers use sublime, and have been very excited about it. I used vim for several years and use emacs now, so probably a hard sell. Still, I get curious when people are Really Excited about other editors (because there may be ideas worth stealing and adding to emacs ;) ).
What's the "minimap", the scrollbar that is a shrunken version of the document? The "multiple carets" feature seems handy. Are there any other standout features, compared to vim or emacs (not, say, TextMate)?
Yes, the minimap is what you guessed it was. Other ST features that Vim/Emacs don’t have (by default, at least):
• You can use proportional fonts (I use Verdana)
• The interface chrome is graphical, not text in a grid. This allows nice details such as a drop-shadow from the minimap when it covers the text and proportional fonts in the file tree’s filenames.
• On a Mac with smooth scrolling, you can scroll smoothly pixel-by-pixel, instead of choppily line-by-line.
• You can easily rename a variable, by using Command-D repeatedly to select the instances of the names inside multiple carets. But I usually forget to do this until after I’ve already renamed just one instance of the variable, and then I can’t select the other instances without undoing that edit first, so it’s not that useful.
• It uses Python as its scripting language, so you can use Python libraries easily, and don’t have to learn an editor-specific language. Similarly, it uses JSON for settings.
But Sublime Text doesn’t have nearly as many editing shortcuts by default as Vim. For instance, there isn’t any hot-key to select inside a quoted string – Expand Selection to Scope is the closest, but it’s hard to predict what it will do and so it isn’t very reliable. You can enable Vintage mode, which emulates many Vim key-bindings and thus gives you access to that power. That mode has a few small problems – the biggest one for me is that the Esc shortcut to exit the current mode sometimes conflicts with the Esc shortcut to remove extra carets so you have just one.
It’s too bad Sublime Text isn’t open source. Its plugin API doesn’t allow setting tabstops manually, which I would like so I could write a plugin implementing true elastic tabstops. Since I can’t implement it myself, I have no option but to beg the developer to implement that and wait.
Vim uses what my terminal uses. No ideas if my terminal(terminator) allows proportional fonts, but I always have used monospaced. Proportional looks ugly to me when it comes to code.
> The interface chrome is graphical, not text in a grid. This allows nice details such as a drop-shadow from the minimap when it covers the text and proportional fonts in the file tree’s filenames.
Drop shadows? Umm, no thanks.
> On a Mac with smooth scrolling, you can scroll smoothly pixel-by-pixel, instead of choppily line-by-line.
Either I search for what I am looking for, jump to definition, or move screen by screen. I don't scroll - at all. If I did, I am reading lines of code, not rows of pixels.
> You can easily rename a variable,
I don't use ST and can't exactly understand what is unique here, but I am pretty sure renaming something is something vim is very good at. You want to limit the scope, select visually and run :s on it.
> It uses Python as its scripting language, so you can use Python libraries easily, and don’t have to learn an editor-specific language. Similarly, it uses JSON for settings.
Python is much more mainstream than vimscript, yes, but there are still people who don't know python and don't want to learn it. Learning python for them isn't very different from learning vimscript.
>> It uses Python as its scripting language, so you can use Python libraries easily, and don’t have to learn an editor-specific language. Similarly, it uses JSON for settings.
>Python is much more mainstream than vimscript, yes, but there are still people who don't know python and don't want to learn it. Learning python for them isn't very different from learning vimscript.
You've quite obviously never tried to code anything in vimscript, have an axe to grind with Python, or are Tim Pope. Vimscript is a horrible abomination that's painful to do just about anything in. Python is far, far superior.
(Vim lover and Ruby guy here, but I'd pick just about any language over vimscript)
> You've quite obviously never tried to code anything in vimscript, have an axe to grind with Python, or are Tim Pope
All your claims are preposterous. I have coded in Vimscript, I use Python and have no axe to grind; and I am not Tim Pope(duh).
> Vimscript is a horrible abomination that's painful to do just about anything in. Python is far, far superior.
I don't remember claiming Python is inferior to vimscript. Have you actually used vimscript, or are you speaking from superficial experience? Vimscript is not a general purpose programming language, but does the job of extending vim fine.
I was in middle of writing a small function which syncs up nerdtree highlighting with bufexplorer buffer switch(came here to take a break). Here is what it looks like:
function! ChangeBuffer()
if bufwinnr(t:NERDTreeBufName) != -1
exe "normal! :NERDTreeFind\<cr>\<c-w>\<c-w>"
endif
endfunction
let g:BufExplorerFuncRef = function('ChangeBuffer')
The amount of general purpose programming involved is minimal.
1. BufExplorer provides a hook which takes a function reference. A variable assignment.
2. If nerdtree is active(simple function call), call the command to find the current buffer in nerdtree(vim specific normal command execution), and switch back to editing pane(again normal mode command)
A good part of tasks make use of exe, nnoremap, iabbrev etc; and vimscript is powerful and pleasant enough for the rest(lists, dicts, simulated objects, variable namespacing...). It has it's quirks, but so has many mainstream languages - you know about the quirks when you are using the language, and avoid them.
> Vimscript is not a general purpose programming language, but does the job of extending vim fine.
If you have the chance to choose to invest time in learning either a language to extend your editor or a general purpose language which you can use to extend your editor, which would be your best bet?
> If you have the chance to choose to invest time in learning either a language to extend your editor or a general purpose language which you can use to extend your editor, which would be your best bet?
It's not as uni-dimensional. Sure if I don't know either of Vimscript or Python, I will see learning Python as more beneficial. But the main reason vim chose vimscript(or emacs chose elisp) is you have a interpreter built in the editor itself. If all your extensions are vimscript, all you need to configure vim on a new box is to copy your .vimrc and .vim folder and everything will work - no package installation, no external dependencies.
If you already know vim and some programming, you can start writing basic vimscript in an hour or two. The more complicated ones(the ones Time Pope writes) are going to take a lot of time, irrespective of your language choice.
Also, vim extensions can be written in Python as well, but it requires that your vim has python support. How does ST does it? Does it bundle python?
The problem with application-specific extension languages is that they may start underpowered and ad-hoc, whilst general purpose languages have already proved their worth and done so in several domains.
Vim designers tried to reinvent the wheel and failed to implement a decent extension language from the beginning, whilst GNU Emacs designers didn't reinvent the wheel and adapted a mainstream general purpose language to their needs. So, while Vim users were busy wrestling with the limitations of their extension language and coping by adding ad-hoc extensions here and there, Emacs users were busy churning out macros and packages for their editor.
The main reason I have chosen Emacs as my editor is that I get more bang for the buck. Emacs can emulate Vim, whilst the opposite is not true, as the folks who tried to port SLIME (a powerful package to code in Common Lisp) realized.
We agree that an embedded extension language is the way to go. And whatever mainstream language you might choose, it could go out of fashion after a while anyway.
> The problem with application-specific extension languages is that they may start underpowered and ad-hoc, whilst general purpose languages have already proved their worth and done so in several domains.
The embedded language has to be small, easy to learn, and most importantly, it should serve the purpose of extension. If it can serve other domains as well, that isn't really relevant as far as the editor is the concerned. Now vimscript doesn't do threading or evented io or thousands of other things - it isn't meant to do any of those.
> whilst GNU Emacs designers didn't reinvent the wheel and adapted a mainstream general purpose language to their needs.
Lisp can hardly be considered a mainstream, general purpose language(may be it was at the time they were adding it to emacs).
The point of vimscript wasn't to win any language design awards, but to have a langauge with a very small core which can be used for configuration and extension. As far as quirks go, all languages have quirks. PHP and JS probably have more quirks than Vimscript. Since you are so critical of Vimscript, care to cite me the pain-points which stop you from writing decent extensions in vimscript? There are a variety of scenarios in which vimscript implementation is much more simpler to an elisp implementation.
viw<leader>g: Visually select a word, then grep for it.
<leader>g4w: Grep for the next four words.
<leader>gt;: Grep until semicolon.
<leader>gi[: Grep inside square brackets.
Are you saying elisp implementation of the same concept(provide me a way to grep for arbitrary grep for words, and no, spawning a shell isn't the same thing) is going to be shorter or simpler?
> While Vim users were busy wrestling with the limitations of their extension language
I would really like examples where the limitation of vimscript is outshined by elsip. Check my snippet above - vimscript is written specifically for extending vim, and it does a good job.
> Emacs users were busy churning out macros and packages for their editor.
I find recording macros in vim simpler than emacs. By default. Vim doesn't have a save macro functionality, but either you use an extension to do that, or manually save the macro.
> The main reason I have chosen Emacs as my editor is that I get more bang for the buck.
It mostly boils down to this "I get more bang for the buck". There is not much objectiveness when it comes to vim and emacs. You enjoy emacs, I enjoy vim.
> Emacs can emulate Vim,
A very limited form of vim navigation.
> whilst the opposite is not true, as the folks who tried to port SLIME (a powerful package to code in Common Lisp) realized.
I didn't know about an attempt to port slime to vim, because you will have to fight vim for it, and vim won't yield. Vim doesn't do async processes and per the developers, it's not going to, period. So, no shells in the vim(you can folk a shell but then the editor goes away and when you exit the shell, you are back in the editor), no debugger, no slime...It's a conscious design decision. If you don't like it, use something else.
> Now vimscript doesn't do threading or evented io or thousands of other things - it isn't meant to do any of those.
Neither does Emacs Lisp. But whilst Emacs Lisp started as a simplification of a battle-tested general-purpose language, Vim Script started as a hack and continued that way, with further functions being added on a "as-needed" basis.
> As far as quirks go, all languages have quirks. PHP and JS probably have more quirks than Vimscript.
Effective analogy. PHP and Javascript started as hacks as well, they weren't meant to do much at first, and shared the same fate of Vim Script. The reason people put up with PHP and Javascript is that they had or have no alternative. And if there were no modal editor other than Vim, I myself would put up with Vim Script as well.
> Since you are so critical of Vimscript, care to cite me the pain-points which stop you from writing decent extensions in vimscript? There are a variety of scenarios in which vimscript implementation is much more simpler to an elisp implementation.
This is what we could name a "Perl fallacy": Perl scripts can be much shorter than scripts in other languages, but the former are more of a PITA to write.
However, I can cite a pain point: I can't write stand-alone applications with Vim Script. You may say this does not matter, because we are talking about extension languages here, but my view is different (and this was one of the original objections of mine). Why learn shell scripting (or something similar), different command-line text processing tools with their quirks when you can learn one framework well and use it for everything?
Evidence shows that Emacs' packages can go beyond Vim's, even when we factor out the kitchen-sink approach of Emacs. For instance, whilst Emacs programming packages parse - thus understand - code while perform syntax-highlighting, Vim's packages rely on regexps, thus messing syntax-highlighting when the syntax of a language is not quirky.
I don't understand your grep example, but providing an Emacs Lisp implementation would be pointless anyway. Languages are not to be judged so much by the terseness of their programs in specific cases as by their consistency and easiness of reading in general cases. Vim Script code is difficult to read because uses keyboard macros heavily, and suffers from accumulated cruft, where equivalent Emacs code would use named procedures with meaningful and consisten names.
> I find recording macros in vim simpler than emacs.
By "macro" I meant procedures, not keyboard macros.
> It mostly boils down to this "I get more bang for the buck". There is not much objectiveness when it comes to vim and emacs. You enjoy emacs, I enjoy vim.
I wish this were the case, but it is not. There is objectiveness. By learning Emacs, you are learning how to use a tool which is much more consistent and flexible. Since the learning effort is comparable, why would you choose otherwise? Concentrated effort on worthwhile tasks leads to higher returns.
>> Emacs can emulate Vim,
> A very limited form of vim navigation.
Current Emacs packages emulate Vim as far as it is useful. Cloning Vim wouldn't make sense as there are equivalent Emacs facilities.
> I didn't know about an attempt to port slime to vim, because you will have to fight vim for it, and vim won't yield. Vim doesn't do async processes and per the developers, it's not going to, period. So, no shells in the vim(you can folk a shell but then the editor goes away and when you exit the shell, you are back in the editor), no debugger, no slime...It's a conscious design decision. If you don't like it, use something else.
I acknowledge that the kitchen-sink approach of Emacs has lead to aberrations (like Gnus), at which Vim users laugh, but the superiority of Emacs would persist even if you stripped out facilities that Vim doesn't offer by design choice.
You know what, Irahul? I like Vim. Really. I have studied many Vim books and lurked on Vim Wiki and Vim enthusiast's blogs. I have never learned how to use Emacs' default editor properly, as I switched to a Vim emulator early. Emacs has an effective editor implementation, Vim has an effective editing model. That's what is objective. Thankfully, we don't have to choose anymore.
> Vim Script started as a hack and continued that way, with further functions being added on a "as-needed" basis.
Why shouldn't adding functions on "as-needed" basis be the case? No body can see what might be needed in the future. All programming languages evolve, so does vimscript. Other languages evolve in favor of language design and libraries, vimscript adds things which are needed.
> This is what we could name a "Perl fallacy": Perl scripts can be much shorter than scripts in other languages, but the former are more of a PITA to write.
"Perl fallacy" isn't something accepted and proved. It's mostly Python and Ruby folks bashing perl. I have written substantial amount of perl, python, ruby(and lots others, but these 3 are almost interchangeable) and I find perl easy to read and write.
> I can't write stand-alone applications with Vim Script. You may say this does not matter, because we are talking about extension languages here, but my view is different (and this was one of the original objections of mine).
You said it yourself, and I will repeat it. Vimscript exists only to extend vim, and everything that's added to it is added with that in mind. Anything that helps vimscript better at extending vim is good, anything else is not bad but is irrelevant.
> Why learn shell scripting (or something similar), different command-line text processing tools with their quirks when you can learn one framework well and use it for everything?
Well then there has got to be a reason we don't have this magical framework yet which we can use for everything. May be "right tool for the job"?
> Evidence shows that Emacs' packages can go beyond Vim's
Would love to look at some of that evidence. Apart from async stuff(debuggers, slime etc), I don't think that should be the case. I have looked at Tim Pope's and scrooloose's vim plugins, and have reasonable experience writing vimscript and looking at others' work to believe vimscript is powerful enough for the job.
> For instance, whilst Emacs programming packages parse - thus understand - code while perform syntax-highlighting, Vim's packages rely on regexps, thus messing syntax-highlighting when the syntax of a language is not quirky.
Look at the syntax highlighting section 28-107 and show me where it's parsing go code. I don't know what you meant by "parse and understand code", but a parser for a non-toy language isn't something you write in elisp for a syntax highlighter.
Syntax highlighters more or less work the same way. You have a colorscheme which says keywords are blue, and then the highlighter tells what is to be considered a keyword. Now keywords is cakewalk - a static list of tokens, and in most editors, if you name your variable `class`, it gets the same highlighting as the keyword class. Regions(multi-line comments, multi-line strings, function arguments falling down to next line) are a bit problematic, but editors have hooks for it.
# Well, thank's slosh again.
# http://learnvimscriptthehardway.stevelosh.com/chapters/47.html
syntax region potionString start=/\v"/ skip=/\v\\./ end=/\v"/
highlight link potionString String
Now,
"She said:
\"Vimscript is tricky, but useful\"!".
will highlight as string just fine.
> Vim Script code is difficult to read because uses keyboard macros heavily, and suffers from accumulated cruft, where equivalent Emacs code would use named procedures with meaningful and consisten names.
It is difficult to read to whom? Unless it is difficult to read to someone who knows vimscript, it doesn't matter.
You are missing the point. When I am in the editor, and I need to copy 2 words, I do y2w. Making it a function call in vimscript isn't beneficial to me at all. What exactly would I gain if vimscript, instead of this:
> Why shouldn't adding functions on "as-needed" basis be the case? No body can see what might be needed in the future. All programming languages evolve, so does vimscript. Other languages evolve in favor of language design and libraries, vimscript adds things which are needed.
When you add things when needed instead of thinking them through beforehand, you have two choices:
- forsaking backward compatibility, thus breaking existing libraries;
- striving for backward compatibility, thus ending up with an inconsistent framework and language quirks.
Examples are not rare:
- Perl and its flattened lists and many other quirks;
- PHP;
- Python warts;
- C++ with weird syntax which is legit;
- etc.
> It's mostly Python and Ruby folks bashing perl. I have written substantial amount of perl, python, ruby(and lots others, but these 3 are almost interchangeable) and I find perl easy to read and write.
Props, man. You must have a big brain, if you feel that both Python and Perl have almost the same cognitive load. I considered myself to be a sharp blade at programming C++, yet I have always found it to be a taxing task. Good for you. I'm not joking.
> Vimscript exists only to extend vim, and everything that's added to it is added with that in mind. Anything that helps vimscript better at extending vim is good, anything else is not bad but is irrelevant.
But you can't deny that an extension language which goes beyond its editor comes with a bonus.
> Well then there has got to be a reason we don't have this magical framework yet which we can use for everything. May be "right tool for the job"?
Such magical framework exists. Its name is GNU Emacs. Sometimes its magic has been overplayed, but still...
>> Evidence shows that Emacs' packages can go beyond Vim's
> Would love to look at some of that evidence. Apart from async stuff(debuggers, slime etc), I don't think that should be the case. I have looked at Tim Pope's and scrooloose's vim plugins, and have reasonable experience writing vimscript and looking at others' work to believe vimscript is powerful enough for the job.
What about:
- Gnus, RM, VM, Vanderlust, Meow: mail readers (IMO an aberration, but it proves the point);
- Eshell (Emacs shell, written in Emacs Lisp);
- Dired, Sunrise Commander: file browsers;
None of these packages uses functionality which is alien to Vim, except a more expressive extension language and a richer library.
> http://code.google.com/p/go/source/browse/misc/emacs/go-mode....
>
> Look at the syntax highlighting section 28-107 and show me where it's parsing go code. I don't know what you meant by "parse and understand code", but a parser for a non-toy language isn't something you write in elisp for a syntax highlighter.
That's a basic Emacs mode. Throw some Perl code to both CPerl in Emacs and to Vim and see which of the two copes better (with Perl you can't do better than coping).
>> Vim Script code is difficult to read because uses keyboard macros heavily, and suffers from accumulated cruft, where equivalent Emacs code would use named procedures with meaningful and consisten names.
> It is difficult to read to whom? Unless it is difficult to read to someone who knows vimscript, it doesn't matter.
It is difficult to read to everyone. There is a reason for we using named variables instead of codes of registers nowadays.
> You are missing the point. When I am in the editor, and I need to copy 2 words, I do y2w. Making it a function call in vimscript isn't beneficial to me at all.
What happens if the reader has remapped such keys on his Vim? I don't know, but either your code will break or the user will risk misunderstanding it. Maybe Vim doesn't offer you any facility to easily convert keyboard macros to named procedures, therefore you have to resort to hardcode such macros.
What if the reader uses a subset of Vim's commands and doesn't recognize the hard-coded macro at first sight? She has to decrypt it. In Emacs Lisp, you always have at least clue about what a command does.
>> Unless you have objective proof of "emacs being much more consistent and flexible(where, how)" it's not objective at all.
That Emacs is more flexible, I have proved. Documenting why Emacs is more consistent would be more work than I'm willing to put into a comment here. Since I have studied both Vim and Emacs and read experiences of users who have switched from one to the other, both ways, I believe I have a good idea about how they stack one against the other. I accept that you don't share my opinion.
Bad bad bad, if you are investing time in mastering a tool which could disappear tomorrow, or take a direction you don't like. This is one of the strongest reasons I chose GNU Emacs as my editor. I remember how burned I was when Visual Studio moved from VBScript to .NET as its macro language. All the time I had invested in learning its macro system and in writing macros went down the drain. Never again.
"Its plugin API doesn’t allow setting tabstops manually, which I would like so I could write a plugin implementing true elastic tabstops."
Elastic tabstops are awesome. This is a feature I do miss in Emacs.
To be completely fair, it's not like they are going to remotely delete it or anything, the current version which I like functions, and has no glaring bugs, and will continue to function.
And if I did use emacs, and somehow it changed in a way that I hated, I really doubt I'd have the time to fix it. Work isn't going to pay me to sit around and write my own text editor.
I see your point. One day I'm going to write a guide to choosing your editor, or your trusty tools, for that matter. There are further advantages in choosing an open-source established editor.
It all boils down to a trade-off. As long as you don't invest too much time into learning a tool, you don't mind losing your investment. Recently I have switched to Opera as my default browser. I couldn't stand Firefox anymore, Chrome didn't suit me. Opera is proprietary and closed-source, but then I'm not going to dig too much into its internals.
Ok. I can see many of those being possible advantages, depending on taste. I find the option of a terminal (rather than a graphical interface) to be a major asset, because then it works with ssh* .
Also, all the people I know using ST are ex-vimmers, and use its vim emulation mode. A data point, I suppose.
And yes, agreed on the open-source-ness, though commercial support does have its advantages.
* I know you can do X forwarding and so on, but, eh.
This looks unwieldy but it's all done interactively. (also if you mess up and you want to rework the macro you can paste it out with "rp to paste the r register rework it and then put it back into another register. 0"ry$ (start at column 0 then into r register r yank to end of line)
As a heavy user of regex one liners, I agree in this case, but as a heavy user of vim, there are lots of times when a macro can be recorded and run over a file long before a proper regex can be constructed, particularly in multi line settings, or those things that would require heavily nested backrefs.
Then enter this sequence of keystrokes[1]:
0veyO// Run the ^R" command<esc>j0f.C()<cr>end<cr><esc>
Then exit macro recording with:
q
Then enter the command:
:g/.rb$/ norm @a
to run the macro on every line ending with .rb (allowing comments in the input, just because (of course it would be nice to make that regex in :g look for "lines that start with comments" and ignore them explicitly)).
If I counted right, thats 57 keystrokes, and I might have been slightly inefficient in my usage, of course, if that one keystroke is part of a command my fingers just do, there is no effective difference :)
[1] I know it was exactly that sequence because I just pasted the macro buffer, which of course can then be edited, saved back to the buffer and run in edited form.
I'm an intermediate user of vim but the filtering the macros to only run on those lines is a great tip! I did it a bit different but we had a similar idea.
I probably define ad-hoc macros 10-15 times a day These are for tiny things that save me a minute or two each time I use one. More than the time savings, though, is the sanity savings. I've it's rare now that I do any sort of repetitive editing task.
Also, you don't have to actually program the editor yourself to reap the benefits of a programmable editor. Let's be honest, most modern editors have mostly overlapping functionality. However, one of the benefits of emacs being programmable is that it's self documenting. I can find out how to capitalize a word problematically without having to go to google by using `M-x apropos RET capitalize RET`.
A mini calculator function, lots of snippets, some saved macros etc.
It's not about changing keyboard shortcuts. It implies you can only remap what already exists. It's about giving you infinite canvas to paint on. This isn't unique to Vim. I am just saying having the capability to do so is important.
The thing is once you can code in emacs, and even when you can use the keyboard macro utility, you constantly find little time saving ways to use it. At first though they're not even time saving, they take longer. Anyhow some examples:
I have a function for my work log which gets the date, figures out the previous Monday's date and dumps a formatted weekly log for me to fill out.
I wrote an entire budget tracking application which generates a forecast and dumps it to a csv file
Wrote a utility to mark and optionally delete duplicate files in a dired buffer
Convert a windows path name to a cygwin one
Functions to add local sales tax and remove local sales tax, same for tips.
Perforce source control, helpers to do blame functionality and other stuff that benefits from pulling Perforce output into a buffer
The most used feature would be keyboard macros which are endlessly useful for any repetitive editing task, which can show up unexpectedly at any point of the day
Occasionally have to write throw away custom code to create some boiler plate code, such as turn the API documentation for some errors into a C++ array of structures that can be manipulated in code
"Keyboard shortcuts can be changed in lots of editors and OS's."
Yes, but you can't change the editing model as easily, e.g. converting a modeless editor in a modal one just by changing a few shortcuts.
My take is that there are two camps: people who adapt themselves to the tools they use and people who try to adapt their tools to their ways and their ever-changing view of the world. The former want the tool to help them to get things done, the latter want the tool to help them to get things done their own way. The former look at tools as tools, the latter look at tools as extensions of themselves.
Restarting a program (in various profiles) for tight dev cycles; running unit-tests appropriate to the file I'm currently looking at; using REPLs (Redis, etc); publishing stuff to servers; hacking games which emacs ships with; going through a file and rolling increment certain numbers; and so on.
I used emacs for about 6 months, and just recently switched to vim to see what I think. It's been pretty subtle so far; close enough that I don't know how much the choice matters.
Not to detract from your point, which was similar to my intro to Unix, but I've always preferred 'man -k' to apropos, because it means remembering only one command plus it is slightly less typing.
$ man apropos
apropos searches a set of database files containing
short descriptions of system commands for keywords and
displays the result on the standard output.
It answers the question "I wonder how to do [this English word]."
For example: "I wonder how I copy a file."
$ apropos copy
Dumps out all of the matching entries from the man pages for the word "copy". If you just wanted general commands, as opposed to library functions, and assuming your system organizes man page sections in the typical manner, you can filter it down with:
$ apropos copy | grep "(1)"
cp (1) - copy files and directories
cpio (1) - copy files to and from archives
Also, it doesn't even make you that much more productive. I love it to bits and use it exclusively, but it's just a bit faster, it's not going to reduce the time it takes you to actually think about the things you have to write.
I agree. The most utility I get out of VIM is quick formatting. I'm very particular on how my code looks, (I want to make things as painless as possible for the next guy), and navigating code in normal mode is much faster than anything I could do with a mouse. As far as writing code goes, typing 120wpm makes me fast, not VIM. As far as thinking goes, Jarnal and a Wacom tablet help me do that, not VIM.
I think that's something we as a community forget. It's ok to feel proud of being good with your tools. It is fun. As long as we don't turn it into a "holier than thou" situation, it's neat to have an editor that you have such mastery over that you can control blocks of text with keystrokes.
Note: I don't quite have it yet myself. I'm been using vim for about 6 months (with only 2-3 of active use) and I'm actually right on that cusp he mentions--where you are searching less and less, and only for more powerful and obscure commands, and things are just starting to all become extremely useful. It's beautiful.
I like to remind people that the flipside of a steep learning curve is a high payoff function. If you can exhaust a tool's potential in a day, or a week, or a month, it really doesn't have much to offer you.
i think it's not even so much about the learning curve, it's about the sheer amount of leverage the skills get you. it's very similar to the way chefs are chuffed about their knife skills - all of a sudden you're doing so much with so little effort that it'd be sadly jaded not to feel a thrill.
Although I agree with you, IDE fans feel the same way: "Writing code is a solved problem: eclipse or xcode or visual studio. Pick one based on your environment and get back to work"
An argument I hear a lot is: 'vim is fine for editing files on a remote server, but not suitable for everyday work'. I believe it is a common belief outside of the HN crowd.
On IDEs: I have the 'pleasure' of being one of those chaps who spends parts of his day job reworking massive Java projects. There is no way in hell I'm touching that without an editor that deeply understands Java.
Seriously, it's a language sufficiently verbose and inexpressive to effectively require an IDE. If you're just going to be generating 70% of your code from your IDE, why is it there in the first place?
Languages don't just fall into two black and white categories of whether or not it requires an IDE that understands the language. It's a spectrum, which means that all languages should benefit from an IDE that understands the language. If not, then you've just found the perfect holy grail of computer languages. Until then, face the fact that language integration is nice.
Unless I'm missing something, specialized non-VIM IDEs tend to be much better at auto completion (especially in C++), jump-to-definition, refactoring, etc. IDE users (who typically are ignorant to VIM) can use these features with extreme productivity. On the other hand, VIM users tend to be rather ignorant of how incredibly productive you can be and how nice it feels to have these powerful context-sensitive tools at your fingertips (and sorry, but CTAGS is useless). Regardless of what IDE you use, nobody can deny IMO that having an editor look up APIs and function lists for you in a context-relevant manner is productivity-boosting versus the alternate of scanning headers manually.
So in this sense I think both VIM/EMACS and IDE users are ignorant to other editor paradigms. What I don't like is how each party tries to claim that their method is the best, without having truly tried both.
I've used both extensively (used VIM for years) and I prefer IDEs by far, but that's just my personal preference.
I've used both IDEs (Eclipse, IntelliJ IDEA) and Emacs. Originally I preferred the IDEs, but then I learned how to use Emacs properly. Besides, Emacs actually combines the best of both worlds for some languages like Scala or any sort of Lisp. (But, notably, not Java.)
I may be crazy about Emacs, but I'd probably still use an IDE if I had to do significant Java development. This says far less about IDEs and editors than it does about Java: I'm going to try very hard not to do any significant Java development in the future, thank you very much!
And that's really the entire point of my earlier post: it was not in favor of editors or IDEs, it was in favor of not using Java. Java is a poor language cursed with a good implementation: it's too good to die but not good enough to use.
A common argument I hear from people defending Java is that their IDE can generate half their code for them. And that was what I was really responding to: if you can use a tool to automatically generate all that code, it should just not be there in the first place!
Your experiences using an IDE for Java say as little about the relative merits of an IDE or text editor as experiences using Emacs on some Lisp: they're both extreme cases. And, more importantly, the reason normal editors are poor for Java, and the reason that SCdF is not touching a normal editor, are endemic to Java and not to the other tools.
You spend as much time reading code as writing it. An IDE that can show you context relevant info at all time and facilitate browsing is interesting in any language. (like where is this set, where else it is used, what the doc for it, ...)
You can also see it as a "problem" of the language if you cannot create an IDE that improve your productivity over a text editor.
Now is a great time to quit: the job market is crazy for software developers. Maybe you don't have the luxury of choosing what tools to use, but you certainly have the luxury of choosing where to work!
Unless you're planning to stay at your current company forever, this is as good a time as any to try something new. Put some excitement into your life :).
Actually I wasn't talking about myself. So far I've only been working part time as a software engineer during my studies and I want to start a company next year. So, IF it works out, I could have that luxury. But I still find it a bit silly to tell someone to quit his job just because his current tooling doesn't involve vim or emacs. Tools are just that. Tools. And IMO Java is just fine if you use it where it is the strongest: enterprise business applications. As long as you don't try to push it to places where performance / power optimization is relevant (I'm looking at you, Google -.-).
Actually, I could live with using an IDE. And most places let you use Emacs if you're crazy enough. (I know both from others and a bit of personal experience :P.)
It's the Java that would really drive me off the wall. Even in enterprise business applications (which aren't fun as is), Java is exceptionally annoying. But it is easy to hire for!
But in your example, IDE fans are suggesting a demonstrably worse set of options - when I switch from iOS to Android development, I have to learn an entire new editor. Using vim, I have to learn the `adb` command.
While vim is very cool, there is certainly a lot of room for improvement. vim's codebase doesn't look like something that I would like to hack, and don't try to tell me that things like vim plugins or vimscript are supposed to be the best that we can ever hope to do.
I'm not trying to tell you anything about the codebase, vim plugins, or vimscript.
I'm trying to tell you that it's probably a waste of your time to agonize over text editors, when there are two very powerful editors available to you, with decades of development and refinement, millions of active users, hundreds or thousands of contributions of plugins and scripts and support tools, copious documentation and examples, and the tools you need to embark on any text editor task you may have without ever feeling limited by the editor (assuming you have learned your editor).
Do you want to work on your software, or do you want to work on text editor scripts? Sure, sometimes you need to write a macro or script or something...but, I can count the lines of vim code I've written in my entire 20+ years of programming on my fingers and toes (if I count vimrc stuff, it'll require a few other people's fingers and toes, but it's still statistically zero compared the amount of code and docs I've written in that time).
I'll leave it to Bram Moollenaar figure out how to improve vim. He's added Python support to vim years ago. Is Python really insufficient for you? I've never needed it, but if I were making something big for vim, I'd probably look into it. But, again, I'd rather be working on the stuff I'm passionate about. Editing text is not a problem I'm excited about; if it's your bag, that's great. But, for the rest of us, it's just a form of procrastination to fiddle and futz around with new tools when the old ones are more than sufficient (and probably superior, on the whole, to new ones...sure, TextMate is super-badass and awesome; but it's missing tons of capabilities that vim and emacs have, and you'd probably be better off learning how to maximize your efficiency in those more powerful editors, than learning new tools which will come and go).
the problem is that there's a lot of accumulated work that has gone into vim at this point, and none of the attempts to reproduce that atop a cleaner, more modern codebase ever went anywhere. emacs's evil mode[1] looks like the most promising current alternative.
Not so subtly the author is telling the reader if you program with Vim you'll be just like "all the really great programmers" who can write 4 line solutions to problems that take ordinary programmers 10 pages. You'll produce "impossible patterns of code and text manipulation", and be able to "fill dozens of registers" (admittedly I don't know what that means). This is all bit silly and reminds me of "hacking" in the Hollywood films.
I understand that this post was tongue in cheek. I also understand that not all text editors are equal, if you see someone writing their first hello world program in Notepad yes you should tell them about much better alternatives. But this post confuses ability to program with ability to use Vim.
Being really good at using Vim will definitely let you say you're part of the club of people who are really good at using Vim. It just might make you more efficient at manipulating code. But let's not perpetuate the elitism that is pervasive enough in hacking, it's a text editor. It doesn't make you more intelligent, better at problem solving, or writing more efficient code.
He's not saying that using Vim will make you a better hacker. You're the one who's confusing remarks on correlation for causation.
Its probably likely that there is such a correlation; those who are willing to put in the time learning vim/emacs are probably those who spend the most time coding, and thus have the most practice.
You could do a global search and replace of "vim" with "emacs" (or pretty much any other development tool for that matter) and it would not change the semantic content of this article at all.
LOL so in my early days it was "vi" but I too use "vim" now a days.
Either way the funny thing is when someone asks me "how do you do THAT in vi?" I often find myself typing in the air to replay the muscle memory that executes those instructions.
For better or for worse I've become muscle programmed to execute vi commands in flashes of thought that really never reach my normal cognitive functions. I love to watch people stunned as they see me do something I've taken for granted for years or figured everyone else knew how to do.
All that said, all tools are not for all situations and all people. I do at times find myself jumping into eclipse (Java I'm looking at you!!!) because of the many additional features available in a good IDE.
I know you can run the vim extensions in eclipse but I've never bothered. I figure if I'm going to mouse my way through an IDE I'm not sure what having vi commands will do to make my life easier. :-)
Oddly, I've found myself using vimacs (https://github.com/andrep/vimacs) to have emacs keybindings available with the quick startup / easy configurability of vim.
I make no claim that emacs keybindings are superior to vim's native keybindings, but for whatever reason, I type more naturally using them at this point. (Which somewhat mystifies me, since for years I used vi/vim as a primary editor with it's normal keybindings.)
I still think that vim keybindings are faster than Emacs for actually editing text, but the emacs keybindings feel more pleasant to me (unless I'm using something without a dedicated control key - like a phone or tablet).
It is NOT going to be easy, but please stick with it. In time you will gain a muscle memory and proficiency for its use. And you will only continue to get better.
I can't speak for how vim feels under Windows (I'm not knocking your OS, just commenting on possible issues you may have). If it seems non-native it may serve you to spin up a virtual Ubuntu instance and give it a try there.
Also, temper your expectations. The comment above by StavrosK [1] is good to keep in mind. Using vim feels liberating and fluid, but it will not improve your programming ability.
I learn by watching and following along with examples, so the following YouTube videos are the ones that I've found the most useful:
http://www.youtube.com/watch?v=71YTkxUNwmg <--Covers the basics and helpful commands. I had never used vim before watching this video, and now I'm reasonably competent at basic text editing.
I wanted to understand/use the .vimrc file, so I googled until I hit this one, which I found quite informative: [UPDATE: put in the wrong link, serves me right for picking the last history item with .vimrc in it instead of watching it. The actual video I found helpful was this one of a guy showing his .vimrc file and what various things in it do: http://www.youtube.com/watch?v=xZuy4gBghho]
Lastly, once you're comfortable using it, try going into command mode and typing Shift-a, and notice that it moves your cursor to the end of the line and puts you in insert mode. I saw this tip on HN awhile back, and I hadn't seen it in any basic tutorials, but it is the single most useful command I've come across.
It will teach you 'The Vim Way' which is a MUST if you want to get most out of it.
When starting with Vim, it can be very daunting and I can't emphasize that enough. If you are in NJ/NY, please email me and I can walk you through 'The Vim Way' to make it easier to get up to speed.
I'm all for vim or whatever other editor you prefer.
But to somehow claim that one editor or another is going to make you a better programmer and make your 10 pages of crap code become 4 elegant lines is pretty nonsensical.
No matter what editor you use; if you're not good at problem solving, you're not going to make a good programmer.
You know, I'm doing an experiment like this with Tetris. I was looking at the world record for 40 line clear (20.55 seconds at http://www.youtube.com/watch?v=WzUUKKuye24) and I realized that the limit is not how fast he thinks, but how fast he is pressing the keys.
So I designed my own system. One key press drops the piece instantly into the correct spot, with the correct rotation. It's making my brain hurt practicing because it requires so much thinking, but once I get it into muscle memory, things are going to get really interesting. My 40 line best using the arrow keys is 45 seconds and with my new scheme it is 2:21. But I'm dropping time quickly and I'm sure very soon I'll beat my record.
Okay, maybe you didn't see how this related. I should have made it clearer. There are a lot of discussions on this page about how Vim's advantage comes from the muscle memory adaptation, relegating text editing to a subconscious, effortless activity rather than something that requires active thought.
I was expounding on this concept with an idea of my own and speculating about its potential benefits using analogous logic to that used in the reasoning about Vim's efficiency.
"Knife skills" don't make you a good developer. Cook a great steak and worry less about cutting it. Tools are boring. People are far more important. A post like this is akin to "I LOVE BRITNEY SPEARS." Please God, make the programmer pop culture stop.
Coincidentally, I've been working on my knife skills lately. In the past, I often served dinner late because I took so long to chop the vegetables. (I'm vegetarian.) Now that I'm focusing on proper knife technique to chop quickly, I find that I can get dinner served faster — but also I have more flexibility to respond and experiment in the kitchen, because I can, for example, put the skillet on the stove before I start chopping the onion I'm going to sauté. And I'm less likely to burn things, because chopping takes less of my time and attention.
Of course, knowing how to cut isn't the same as knowing how to cook. Vegetables chopped slowly taste the same as vegetables chopped fast. But if you already know a thing or two about food, you can cook a little bit better if your cutting technique is better.
Nope. Don't get me wrong, I love vim, but I don't need to have it everywhere. It makes no sense in the browser. It's lacking some features Eclipse has (although if Eclipse had a proper Vim mode, I'd use it in a heartbeat).
A long time ago I narrowly escaped being like that exactly, but with TECO :-)
I've learned not to fret about people's choice of editor. FOr instance, if someone was happy in NotePad, as long as it didn't affect me, I learned not to care. (I might grit my teeth in frustration, watching them flail for minutes at something I could do in seconds with my choice of editor, but that's my problem).
Yeah, but I always ssh from Emacs using Tramp. When all I have to do is C-x C-f /user@hostname:~/path/to/file, there is no reason to use anything else.
Just as pragmatic, and I get to use all my nice normal Emacs features at the same time.
Fully recognize I am outing myself here but the timing seems great given the Vim articles that have been coming up lately, as well as my Lead Engineer keeps bugging me to really get into Vim. I have used it before, but never GOT it. Is there an online guide that is great (and not just a story like this one) or do I need to get the O'Reily Vi and Vim book?
Being somewhere in the middle of that timeline, I'd watch that movie. This piece reminds me that an authors vision is always more important to communication than the subject itself.
If someone can always "churned out 4 line solutions for an assignment that took you 10 pages of code to complete", he can use any editor or maybe simply "cat >".
I still can't believe people love that damn thing so much, even after all these years. There are way better tools in my opinion.
Of course, if you like it by all means continue using it. But if you think it has anything to do with your talent as an engineer, you are wrong. And if you see other engineers not using it and think it implies anything about their talent, you are wrong.
Side note: if anyone wrote in such a breathless tone about Apple, they would be skewered as a fanboy and a drinker of the Kool-Aid.
What I gained from the article wasn't any explanation of why Vim is great; indeed, there was little included in this respect, aside from moving "entire blocks of code with the flick of a finger." Even the cool feeling of proficiency you get from knowing a tool well, and the fun of getting to show off a skill to a "how did he do that!?" audience was secondary.
My favorite part was the implicit reminder to relax about my tools. The most effective use of hyperbole is not the emphasis of a particular point, but a caution not to take ourselves too seriously, and place our self-satisfaction in proper perspective. The most powerful instances border on satire, and in that respect, this piece was perfect.
Addendum: I use vim and pentadactyl. They are extremely awesome, fantastic, and exhilarating.