How I 
Tom Ryder
Systems administrator
New Zealand
Systems administrator
New Zealand
I’m a systems administrator working mostly on GNU/Linux machines. I started as a web developer. I write pretty much everything longer than a sentence or two in Vim, and have been doing so for about six years. At work I’m on Windows, and at home I’m on GNU/Linux, but since I do most things in either a web browser or a terminal emulator these days, the host operating system tends to matter less.
On a typical day the things I edit include: configuration files; Bash, Perl, and PHP scripts; HTML documents; email messages; and documentation in Markdown, for translation to more office-friendly formats.
For curiosity’s sake I rebuild Vim from the source every morning on
my home machine and my development machine at work with a cron(8) script,
just with the --with-features=huge flag and installed in my home directory.
On the servers I maintain, I just use the packaged version. I try and keep my
configuration working on much older Vim versions.
The whole configuration as at the time of writing is on my cgit instance. It’s pretty thoroughly commented, mostly so I myself don’t forget what any of it does. It hasn’t changed substantially for several years now.
In general, my approach is just turning on all the features I use that Vim
disables or configures conservatively by default, with version and feature
checks so that it still loads without errors on older versions of Vim. I think
the only slightly unusual thing about my configuration is that I don’t see too
many other people who don’t have :set hidden. I prefer having to save a
buffer before putting it into the background.
Something I particularly like is binding Ctrl-C in insert mode to cancel an entire insert operation.
I load plugins with Tim Pope’s
pathogen.vim, and manage them manually
as Git
submodules.
I try not to load too many of them, and often end up not using the ones I do
load and later removing them. I used
fugitive.vim for a while, but stopped
needing it when I learned about git add -e. The only plugins I use daily are
unimpaired.vim and
surround.vim. I call Vim from the
shell and am comfortable with globs and find(1). I don’t even use
netrw.vim, really. In
general, the plugins that seem to stick are the ones that do actual editing of
text. Other functions just end up drifting back into the shell, just a
Ctrl+Z, new tmux(1) window, :!, or :%! away, where they should be.
I use sahara.vim as my colorscheme, which is just my fork of the desert256.vim with a few small things tweaked. I use 256-color terminal emulators everywhere.
I manage my dotfiles with Git, and use a Makefile to install them. It works pretty well.
:help, Vimcasts, and reading .vimrc files on
GitHub. I started with the IRC-based Vim tutorial,
following along with Socrates and Glaucon.
The BigFileMeasures()
function
towards the end of my .vimrc is a relatively recent addition that I wrote when I
got impatient with Vim choking on large log files. It checks that it has the
eval and autocmd features it needs, and then sets up an autocmd hook for
reading a file that checks its size and tweaks options local to the buffer
appropriately. Really, though, the correct solution here is not to view massive
log or data files in Vim at all, and instead to use tools like grep(1) or
ed(1).
The
ToggleBreak()
function is useful for copy-pasting multiple lines of text from a terminal
emulator or tmux(1) window without including the showbreak characters or
extra spaces included by linebreak.
I’ve been writing a fair bit more Bash and Perl lately for tasks related to
system administration, and to get a bit more practice trying to write them
properly. Vim’s support for Perl syntax is great. I can think of only one thing
in modern Perl syntax that it doesn’t highlight correctly at the time of
writing; specifically, on my system it doesn’t detect comments in substitution
patterns with /x, which is a pretty minor thing. Bash doesn’t fare quite as
well, unfortunately, but it still beats ed(1) or nano(1). I don’t really
hold that against Vim, since very few people write decent Bash anyway.