Feb. 7th, 2012
Org mode epiphany...
Feb. 7th, 2012 11:08 amOrg mode in Emacs has what's called a "capture" mode that makes it dead easy, i.e., fast, to add TODO items, notes, and whatnot to one's database using a set of default templates. In my setup, for example, every time I enter a new TODO, the software captures the date on which the item was entered, which comes in handy in figuring out what items have been lying around and are starting to smell.
Part of a template definition is to specify what file a captured item is saved in by default, which in most setups (including mine) is a file called refile.org. The idea here is not having to spend time figuring out where to put the blessed thing while you're creating it, and instead, to schedule a few minutes on a regular basis to review the items to be refiled and move them where they belong.
Well, what I am noticing is that a heck of a lot of TODO items are getting retired in place (i.e., before they got moved).
This, in turn, makes me wonder just how much organization my database needs.
* * * A long time ago, I realized that having a framework within which to store data—arranging words alphabetically in a dictionary, for example—really only makes sense for one reason: to be able to reliably find a definition in said dictionary later.
And while this may seem pretty obvious, a long-ago program called Tornado Notes (which later became InfoSelect) made me realize that quite a bit of such structure really isn't necessary if you have other means of fetching information.
At its heart, InfoSelect allowed you to create windows that you would fill with as much or as little text as you wanted, on whatever subject, in whatever format. I had one file that was devoted to contact information, and what I really liked about it was how the program didn't care whether I had just a first name and a phone number or the whole shebang (name, nickname, job title, company, work address, home address, however many phone numbers, a physical description, the name of the significant other, birthday, etc.), because ultimately it really didn't matter what was in these windows.
Where InfoSelect absolutely scintillated was in finding stuff. The search capability in the 1.0 product narrowed down your search faster than you could enter what to search for.
This made InfoSelect particularly useful for creating glossaries without having to worry about alphabetizing lists or filling in fields that I might not have information for. A window in my glossary file might or might not have an abbreviation along with its expansion, and it might or might not have a reference to the client or document associated with the addition of the term.
And there was no rule that said "one item per window," either. I still remember an item I created listing about six or seven different types of common trees, with their translations, which serendipitously turned out to have been a good idea because whenever trees were cited in the environmental impact documents I used to work on in those days, there would invariably be a list of tree types, which I had already taken captured in the item.
Later versions of the program introduced a lot of complexity that, in my opinion, bloated the software and made it harder to use on later systems.
* * * So here I am, trying to figure out the best way to organize my org files. Besides the refile file, I have a file to keep track of my translation assignments, a "sandbox" file (in which to try stuff out), a terminology file (for new terms and definitions), and a sort of catch-all for everyday business.
I'm thinking the latter and the refile file ought probably be the same file.
Cheers...
Part of a template definition is to specify what file a captured item is saved in by default, which in most setups (including mine) is a file called refile.org. The idea here is not having to spend time figuring out where to put the blessed thing while you're creating it, and instead, to schedule a few minutes on a regular basis to review the items to be refiled and move them where they belong.
Well, what I am noticing is that a heck of a lot of TODO items are getting retired in place (i.e., before they got moved).
This, in turn, makes me wonder just how much organization my database needs.
And while this may seem pretty obvious, a long-ago program called Tornado Notes (which later became InfoSelect) made me realize that quite a bit of such structure really isn't necessary if you have other means of fetching information.
At its heart, InfoSelect allowed you to create windows that you would fill with as much or as little text as you wanted, on whatever subject, in whatever format. I had one file that was devoted to contact information, and what I really liked about it was how the program didn't care whether I had just a first name and a phone number or the whole shebang (name, nickname, job title, company, work address, home address, however many phone numbers, a physical description, the name of the significant other, birthday, etc.), because ultimately it really didn't matter what was in these windows.
Where InfoSelect absolutely scintillated was in finding stuff. The search capability in the 1.0 product narrowed down your search faster than you could enter what to search for.
This made InfoSelect particularly useful for creating glossaries without having to worry about alphabetizing lists or filling in fields that I might not have information for. A window in my glossary file might or might not have an abbreviation along with its expansion, and it might or might not have a reference to the client or document associated with the addition of the term.
And there was no rule that said "one item per window," either. I still remember an item I created listing about six or seven different types of common trees, with their translations, which serendipitously turned out to have been a good idea because whenever trees were cited in the environmental impact documents I used to work on in those days, there would invariably be a list of tree types, which I had already taken captured in the item.
Later versions of the program introduced a lot of complexity that, in my opinion, bloated the software and made it harder to use on later systems.
I'm thinking the latter and the refile file ought probably be the same file.
Cheers...