This won't make much sense unless you've read the page explaining what the macros mean.
Here is the default Options file for Diary (accessible by clicking the Config button);
# version version=0.06 # locations journal_dir=<diary$dir>.^.Diary fragment_dir=<diary$dir>.^.Diary.fragments script_dir=<diary$dir>.^.Diary.scripts output_dir=<diary$dir>.^.Diary.Output # Journal naming formats journal_year=%ye journal_month=%mo journal_day=%dy # entry creation newentry=NewEntry newentry_script=True # default script file script=Example1 # window date format title=%we, %zdy%st %mo %ye. title_entrypath=False # built in expansions meta=<meta name="generator" content="!Diary v%ve"> comment=<!-- Created with !Diary v%ve --> # No of years to keep in index maxyears=5 # No of hours past midnight to revert to previous date. overlap=0 # Debugging options debug=False log=RAM::RamDisc0.$ verbosity=1 # valid values; 0-3 #end
This file is rather pointless in that it just contains the default values that the program uses if it can't find an options file. Also, if the options file does not contain all the settings defined above, any missing ones will have the default values shown.
The basic format is fairly self explanatory - any line starting with a '#' character is ignored, and the other lines are simply of the format 'variable=value'. Trailing or leading spaces are ignored, as are spaces around the '='. The variable names are not case sensitive.
Here's what the variables mean, assuming the application has been installed as
1: The options file reader will understand any of N,No,0,False,Off or Y,Yes,1,True,On, and is not case senstive.
The journal directories are created as required, so when I click on the 'edit' button with the date display on, say, the 2nd of May, it checks to see if the directory specified by 'journal_dir' exists, then the year subdirectory (having expanded the macro to whatever format you've specified), then the month subdirectory (again, expanding them macro), and then either copies the fragment to it (from the fragments directory) or runs the script to generate the output with the name according to the day format you've specified. In this case the file NewEntry would be copied to
If copying a fragment, the newly created entry ends up with the same filetype as that fragment. If the new entry is generated by a script, that script must define the filetype (otherwise the entry will end up typed as raw data). Note that a new entry fragment would have to be placed in the fragments directory, while a new entry script would go in the scripts directory . . .
It's probably easiest to play around with this, and see what happens.
The script variable defines the name of the default script file to be used when you click on 'Make' (although other scripts can be selected from the main window).
The maxyears variable defines how far the buttons that move forward and back between entries should search until they give up. This should always be an odd number, greater than three - the reason being that it will search up to maxyears/2 forward from the current year, or maxyears/2 backwards. The default of 5 should be adequate for normal use, but if you omit keeping a journal for some years, and then start again (i.e. there are lengthy gaps with no entries in them), then you may want to increase the setting. (This will ultimately have implications on the memory requirements - you may need to increase the application wimpslot specified in the !Run file inside !Diary if setting maxyears to a large value).
The other variables should be self-explanatory, except possibly for the 'overlap' variable;
I generally write my diary entries last thing at night, before I head for bed. This often means that I am editting them close to or after midnight, and it can be annoying for Diary to suddenly start behaving as if the date was 'tomorrow'. Of course, the date actually is right, but I want to write the entry for what is strictly speaking yesterday. The overlap variable can be set to a number of hours after midnight during which Diary will default to one day earlier for diary entries (although other information referred to within the Script file may use the actual date). Typically I set this to '2' which means that if starting Diary between midnight and 2am on the morning of the 3rd for example, Diary will pretend that it is actually the 2nd.
This feature is a lot easier to use than to explain . . .
Diary only reads the current date on start up, it doesn't do anything if left running beyond midnight.
The debugging options should only be used if you hit a problem and need to send me information - the higher verbosity levels can generate large files, and as they append to these files in small chunks, the disk activity generated can be large (particularly as the script may be similarly appending small chunks of data to another file elsewhere on the disk surface, and these operations are being interleaved). For this reason, the default log file location is the RAMdisc, however you need to have created one manually first.
Meanwhile, to actually do anything useful with it, you'll need to know about how the script file works . . .
However, first, a quick note on configuring Diary to work with other Journal keeping applications;
To configure it for use with Organizer, you would need the following settings;
Journal_dir=[path to journal directory - this is inside Choices by default] journal_year=%ye journal_month=%mn journal_day=%dy
To configure it for use with Journal, you would need the following settings;
Journal_dir=[path to journal directory - this is inside <journal$dir> by default] journal_year=%ye journal_month=%m3 journal_day=%zdy/%m3
To configure it to keep all the entries in a flat directory structure;
Journal_dir=[two directories above the actual directory you want] journal_year=[static dirname] journal_month=[static dirname] journal_day=%ye_%mo_%dy [or whatever, as long as the names are unique]
In the latter case, the year and month entries would not actually contain macros, but would be constant, and the day format would need to contain macros for the year, month, and day in order to ensure that two entries wouldn't end up with the same name. The filing system would need to support large numbers of files per directory.