toothpik's vim page
This is not a site on what vim is, or how to use it - if you find
yourself here with either
of those things in mind, go to the
vim homepage.
This page is more about how to have fun with vim than anything, or
at least how I have fun
with it.
It's also about how to have fun with python and tcl and perl
...and bash, awk, grep, sed, and all the rest.
Here's my
.vimrc, as it existed at at least one point in time
feline section
me and my favorite coding companion
konsole section
I've become a fan of konsole over the years, using it for
almost everything - with
a selection
of directory changing aliases in my
.bashrc I can navigate faster than I can
with the mouse
in dolphin - when I first start konsole (using
sk) I run
mxm, which makes
"x" more konsole
tabs,
or 10 without an argument - I don't show the tab labels, I don't
use a mouse in konsole, and it
is so gloriously easy
to switch between tabs with shift-left
and shift-right
there's no
need for
mouse clickable space
wasting decorations -- with the
sequential titles
created by mxm I know
exactly where I am at all times.
konsole one
on my second desktop I keep my main konsole with 10 tabs. I like
to display current year in the first,
using the imaginatively named 1,
which uses dtyear,
which in turn uses yearws
and tyear
konsole two
here I run
tc6 - tc6 calls
tc4, which calls
tcnlc3, which invokes
bcdit and
trimc on
tocal
resulting in an extract from my calendar being
output to the command line with current date
boxed and positioned on the same row as current date in the cal window
konsole three
in my third konsole I run
3, my countdown reminder module - some of the scripts triggered
by 3 include:
cct - combines bin/ct0, tcl/ct0, and incend.awk to produce the list
ct0 - uses realstuff to cat the dates into nl
ct_list - the list
realstuff - generic "realstuff" text extractor - allows
history to be kept by moving
expired items below
"endrealstuff"
tcl/ct0 - calls jctd to obtain the counts
jctd - generic day counter
incend.awk - verifies the dates are in ascending order
frequently I will use
jatc to calculate a date needed for ct_list
a recent run of ccct looked like
this
konsole four
konsole four is for budgeting - here I track my checking account,
reconcile, and project
into the future - over the years I've used a variety of spreadsheets to
store this data,
and have repeatedly
been frustrated by upgrades to the software making my older data
difficult to get to - the answer
I've come to embrace is ascii text - I cannot imagine a
time when text is unreadable - ok, yes, I can
if I stray into disaster science fiction,
but if we get to that point we won't have banks and checking
accounts anyway - whether
the scripting language that reads it evolves is irrelevant - the data is
the important
thing, and text is the most universally readable format available
by formatting the data in specific columns I enable a variety of
languages easy access
to it - the
FIELDWIDTHS feature of awk springs to mind, but every language I
know can
parse lines of a known format
copying my last spreadsheet I built what I refer to as the "plan"
modules as having this
format
I have defined fiscal months as starting on the 23rd of the
preceding month and ending
on the 22nd - that way there's a full week of lead time for transactions
targeted for the
1st, and the
month starts off clean with the first transactions first - that's
my take on
it, it's my system, so I get to decide
the script I use the most for displaying it is
m
m uses a variable combination of mYY modules to display the
relevant portion of my account,
for example:
{ m12 8; m12 9; } | head -31
will display august and most of september for 2012 - m starts by
running the entire year
(m12)
through
funclear.awk in order to determine whether the first unclear
transaction
occurs in the
same or the previous fiscal month - with this information it can
design
the most relevant display using two of
-
plan1.sed -
plan2.sed -
plan3.sed -
plan4.sed -
plan5.sed -
plan6.sed
-
plan7.sed -
plan8.sed -
plan9.sed -
plan10.sed -
plan11.sed -
plan12.sed
I edit the plan modules by invoking
vp or
gp, which sources
plan.vim as it calls up the
module - any of
planbal.py,
planfood.py, or
prec.py
may be invoked by different <Leader>
mappings defined in plan.vim
when it's time, I make the next year's plan using
plannew, a bash script that combines a
tcl
core, two python scripts, and five perl scripts, most of which
are tailored to my
specific needs, with the exception of
plandsh which puts a line of dashes between months
at the end of the series - driving all this is the
plan_core which is described in the
plan_readme - of note is the last line in the core with description "food &
atm" - the
more accurate you can be in estimating this important item the closer your future
projections will be to reality -
a powerful tool in the quest for accurate food/atm
estimates is a collaboration between
lfy (last fiscal year) and
mft (make food totals)
- ie.
lfy | mft
a recent enhancement to lfy is
cfm (current fiscal month) which makes use of
cfm.awk
and
perl/cfm
another tool that can be used to aid in estimating gas or electric bills
is
ept
(mnemonic examine previous transactions)
konsole five
konsole five gets to display the "head before equal" of my visa
charges module
using
hbev which makes use of
sae.awk
konsole six
konsole six is for batteries - the display is with
ba - scripts triggered by ba include
b2 - main battery age tracking script
hoirb - how old is raney's battery
mb
- mouse batteries
tpr - raney's tire pressure check script
tpk - road king tire pressure check script
with this system the batteries in the thermostat never die, and I
never pick up a remote
or flashlight that has dead batteries - with these yearly
replacements, I always have a
good supply of "used" batteries for my cordless mouse and
every-day-carry flashlight
vim build konsole
cd7 (~/.build/vim) - here I start with dp, my "dangerous
path" function defined in .bashrc
that adds $(pwd) to the beginning of $PATH, because all my vim
build scripts are here -
next I may just do an
hl and move on, or, if Bram's been posting patches in
vim_dev
I will start an update/build process
the first script run by hl is
hlsb, which runs both
hlslt and
hlsld, making use of ee
along the way - the purpose of all this is to run
t, which at its core performs an
'hg incoming' against the vim repository - all the 'hls_' modules
test "how long since"
the last empty 't' or the last data hit - I don't want to unduly
stress the server,
especially when there's no cause to believe any patches have been
uploaded, so my rule
is to not 't' any more often than once every 10 hours
there are three main scripts to update:
u (to get),
u2 (merge), and
u3 (commit) - u2
makes use of
cs to determine what to merge - these are all I need to update the vast
majority of the time - however there are times the stinking tags module throws a monkey
wrench into the works and u2 fails - for these rare occasions I trot out u3t which performs
a commit with a message about tags and how happy I am they are included, then I run
u2 with the result of cs2 as its argument,
then the final u3
m makes vim, but if somehow configure got triggered I'll cancel
it and run
myconfig
so buildsize and compiledby get defined - it is finding GTK2 with
no help from me
and
sudo i installs
konsole ten
On my last konsole tab I perform cdb and dp, both defined in .bashrc, in preparation
of a mail window. Before I start the fetchmail daemon I check the two log files size
with
hb - if they are running amok I use
cfl and
cpl as needed
It's only natural for fans of vim to be fans of
mutt as their mail client of choice, and I
am no
exception. Some of the scripts I use to support my email session follow:
cr - "check received" is the mnemonic here
crr - check received and touch lamda
ccr - the workhorse that displays mail folders updated today, sorted on time
ccr.awk - puts commas in the size field
laflp - look at fetchmail log and predict the time of the next fetch
leftovers
Item - I hope this
copyright link never breaks
Item - Daylight Saving Time is evil - you can help - sign the petition
at
standardtime.com
Item - It is wrong, our system is just wrong, when our government makes
it illegal to sell
cars that get over 78 miles per gallon - VW makes them here, but can't sell them
here
- the rant I am quoting (
youtube ) says it's because we maintain our roads with taxes on
gas and don't want to lose the money
let's hope that logic doesn't stop the Elio from coming out
Item - if you want to read a well written but scary book, pick up a copy of "This Changes
Everything" by Naomi Kline