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";

    ci"baz<esc>

    <cmd>→←←⌫⌫⌫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.

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.

Gives back a list of interesting people.

Not that I think it matters if you use Vim or anything particular for that matter.

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!

<cmd>-<right>, <option-left>, <option-shift-right>, baz

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.

edit: link - https://github.com/JugglerShu/XVim

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

  Ctrl + I : Incremental Find (finds and selects finding)
  bar : Find & select text
  baz : Overwrite selection

  Ctrl+<Right>+<Right>+<Right>+<Right> : Reach the word bar
  Ctrl+d : Select word under cursor
  baz : Overwrite selection

  Ctrl+P : GoTo Anything
  # : Goto word
  bar : Goto word 'bar' & select it
  baz : Overwrite selection

    f"ci"baz

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

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.

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.

Hope this helps.

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.

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

Have fun

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

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.

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!

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.

You often don't notice how useful something is until you're used to it.

http://www.youtube.com/watch?v=pCiVCiku3cM

http://blog.eleutian.com/download/vimteaser.wmv

http://blog.eleutian.com/download/vim2.wmv

http://blog.eleutian.com/download/vim3.wmv

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.

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.

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

If your language has a more involved build process, chances are someone has written a plugin to help you and posted it on the vim scripts page: http://www.vim.org/scripts/script_search_results.php.

Enjoy :)

Alternatively, my own work flow consists of using tmux to have a split screen terminal, Vim left, REPL right.

I use CUA and can be productive everywhere immediately, even if it may be a bit less efficient.

Then you reap productivity benefits for the next couple decades.

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.

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

"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]

  // 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 ]

1. `command + A` to select all

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.

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

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

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

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

    

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.

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?

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

Consider this sample grap extension take from Steve Losh's http://learnvimscriptthehardway.stevelosh.com/chapters/34.ht...

    nnoremap <leader>g :set operatorfunc=<SID>GrepOperator<cr>g@
    vnoremap <leader>g :<C-U>call <SID>GrepOperator(visualmode())<cr>

    function! s:GrepOperator(type)
        let saved_unnamed_register = @@

        if a:type ==# 'v'
            normal! `<v`>y
        elseif a:type ==# 'char'
            normal! `[v`]y
        else
            return
        endif

        silent execute "grep! -R " . shellescape(@@) . " ."
        copen

        let @@ = saved_unnamed_register
    endfunction

    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.

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

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.

Back to work ;-)

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.

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.

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

    "She said: 
    \"Vimscript is tricky, but useful\"!".

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

    normal! `<v`>y

   copy_visual_mode_range_to_default_register()

But everytime I need them, I have to look them up, compared to vim normal mode and other commands which I already know and use in the editor.

> There is objectiveness. By learning Emacs, you are learning how to use a tool which is much more consistent and flexible

Unless you have objective proof of "emacs being much more consistent and flexible(where, how)" it's not objective at all.

> but the superiority of Emacs

Again, citations needed.

> Emacs has an effective editor implementation, Vim has an effective editing model. That's what is objective.

No, it's still not objective. You just delcared "vim has effective editing model" and "emacs has effective editor".

> Back to work ;-)

The only thing that matters.

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.

>> Back to work ;-)

> The only thing that matters.

But a flame war is often a welcomed distraction.

Cheers.

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.

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.

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.

Have a sweet day.

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.

I'm not really a Python person (I prefer Common Lisp, but that's another talk for another time), but GNU Emacs has Pymacs

qrIdef<space><esc>f.Di()<return>end<esc>jq

qr ' record a macro into register r

I ' insert mode at start of line

def<space><esc> ' type def then exit insert mode

f. ' find the dot

D 'delete the rest of the line

i()<return>end<esc> ' type () return end

j ' next line down

q ' exit macro recording

call it with 9999@r

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)

cat file | perl -p -e 's-\s(.)\.rb-// Run the $1 command\ndef $1()\nend\n-'

start recording a macro:

qa

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.

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

It's not always about programming. It's about configuring and extending to suit it to your problem.

Pylinting and running python code. ,c(mapped to :make, not shown here) to pylint(not need as I run syntastic but still), ,x to run

    augroup python
        au!
        autocmd FileType python nnoremap<buffer> ,x :w<CR>:!/usr/bin/env python % <CR>
        autocmd FileType python setlocal nosmartindent
        autocmd FileType python setlocal makeprg=pylint\ --reports=n\ --output-format=parseable\ %:p
        autocmd FileType python setlocal errorformat=%f:%l:\ %m
        autocmd BufRead python setlocal efm=%C\ %.%#,%A\ \ File\ \"%f\"\\,\ line\ %l%.%#,%Z%[%^\ ]%\\@=%m
        autocmd FileType python setlocal path+=$PYTHONDIRS
      augroup end

    inoremap \1 <%<Space><Space>%><Esc>2hi
    inoremap \2 <%=<Space><Space>%><Esc>2hi
    inoremap \3 {%<Space><Space>%}<Esc>2hi
    inoremap \4 {{<Space><Space>}}<Esc>2hi

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.

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

Full client for Redis

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.

Highlights: a Python IDE with refactoring, inference, search, etc.

Some hacks for TRAMP which lets me remotely edit content on arbitrary servers transparently.

A Python repl.

A generic compliance checker for Python code.

An undo module that presents undo/redo history as a visible tree that you can traverse arbitrarily.

A git client that has some EXCELLENT features.

A function to dynamically reload my environment.

A macro for my python debugger injector.

Code to unhtml HTML content and a whitespace cleaner-upper.

An interactive environment to experiment with and test regex.

A mode for CSS that highlights hex-values with the colors they represent, making their properties visual.

An interactive HTTP REST client interface for testing HTTP APIs.

A clone of hacker-typer in elisp.

Modes for clojure, erlang, haskell, rust, etc.

And a nyan-cat for my progress bar.

either you share this or not. If you saw anything else, you are probably misreading or reading too much there.