== My growing entanglement into _vi_

It started with [[_vi_ becoming my sysadmin's editor
../sysadmin/WhyViForSysadmins]], the editor that I used for quick
edits because it was everywhere, worked in minimal environments, and
it started fast. But of course it didn't stop there. Any good tool has
a virtuous circle where more use makes you more familiar with it and
thus makes it easier to use so you use it more; [[_vi_ goes well beyond
that in terms of rewarding extended use LikingVi]].  Vi's march into my
editing life has not been fast but it's feeling more and more relentless
as time goes by, especially when I do things like specifically configure
[[git http://git-scm.com/]] to use _vi_ instead of my normal default.
I'm not using _vi_ pervasively quite yet, but increasingly my major
holdout (writing email in my full email environment) feels a little bit
awkward.

(My normal default _$EDITOR_ is a script that tries to intelligently
pick the editor to use based on my current environment based on
things like whether or not I have [[X
http://en.wikipedia.org/wiki/X_Window_System]] available.)

This has not fundamentally changed my view of _vi_ as a whole (it
remains not my favorite editor). I am simply being seduced by
convenience and familiarity, and running into the limits and issues
in [[my major other editor ../tech/EditorDifferences]]. Not that _vi_
is bad (rather the contrary), but I still miss things from my other
editors and often would sort of prefer to be using them.

(Possibly this attachment to my major other editor is just emotion
speaking.)

While I've been additional learning _vi_ (well, _vim_) features slowly
over time, I still have not really attempted to become solidly familiar
with Vim's advancements over the core _vi_ editing commands (I'm going
to wave my hands about the reasons why, but see above about _vi_ still
not being my favorite editor). If I get more seriously into _vi_, and it
seems inevitable that I will, I should probably change that. My obvious
weak areas are the areas where _vi_ itself is weak: working fluidly
with multiple files and also with split screens for editing two files
simultaneously. Mastering doing this in Vim would remove one significant
reason that I revert to other editors.

(I will probably always edit Python, C, and Go code in GNU Emacs when I
have a choice. But there is a fair amount of other multi-file work that
would at least be more convenient if I knew what I was really doing in
Vim.)

I know that Vim has a universe of advanced text movement and text
manipulation commands but I'm honestly not sure that I feel much
interest in learning them. The mere fact that there is a universe of
them is kind of daunting and I have no confidence that they'd speed up
the sort of editing work that I do very much. Probably some of them
would, so I suppose I should at least glance over the list to see if
anything stands out.

(This has come out more rambling and thinking aloud than I thought it
would. I do think that there's something interesting about how _vi_ has
wormed its way into my computing life as more and more the editor I
reach for, but I don't have the words for it right now.)