== Programming fun

Programming fun is spending a couple of hours writing, revising, and
tuning a DWiki feature that I'm not sure I'm actually going to like well
enough to keep.

I'm serious, not being sarcastic; I like programming, but not all ideas
for improving a program pan out. An idea that seems great in my mind can
be less attractive once I've made it concrete and explored all of the
bits that I could gloss over when it was just thought-stuff. So I can
spend a pleasant and enthused couple of hours and wind up with something
I may end up just throwing away (well, sticking on a back shelf in case
I get a clever idea about how to improve it).

Python is a good language for doing this sort of thing in, since it
requires very little annoying make-work. It's one thing to materialize
my ideas and discover that they don't pan out, but it'd be an entirely
different thing to have to slog through a lot of grit for no purpose. (Or
to put it another way: the more un-fun involved, the more I'd need to
get something useful out of it.)

=== Sidebar: today's nascent DWiki feature

I'm tired of having to write [[x86_64|]] as ![[x86_64|]] most of the
time, and [[yesterday's entry ../linux/Dell2950USBProblem]] has
raw text that looks like:

>  [[atkbd_connect|]] {{C:rarr}}
>  [[atkbd_activate|]] {{C:rarr}}
>  [[i8042_interrupt|]] {{C:rarr}}
>  ...

One of my guiding principles for DWikiText is that it has to look
attractive and natural in raw text; this is clearly not happening with
either example. My first idea is 'processing notes', in a form stolen
from [[*roff|]]:

>  .pn no _ sub -> {{C:rarr}}
>  
>  atkbd_connect -> atkbd_activate ->
>  i8042_interrupt -> ...

I'm not sure that I like this format for processing notes (or even the
name), plus it doesn't really improve writing [[x86_64|]] once or twice
in an entry, plus it turns out to have some unaesthetic consequences; the
only good way to do the text substitutions right now makes them affect
things like URLs (which are in the text but not actually text).