TkCodex does not require a configuration file, but it does look for one (~/.tkcodex-config). If it exists, it should be something like this:
show directory: /home/user/NOTES/tkcodex bookmarks: /home/user/NOTES/tkcodex/bookmarks a comment, if you want geometry: 1264x750+0+0 sub: c,h=(^)(\w+\s\w+)\( no follow
Since you are at least an aspiring computer programmer, you should understand this format does not require any extra spaces, including at the end and especially the beginning of the line, or TkCodex may ignore it. For example,
geometry: 1264 x 750 + 0 + 0
Can cause an error. If you run TkCodex from a terminal, you can get some info about your configuration by including show on a line by itself. All lines after "show" will produce some output, and the final status of some options will also appear:
TkCodex: using /home/user/.tkcodex-config for configuration... note directory: "/home/user/NOTES/tkcodex" bookmark file set to "/home/user/NOTES/bookmarks" geometry: "1264x750+0+0" subroutine regexp for "c,h": "(^)(\w+\s\w+)\(" Follow softlinks turned OFF Configuration set: note directory: "/home/user/NOTES/tkcodex" geometry: "1264x750+0+0" subrountine regexp for "c,h": "(^)(\w+\s\w+)\(" subrountine regexp for "pl": "(^\s*sub )(\w+)\s*{" bookmarks: "/home/user/NOTES/bookmarks"
By default, TkCodex uses ~/tkcodex as the note directory. If it does not exist, you can't save notes. Also by default, it looks in the "note directory" for a bookmark file named tkcodex.bookmarks, but you can give it a different name and even a different path if you want.
The geometry refers to the view windows. These are designed to be approximately 1200x800 (the default) or larger. Your window manager decorations are not taken into account with perl/tk, so you will probably have to tinker with this number to get a correct fit. The smallest size at which the view windows will remain usable is 1050x600 and TkCodex will reject geometry specs below this limit.
As previously mentioned, TkCodex provides subroutine (or function) indexing for .c, .h, and .pl files. Using the configuration file, you can modify the way this is done and create indexing methods for other languages as well. This requires a perl regular expression. The default for for .c and .h is (^)(([\w\*]+\s)+\(.*\))\s{, the default for .pl is (^\s*sub )(\w+)\s*{. You might notice that these both contain TWO substrings, although with the C model, the first substring matches the beginning of the line (^) and no more content. This is because the actual tag which appears in the index is the second substring. Using a first substring allows us to eliminate the superfluous "sub" in languages (like perl) that require such a keyword. Since in C the function type is informative, we leave it in the second substring, (([\w\*]+\s)+\(.*\)), so the C function index looks like this:
In other words, you must have the two substrings, even if the first one is just (^). As a further example, if you wanted to create a match for javascript functions in html files, you could add the following line to the configuration file:
sub: html=(^function)\s(\w+\s\([\w,\s]*\))\s{
The two substrings are in red. It is a drawback that you can only have one regexp per filetype, and this one may not match php functions which are also in .html files -- but, in this case at least, you should be able to figure one out which will. To make the task somewhat easier, TkCodex ships with a short command line program, regexptester.pl which will tell you right away whether your regexp will work or not. It asks for a couple of lines of input, gives you an answer, and asks again:
sample sub format: function this (that,then) { regexp: (^function)\s(\w+\s\([\w,\s]*\))\s{ function this (that,then) { contains (^function)\s(\w+\s\([\w,\s]*\))\s{ the index will be "this (that,then)" sample sub format:
"regexptester" uses a line history, so you can flip back to your previous tries and modify them if you fail. A sure way to know your regular expression is a bad one is if regexptester faults with a message beginning Unmatched ) in regex; marked by <-- HERE. Less drastic mistakes are like this:
sample sub format: function this (that,then) { regexp: ^function\s\w+\s\([\w,\s]*\)\s{ function this (that,then) { contains ^function\s\w+\s\([\w,\s]*\)\s{ but you don't have a valid 2nd substring!
In the future, TkCodex may include an "on the fly" method for changing the subroutine regexp, since with only one per file type, it may be difficult or impossible to come up with a perl regular expression which matches all of the ways you can legally indent and space a function preamble in C. The defaults and the examples here all presume that the definition begins with no indent, for example. In reality, people usually stick to one style throughout an entire script, and you can keep several flavours in your configuration file to choose between later -- TkCodex ignores unrecognized lines or anything that's indented, so all you have to do is change "xsub:" back to "sub:" to make it work. You can include as many filetype extensions as you want in the model, separated by commas with no spaces.
If you put "no follow" on a line by itself, TkCodex's recursive directory tree lookups will not follow symbolic links, since this may cause a circularity problem.
One possibility created by the configuration file is that of swapping in a different ~/.tkcodex-config when you find it easier to maintain separate sets of notes, with separate sets of bookmarks and subroutine highlighting criteria.