A vague spec for making wmFuzzy more easily configurable
=========================================================

At the minute you have to recompile with the correct language option
included. This isn't great but has some advantages.

1. It keeps the code and general footprint small. wmFuzzy is a
   dock-app; it's not meant to take up resources.

2. It was easy to implement.

3. You don't often want to change the display language. (Though this
   kinda assumes a single user, or at least single locality system).

Ideally I'd like to able to configure it with a file somewhere on the
filesystem, e.g. ~/.wmfuzzyrc.

To do this needs a way of mapping time to configuration lines and then
filling in the blanks.

First step is probably to get rid of all the extra modes where the
granularities are greater than an hour. They were kinda fun and had
the historical significance of being the first patch I'd received for
it but they are also a millstone around the neck of translators and
testers and make for more variability in the display for this.

This leaves us with just the case of displaying the hour and the
offset from the hour. Examples:

----------
07:00	    Seven O'Clock
10:10	    Ten past Ten
06:15	    Quarter past six
03:45	    Quarter to four
18:30	    Half past six
00:00	    Midnight
12:00	    Midday
----------

Probably the first thing to have is a list of hour names

----------
Hour    00      Midnight
Hour	01      One
...
Hour	12	Twelve
Hour	13	One
...
Hour	23	Eleven
----------

Then we want the basic time names. We'll use %h as a while card to
represent the current hour and %H for the next hour (ie. '%h+1').

----------
Match	%h:00   %h O'Clock
Match	%h:05	Five past %h
Match	%h:10	Ten past %h
Match	%h:15	Quarter past %h
Match	%h:20	Twenty past %h
Match	%h:25	Twenty five past %h
Match	%h:30	Half past %h
Match	%h:35	Twenty five to %H
Match	%h:40	Twenty to %H
Match	%h:45	Quarter to %H
Match	%h:50	Ten to %H
Match	%h:55	Five to %H
----------

This actually gets us most of the way there. There are couple of
exceptions that need to be handled.

----------
Match	00:00	Midnight
Match	12:00	Midday
----------

This would also allow people to put fun customizations in if they want to:

----------
Match	17:30	Home time
----------

The problem is now reduced to the relatively trivial one of parsing
the files in the format above and then deciding which matching gets
used in the case of the overrides.

The 'intelligent' option would be say that we use the match that has
the least wildcards in it. The easiest option is to say that the order
of configuration options in the file matters and that we use the
first/last matching option.


Coding this up
===============

We need an array of 24 strings, one for each hour. Read a line if it
matches "Hour" as the first word, read the numeral as the second word
and the string as the rest chopping off any preceding whitespace.

We need a [list/expandable array] for the matches. Read a line if it
matches "Match as the first work, read the pattern as the next
(whitespace delimited) word and the text as the rest, chopping off any
preceding whitespace. Add to the pattern list (depending on how we
want the priority to work we can append or prepend or change the
iteration direction when matching).

To match a time to patterns, we look at each pattern in turn
(iteration direction depends on the priority we want). Substitute %h
for the numeric hour (make sure that hours and minutes are always zero
padded to be two characters). If this is first pattern that matches
then return it.

Then need to substitute the textual hour name in the text pattern.


Error Handling 
===============

We're suddenly reading stuff from a file in C and doing string
manipulation, which means that we really ought to start worrying about
joyful things like buffer overflows. There's probably going to be
slightly more happening in the way of malloc/free so will have to
watch the memory leaks. (Naively I'd say that latter is more important
as wmFuzzy is liable to run for a long time unchecked and I can't see
how it could be used for a hack exploit, but then I'm not a cracker.)

We also have to handle the case of problems with the configuration file.

1. Too many or too few hour patterns: quit dumping a message to stderr.

2. Invalid line format: quit dumping a message to stderr.

3. Can't find a matching pattern: revert to built-in English
   version. (Should possibly use some language other than English so
   it's obvious to me that there is a problem).

At the minute wmFuzzy has no support for changing fonts (It would be
nice to add it at some stage but that means learning more X
programming). As such it is very much limited to displaying four lines
that are no more than eight characters long (think it's eight off the
top my head). Thus there's no point in the hour string or the time
pattern string being particularly long. We can therefore make buffer
handling easier by arbitrarily restricting them to a certain length
and truncating anything that overruns. This gives another error
condition.

4. Text truncated: send a message to stderr but carry on regardless.


Testing
========

It would nice to write a quick test harness that just reads the
configuration file and prints the numeric and textual representations
for each time through out the day. This would make it easier to debug
(diff would become the regression testing tool) and check for
translators.


Going Futher
=============

If we really wanted to you could imagine expanding the syntax to make
the configuration shorter. So you could write

----------
Minute	00	O'Clock
Minute	05	Five
...
Minute	30	Half

Match	%h:00	%H O'Clock
Match	%h:[01-30]      %M past %h
Match	%h:[31-59]	%-M to %H
----------

But this is getting towards serious parsing and that doesn't seem
worthwhile.