
Why are vi[m] efficient code editors? - robomartin
This started on another thread where I got throttled pretty badly because of my opinion that, in the context of a non-trivial project, vi[m] offer no real gains, particularly when one considers timelines, code quality, bugs, costs, etc.<p>I am always one interested in learning.  And that is why I decided to launch this thread.  To be clear, I am not interested in engaging in "mine is better than yours" discussions that invariably lead to flame wars.<p>The intent is to hear from vi[m] expert users on the reasons those of us who, like me, only touch vi[m] when absolutely forced to, or others who chose to avoid vi[m] or barely know anything about these editors should seriously consider what vi[m] have to offer.<p>I propose that posts should take the form of reproducible recipes.  Give us, vi[m] neophytes, steps to follow in order to understand how one might do a specific task more efficiently using vi[m].  Please don't engage in comparing it to anything else.  If we keep it to vi[m] recipes then this thread stands a chance of becoming an educational resource for those of us not familiar with these methods.<p>This also means that making claims about vi[m] efficiency supported by saying something akin to "every programmer who uses vi[m] thinks so" are not acceptable.  Only recipes.<p>Also, in the interest of fairness, the recipes should work with unmodified vi[m].  Requiring the loading of plug-ins of various kinds muddles things as the same could be true of other editors.<p>In addition to this, let's not talk about things like memory foot print or binary size.  With today's multi-gigahertz-multi-gigabyte computers this really is immaterial.<p>A recipe could start by suggesting to clone a certain github repository, then opening a specific file with vi[m] and then offering-up a series of commands that show how to derive efficiency gains from vi[m].<p>On my end, I have access to OSX, Linux, Irix, Solaris and emulators on Windows machines.  Other readers might only have one platform available.  Please indicate if your recipe, for some reason, requires a specific platform.<p>Finally, please don't comment on my introductory (first) paragraph.  Only recipes and discussions that ask questions or offer clarifications on the recipe in question.<p>Thanks.
======
slurgfest
Where are your data proving that vim offers 'no real gains' (or as you
intimated in another thread, that it is actually counterproductive to use
vim)?

I'm puzzled at how you can ask about 'gains' and at the same time, discourage
comparing vim to anything else. Isn't your question about relative advantage?

If you disqualify things like startup time, portability, and plugins you are
now talking about a meaningless comparison. Those are real features vim has
and you are just trying to exclude them in an effort to tilt toward your
predetermined conclusion that vim is bad.

------
tlunter
The reason I use vim is precisely what you have access to. OS X has vim, Linux
has vim, and there are all different versions and ports of it. If not vim,
then at least vi. Do I need all my plugins to be sufficient? No. Is it nice to
have my customized look, yes.

In the end my productivity at any work station is not defined by which program
I use, but how well I know the code. I try to not let my environment affect my
workflow as much. If I sit down at any computer with some way of SSH, or a
terminal emulator then I will be able to code my heart out.

One last thing I notice with vim, everything seems to be a keystroke away.
Searching and moving the the next line, adding to the end of the current line,
indenting the line, moving to the beginning of the line. It's so quick.
Certainly every other editor out there has realized this and has the same
features, but they are gummed up by the fact that they are always in insert
mode. For me it is faster because I don't use left shift or control. Some
people prefer emacs style bindings for everything they do. They don't mind
throwing the left pinky down and hitting shift or ctrl. I find it so unusual
so I find vim bindings much easier to become accustomed too.

Does that provide any help?

~~~
robomartin
> Does that provide any help?

Not a recipe, but yes.

Can you explain this comment a bit further: "they are gummed up by the fact
that they are always in insert mode"

How is being in insert mode problematic? A scenario or two might be useful.

I use vim with git all the time and can't say I enjoy having to go in and out
of insert mode every time I touch it.

~~~
tlunter
Well as carb said, you aren't going to be writing code for hours and hours
each day. As a project gets fuller, it's more navigation between files and
manipulation of what is already there. The ability to move around lines with
only one key or a key and an alternater (Shift more often than not) makes
movement a blast. Searching for words around a file is as simple as a /. The
ability to repeat past commands is just a ".". There are a variety of commands
that when they are first presented to you looks like a mess. If you take a
second and look at it it turns out to be really quite simple. Just vim
commands are short and sweet and simple.

There is no recipe or anything to get really good at Vim. It's up to the
person using it to get a firm handle on what is going on. Some times you just
have to be curious and notice that there could be a performance tweak here and
then research how to do it. Also, don't be afraid to make your own macros to
take care of work for you. I have plenty of self defined macros. Taking all
the work from someone else doesn't make it entirely yours. Tweaking and
picking from tons of other vimrc's and the like can be interesting.

As a tid bit, make your own dotfiles repository on github. I have about 15-20
systems where my dotfiles directory is symlinked and as long as I have
internet I can transfer around my perfect environment.

~~~
robomartin
I intend to spend time with vim over the weekend and take-in some of the
excellent input found on this thread.

The mental image I am developing now is that vim can be said to be efficient
in a narrow sense. Perhaps that narrow definition is constrained to the file
level. It's like a musical instrument to manipulate files. Once you know it
well, it feels just like that. I am not saying that this is the only
definition, it's just what I am coming-up with now.

Once we deviate from whatever the narrow definition of where vim is more
efficient the claims start to fall apart. This doesn't happen because of vim
but rather because it is the very nature of creating software: Things take
time and saving keystrokes at the file-editing level isn't going to bring a
project to completion six months earlier and with less bugs.

I wear at least two hats: developer and businessman. I am forced to look at
things from both angles, because, well, I have to pay for the consequences of
my own decisions. For example, if I succumb to my natural inclination to keep
adding features it means that I might have ten programmers busy for weeks
chasing an ever-moving project completion milestone. So, as a business person,
I do my best to control these urges and look at things through a different
equation. Eventually you have to call it "done" and move on.

Over the years I have never seen any code entry tool that truly makes a
serious dent in software project timelines. Software projects are notorious
for being late and over-budget. And this has absolutely nothing to do with the
tools we use. Zero. A better editor or IDE will not make a dent on overall
project timeline. Anyone who can figure out a way to solve that problem can
become an "instant" billionaire.

~~~
johncoltrane
You are making stuff up. Nobody is claiming that using Vim over Eclipse allows
a product to be delivered earlier and with less bugs.

The Agile crowd makes that kind of claim, some language zealots also do.

The "saving keystrokes" argument is important for programmers because our work
is very repetitive and we are lazy. It has nothing to do with the productivity
of your team or the release date. Nothing. Because programmers don't care
about all that. Chosing Vim over another editor is a matter of personal
choice.

If you don't like Vim don't use it. Noone cares.

if you are interested, even remotely, try it in your free time.

But by all means don't project the effects of your delusions on random
strangers: nobody is insisting that you use Vim instead of X. All the "Vim is
awesome" comments or blog posts you have read are not attempts to bring you to
our temple. They are just manifestations of our personal and often
unreasonable "love" for Vim. No more, no less.

------
grannyg00se
"in the context of a non-trivial project, vi[m] offer no real gains,
particularly when one considers timelines, code quality, bugs, costs, etc."

"Give us, vi[m] neophytes, steps to follow in order to understand how one
might do a specific task more efficiently "

I believe this is the strawman that was being alluded to in the previous
thread. Nobody is going around saying "Hey, if you don't use vim, you are
producing less than I am!" Okay maybe some people do say that, but that's
really not the reason people love vim.

The real reason (in my opinion, of course) has to do with _flow_. It's hard to
explain, which is why these discussions tend to digress. But when you're in
_flow_ , or _the zone_ , you don't want things like your text editor to get in
your way. You want it to be a harmonious extension of your intentions to the
machine. When you connect with vim, that is what you get. Other people might
get that connection with emacs, or some other editor. But for the most part,
you just don't get it with editors that don't allow a rich communication
vocabulary between you and the machine.

Does _flow_ matter on the scale of business deliverables within a project
budget? Not really. It matters to the enjoyability of the creation experience
that the programmers are involved in. They could probably still produce the
work without that additional enjoyability, but less enjoyable work can
sometimes lead to lower quality. And perhaps more importantly, it always leads
to less joy.

For the past several years I've been using a keyboard that doesn't require me
to move my hand away from the home row in order to manipulate the mouse
cursor. There's a similarity there in that it reduces flow interruption. I've
recently started learning vim because I see this same potential in it.

As for "recipes", there is a post here taken from the previous thread:
<http://www.viemu.com/a-why-vi-vim.html>

~~~
robomartin
I am going to ignore the first part of your comment because, well, I asked
that this thread not go that way. The problem with the other thread is that
claims were made about vi efficiency and not one bit of data of any kind was
provided to support these claims. Nobody learns this way. This thread is
already very different as many have provided very interesting comments with
valuable insight, including yourself.

I understand flow very well of course. I can't say that I've ever used an
editor that prevented me to enter that state. I a not countering your
statement, just providing my own experience.

Aside from programming I play the piano and classical guitar. When I play
music I am in flow. That didn't happen until I had reasonable command of the
instruments. With vi (or any other tool) the same is required. I wonder how
much time it would take to go from vi neophyte to playing it like a piano?
That initial phase is painful if you have to get work done.

I also understand the value of playing a good instrument and using good tools.
And, while this value may not provide any hard quantifiable benefits to the
project timeline it does provide benefits for the practitioner. The project
might still be six months late, but there will be more daily enjoyment, if you
will, for the practitioner to remain on focus. That could have value. Whether
or not there is a difference between someone who has never touched vi and a vi
expert remains to be determined. The vast majority of programmers don't use
vi.

After reading your post and others on this thread my immediate reaction is
that vi advocates might want to consider not characterizing vi as "more
efficient" but rather highlight what it might do for a programmer. I can't
come up with the words right now, but "more efficient", in my book, calls for
having quantifiable data at the project level (not the file level).

We all know that saving a few keystrokes here and there isn't going to bring a
project to conclusion any sooner. We had a project where we spent six months
tracking down a bug that was due to a rounding error someone made in a
calculation of lookup-table data used in a polyphase FIR filter module. It was
one of those things that was right in front of you but nobody could see it.
The project was late by an additional six months (it was already late) because
of that bug. That's the kind of thing I think about when I say that saving a
few keystrokes on the editor doesn't matter in the context of a project.

I'll read the article you pointed out and see what else I can learn.

Thanks for your input and valuable insight.

~~~
aidenn0
I just think "efficient" is ill-defined. Nobody (or nearly nobody, I can't
speak for everyone) that says vi[m] is more efficient is talking about
project-level efficiency. They are talking about saving a few keystrokes (or
more importantly a tiny amount of attention) when manipulating text.
Manipulating text is just one part of writing software, but it's the part that
developers want to spend the least amount of thought on, as it's (as you point
out) not that important at the project level.

Being more efficient at manipulating text means less energy spent, which makes
for happier programmers. So the more efficient text-editing is preferred by
some, not because it leads to better software, but because it leads to better
quality of life. And I stand by the statement that vi[m] is more efficient at
manipulating text, while not disagreeing with you that it makes no difference
at the project level.

~~~
robomartin
> Being more efficient at manipulating text means less energy spent, which
> makes for happier programmers. So the more efficient text-editing is
> preferred by some, not because it leads to better software, but because it
> leads to better quality of life. And I stand by the statement that vi[m] is
> more efficient at manipulating text, while not disagreeing with you that it
> makes no difference at the project level.

I can absolutely agree with you on that. Learning vi[m] in order to get to
that level seems to be the hit lots of people are not willing to (or simply
can't) take. In the context of a busy shop it makes almost no sense to bring
productivity down to almost nothing while everyone has to slow down to learn a
new tool (any tool, not just vi[m]). The only time one can justify this sort
of thing is when there are real and measurable business or code quality
benefits to the interruption. An example of that is sending everyone out to a
one week course on a new technology. When they come back they absolutely rock.
I've sent people out to take courses costing the company tens of thousands of
dollars on more than one occasion. In every case it pays off within days.

I can't say that about vi[m] yet. Not wanting to voice opinion from a context
of ignorance I will spend time over the weekend to force myself to dive into
vim and see what I can learn. Happy programmers, hell, happy people, are
always more fun to work with and be around. If vi[m] can bring that to the
table I have no problem promoting its learning and usage at our shop (when we
can afford to take the initial productivity hit while everyone learns).

~~~
aidenn0
Most programmers who care that much about their tools will learn (at least
partly) on their own time. I agree that it probably doesn't make sense to have
a "learn vim" week at most companies.

------
robomartin
In looking for vi[m] tools for Vista 64 I came across this:

[http://www.microsoft.com/en-
us/download/details.aspx?id=2375...](http://www.microsoft.com/en-
us/download/details.aspx?id=23754)

older, but better explanation: [http://technet.microsoft.com/en-
us/library/cc779522(v=ws.10)...](http://technet.microsoft.com/en-
us/library/cc779522\(v=ws.10\).aspx)

And a blurb on how to go about enabling some of the functionality:

    
    
      If you have Vista Enterprise or Ultimate, you can install the optional
      "Subsystem for Unix Applications" (SUA). This is under Control Panel,
      Programs and Features, Turn Windows Features On or Off. After you have
      installed SUA on Vista, then download the "Utilities and SDK for SUA" from
      Microsoft.com (the download URL is in the Start menu, after you install
      SUA).
    
      The SUA Utilities include vi, as well as all the standard Unix/Posix tools
      like ls, cat, sed, awk, etc. There is also the gcc compiler, so you can
      compile and run a wide range of open source Unix software on your Vista box.
      You can also download SUA binaries and source code for many popular
      Linux/Unix apps on Vista, from www.interopsystems.com - Apache, PostgreSQL,
      OpenSSL, Squid etc - it's all there.
    
      Unfortunately, SUA is not available for Home or Business editions of Vista.
      If you have one of these editions, you can try using Vim, a very popular vi
      clone (see www.vim.org). A Win32 version is availabel. In fact several Unix
      distributions are now shipping vim as the standard editor, in place of the
      classic vi (because vim has many useful extra features).
    

Fortunately we are running Vista Ultimate 64 bit, which makes playing with
this subsystem possible.

------
ramses0
Vim is _extremely_ regular, as well as extremely powerful.

The thing that makes me rage when I'm forced to use an editor other than vim
is "Ctrl-RightArrow / Ctrl-LeftArrow".

Will it stop on spaces? Will it stop on commas? Will it stop on parenthesis?
If I hit Ctrl-Right->Right->Right then Ctrl-Left->Left->Left do I end up back
where I started?

I cannot fathom how people blindly accept that their editing movement
operations are inconsistent. In case it's not clear, by default in windows
most text editor areas do not "properly" return you to where you started with
a bunch of Ctrl-Right/Ctrl-Left pairs (although I can't tell you at the moment
what characters actually trigger this issue).

Finally, by being a "modal" editor... when you want to type letters and stuff,
getting into insert mode is an extremely small price to pay in comparison to
having 26 function keys under your fingertips at all times.

"""Vi has the advantage that most ordinary keys are connected to some kind of
command for positioning, altering text, searching and so forth, either singly
or in key combinations. Many commands can be touch typed without the use of ⇧
Shift,Ctrl or Alt. Other types of editors generally require the user to move
their hands from the home row when touch typing:"""

...the idea being that when you're actively typing, vim is just as crappy of a
text editor as anything else (notepad, bbedit, etc.) but when you're not
typing you've got at least 26 letters which all do something, then 26 more
because you can type shift.

q == record macro, w == move by word, e == end of word, r == replace
character, etc, etc, etc. (don't make me type them all out, we'll be here a
while! ;-)

~~~
robomartin
> I cannot fathom how people blindly accept that their editing movement
> operations are inconsistent.

That can be a problem if you have to jump from platform to platform or work
with IDE's that implement things in vastly different ways.

I jump between Windows and Mac all the time and for the longest time the Mac
keyboard was infuriating. My solution was to re-map it to match, as much as
possible, what I was used to. That may very well be the case with vim
advocates. To be clear, this isn't about one or the other approach being
better by any measure of the work. It's simply that one tends to prefer that
which is familiar. That's just the way every person is wired. I've seen this
across disciplines that have nothing whatsoever to do with programming.
Resistance to change is a strong force. We tend to want to stay with what we
know and reject change at a visceral level. And that's OK.

Your point are probably valid. I'll take the time to explore over the weekend.
Thanks for taking the time to share your insights.

------
gsvolt7
recently i learned that some developer successfully ported vim to windows 64
bit. i was mighty glad, installed it on a windows 8 machine and started to use
vim right away, simply because dos's edit command doesn't provide features
similar to vim.

i decided to write here how i use vim in no particular preference:

vim's J keystroke (that joins the line in succession with the one you're on)
is the most frequent reason i use vim on whatever platform.

next, s/this/that/g search and replace is quick for regex based string
replacements

next, vim -d file1 file2 visual difference is pretty great in console or in
the gui mode (gvim)

next, on a unix system if you're dealing with C sources for a big project,
ctags allows vim to provide the feature where you press CTRL-] and it takes
you to the definition of that symbol. This is similar to other editor's right
click and 'go to definition' context menu.

i'm not trying to sell vim to you or readers of HN; i'm simply advising to
read :help in vim to the best of your abilities the same way you would read
about other editor's help pages/cheat sheets and the sort to determine value
for yourself. i do agree that examples sometimes enable you to associate with
one or the other editor; i dislike using vim for editing all sorts of files. i
use vim for things i can quickly get done in it, using other tools for
whatever they're good at, if that makes sense.

~~~
robomartin
>recently i learned that some developer successfully ported vim to windows 64
bit.

Do you have a link to the port?

~~~
robomartin
found it.

------
johnny22
how about just don't use vim at all. nobody is forcing you to.

use whatever you like and works for your workflow.

~~~
jlgreco
Ah, but where is the flamewar in that?

~~~
johnny22
because you can't have a vi vs $EDITOR flamewar if emacs isn't mentioned.
duh..</snark>

------
oneandoneis2
Well, as someone who's in the middle of writing his own blogging platform
specifically so I can use Vim to write my posts...

The important thing that Vim does for me is to reduce to an absolute minimum
the amount of keypresses it takes to write the code I want.

Simple example: It's a common practice when people are putting in blocks of
comments to put in an eighty-character line of hashes to delineate it -
something I'm sure every coder has seen. And it's not hard to just hold down
the hash key until it's reached the end of the line. But it's far quicker and
more reliable in vim: 80i#<ESC>

Say I'm editing code near the bottom of a screenful of text. I want to see a
couple of lines that are just off the top of the screen. In most editors you'd
hold down the "up" key until your cursor reached the top of the page, keep
going until the lines you wanted were on show, then hold "down" until you got
back to where you started.

In vim, Ctrl-Y a couple of times and you're done, without losing your place -
your cursor stays in the current position, on the current line.

The regex-capable search + find&replace is invaluable - Earlier today I had to
generate >100 tests based on information spread through multiple spreadsheet
tabs. This would have been hours of work doing point&click copy-pasting, it
was done in a few minutes courtesy of a couple of regexes.

Moving blocks of code around when refactoring is effortless: di} to delete all
the code in the current JS function and copy it to the buffer, move to where
you want the code to be, 'p' to put it in its new home.

The "snippets" plugin giving TextMate-style functionality is very useful, a
big plus for vim's ability to be programmed, which I also use extensively. For
example, we often need to look at information stored by our web application in
a database. We used to have to either access it via the DB or use the web app
itself to display a poorly-formatted static text output. I created a Vim
command that retrieves the data, orders it, formats it, syntax hilights it,
and makes it far easier to navigate & search.

I've used IDEs, I've used other editors, and Vim is simply better than all of
them. IDEs in particular spend more time getting in the way than they do being
useful. Vim is the closest thing there is to being able to take the code I
have in my head and dump it straight into a computer.

And given the number of studies that show that a single interruption to a
coder can result in a half-hour delay whilst he rebuilds his mental stack,
that makes Vim a tool that can save you hours of productive time every single
week.

~~~
robomartin
One of the seemingly common threads I am seeing is that having vim available
across platforms is an advantage to some. That certainly has value.

I can't really comment on the rest of your excellent post until I try some of
these things out. I intend to spend some time with vim this weekend, try out
some of the ideas presented in this thread and see what I can learn.

I can comment on this: "And given the number of studies that show that a
single interruption to a coder can result in a half-hour delay whilst he
rebuilds his mental stack, that makes Vim a tool that can save you hours of
productive time every single week."

I've been programming since I was ten years old. I have well over twenty years
of experience in the field, across multiple platforms, tools and languages. I
started out with machine language. Not assembler, actually typing in hex
instruction codes into a keypad. Back then, I used that approach a number of
times to bootstrap a Forth system onto a newly built computer board (something
like a 6502 board). One of the first things you do after that is write an
editor (in Forth) so you can start moving faster.

I have to say that in all of this time I have never had an editor get in the
way of the programming task to such an extent that it can be considered an
interruption. Interruptions that disrupt the mental stack you refer to are
very real and they suck, but, in my experience, the text editor is never the
issue.

Again, thanks for your valuable input. I'll spend some time absorbing it over
the weekend. I need to get a project out first. Damn priorities!

------
johncoltrane
Three things gave a background to my decision to start learning Vim:

* A nagging desire to drop Mac OS X in favor of Linux and, therefore, the necessity to find an alternative to TextMate. * TextMate's learning curve is very flat and very short. After years of heavy usage, I was bored. * I've seen a couple of "magic" Vim screencasts that left me drooling like an idiot.

Because of the first point, I've spent a significant portion of 2009 trying
out all the Linux/cross-platform editors/IDEs I could find: Gedit, Geany,
Kate, Scribes, Redcar, Emacs, Vim, Eclipse, Komodo, IntelliJ IDEA… I've tried
them all. I wanted completion (even basic), some kind of snippet system,
themeability, fast navigation… and all of it was available in one form or the
other in most of those editors/IDEs.

Because of the second point, the over all design of the editor, the steepness
of its learning curve and all sorts of subjective details (keyboard
friendlyness, scriptability, active community…) were also weighted when trying
out all those editors/IDEs.

Because of the second and third point, I was very curious about Vim. It was
the most "special", advanced users seemed to be able to fly and it was cross-
platform. The String Calculator Kata In Python screencast
(<http://vimeo.com/8569257>) by Gary Bernhardt, despite showing an heavily
customized Vim, was mesmerizing. It's very subjective, I know, but I felt that
Vim was just my kind of "special".

But yeah, it was really "special". All my attempts to use it had been very
frustrating and I was about to settle on Eclipse.

Then came the right occasion: I had a totally empty week before me. Nothing to
do at work, my kid was at his grandparents'… So I decided to give Vim a
serious try.

I decided to start right at the beginning: $ vimtutor, which I did a good
twenty times. After each session, I opened an old html or js or txt file and
tried to apply my new knowledge. Of course the first day or two were very
unproductive and frustrating but I had a lot of time and no obligation of
prductivity so kept trying. After a week, I knew all the basic commands but I
was definetely not ready. When, finally, I had some real work to do I
naturally turned to my trusty old TextMate while I spent a couple of hours
every night watching screencasts, reading tutorials, practicing and, above
all, doing the biggest rookie mistake: trying to turn Vim into a TextMate
clone.

I installed lots and lots of plugins, filled my .vimrc with hundreds of lines
I didn't understand copypasted from people I didn't know and tried to map 1 to
1 Vim's and Textmate's keyboard shortcuts. After a few weeks at this rate, my
Vim was an horrible and slow mess. It took a lamentably failed attempt to use
Vim on a VPS for me to actually accept my failure and decide to go back to
square one.

I deleted the content of my .vimrc and of my .vim/ and tried $ vimtutor again.
I was a new "student": more open minded, more willing to learn. It was only at
that time that I found myself suddenly blown away by the elegance of Vim's
design and, yes, the SIMPLICITY of its language. Before that, aJc/ and Co.
didn't really make much sense. After that, it took one month or so for me to
finally make the switch after "solidifying" my newfound zen.

For me, it was mostly a question of design. And of being in the right state of
mind.

So no, I won't prove you why Vim is better than X. That would be pointless
because a. I don't care about you or the editor you use and b. I'm perfectly
satisfied with the choice I made and I don't feel the need to convince myself
through others that I was right.

Use whatever tool you prefer/know/need/can afford.

Instead I will show you a few things I THINK are cool.

    
    
        yy5p to duplicate the current line 5 times
    
        :g/pattern/norm @m to apply macro m to all lines matching "pattern"
    
        :'<,'>norm yss<li> to turn a bunch of visually selected lines into list items (the '<','> is added for you by Vim and the yss part is provided by Surround.vim)
    
        :ts <tab> to select tags from a <tab>-navigable list
    
        <C-x><C-l> (mapped to ,= here) to complete lines
    
        <C-x><C-f> (mapped to ,: here) to complete filepaths
    
        dat to remove a whole html tag
    
        ci( to delete the content of parenthesis and enter insert mode
    
        R to enter replace mode
    
        <C-a> and <C-x> to increment/decrement a number (with an optional count)
    
        <C-r>= in insert mode to insert the result of an expression
    
        vatat to select a whole table row from within one of its cells
    
        :s/foo/bar the best search/replace mechanism I've ever used
    
        <C-o> and <C-i> to jump through the jumplist
    
        ma 'a to create a mark and jump to it. that's pure beauty.
    
        /?{}wWeEbBfFtT and all the other motions and text-objects that make moving around so horrible in every other editor
    
        and so on…
    

I understand that most if not all of it can be achieved in most code editors
but, in my opinion, none allows me to do all that in such an elegant and
natural manner.

~~~
robomartin
This is, by far, the most intelligent and useful post I've seen in my attempt
to get some answers and understand. I am as hard-headed and as anyone else. I
am also as understanding as anyone else. Change only happens out of necessity
and curiosity. I am curious to learn, otherwise I wouldn't spend all this time
and take the abuse of some who choose to be total aholes and not take the kind
of approach you have taken to at least help someone --not just me, but anyone
who may have touched vi and failed-- understand where the strengths may be.

Based on your story it is clear that vi is not a weekend project. I am
interested in learning so that I can have an opinion that is based on more
than the "fuck this" reaction I have had over the last twenty years every time
I've touched it on many platforms.

I am also impressed by your process and dedication to exploring the space. One
can only respect that approach and the conclusion you reached. I too have used
a ton of editors. For some reason I've never had the patience to really get
into vi. But now I will. Because I owe it to myself to know what everyone is
so impressed with. What happens from there is a different matter.

Also, thanks for not resorting to insults or calling me a troll as others who
never seem to contribute anything of value have done.

Thanks again.

BTW, if you have more screencast links feel free to share them. I'd appreciate
it and I am sure that others who are reading this and might have had the same
level of rejection of vi would too.

~~~
johncoltrane
HTH.

There are many screencasts available on the net, paid and free. The best ones
happen to be free.

Drew Neil's screencasts at <http://vimcasts.org/> are laser-cut, focused and
short. Each video is about one or two specific use-case so you don't get
overwhelmed by dozens of "cryptic" commands. The production value is amazing
(not in the Michael Bay meaning of the word).

Derek Wyatt's Vim Tutorial Videos at <http://www.derekwyatt.org/vim/vim-
tutorial-videos/> are the opposite: messy, lighthearted, funny, hysterical and
packed with gold nuggets. You'll probably need to watch them a few times if
you really want to extract practical knowledge.

Peepcode has three Vim-related screencasts but I think they are really bad,
specially the "Play-by-Play" one.

Yes. Vim is not a weekend project. There's no way you can reach your previous
level of productivity in one weekend or two.

May I suggest you, based on my own experience, to not install any plugin and
not copy someone else .vimrc? Play around with $ vimtutor, exercise on random
files (not on serious stuff), read the help (:help<Enter>), watch a bunch of
screencasts to get the feel of what it's all about.

After the weekend is over you will either be craving for more or be disgusted.

Consider both outcomes as a succes and move on to the next step.

~~~
robomartin
Will do. I am planning on hitting-up vimtutor later today after the kids'
Saturday activities are over. Fishing trip tomorrow is a priority, so vim will
have to take a low priority to real life but I might manage to mess with it at
night. Once again, thanks for your input.

~~~
johncoltrane
So? How did it go?

