[sorry for the dupe, forgot to cc the list on first shot] Jan,
thanks for sharing your setup, which got me intrigued. Is there a place where a interested person can take a look at your (org-) configuration-files, esp. the two template-sources you mentioned? Thanks, Claus On Sat, Apr 10, 2010 at 1:31 AM, Jan Böcker <jan.boec...@jboecker.de> wrote: > [The following text has gotten quite long. Sit comfortably and get a cup > of your preferred drink if you want to proceed.] > > That is an interesting setup you describe there. I had considered > something similar myself, but found it a hassle to come up with a file > name for every new piece of information (although unix does allow > everything except "/" in a file name, I want my file names to be lower > case, short and without spaces where feasible). > > To paraphrase what you said, putting things into files just makes you > loose time thinking about file names (which I also consider structure). > > In the end, I settled upon one big org file ("reference.org"). Each > piece of reference information is in its own top-level node. When I want > to find something there, I use isearch and/or search for a specific tag > (in virtually every case, a simple isearch for one or two words is > sufficient). > > This is way faster than navigating the file system! I also share your > dislike of categories (which a strictly hierarchical file system would > force me to use). > > I have two remember templates to add an entry to reference.org. > > The first template asks me for tags ("%^g") and a title for the > headline. After filing it (at the top of reference.org) with C-c C-c, > Org jumps to the location it was just filed ("%&" in the template), in > case I want to use C-c C-c again to readjust the tags. > > I use this first template to keep data that can be expressed in plain > text (including all the powerful tools Org gives me to work with plain > text, such as outlines, links and tables). > > The second template is a little more complex; it calls a custom elisp > function to do all the work. > > When I call this second template, I am asked for the following: > - a title for the headline > - a date (I mostly use this template to file scanned letters, invoices > and the like, so it helps to be able to change the date from the default > of today.) > - a folder name (defaulting to YYYY-MM-DD.S, i.e. the previously > specified date followed by a sequence number to make the folder name > unique). Normally, I do not customize the folder name, because I only > need to find the reference data via Org and do not need to navigate to > it using e.g. the "open" dialog of any other program (and I do not want > to change it in the future, which might make a folder name containing a > date obsolete). > - where the original went (defaults to "Trash"). This is stored as an > attribute in the outline node. > > A new subfolder with the specified folder name is created in ~/org/data/ > and set up as this node's attachment directory. The ID of the node is > set to data-<folder name>, so I can link conveniently to this entry from > project notes. > > The custom elisp function also installs a hook that automatically calls > org-attach-attach-mv if I try to file the template without having added > any attachment, so I do not forget this. > > I use this second template when I have to attach a file to the entry, > because it cannot be represented in Org. This mostly applies to scanned > paper of any sort (letters, invoices, etc). > > I have a shell script which I use to scan directly to PDF files (I do > not use OCR, the PDF just serves as a container for possibly multiple > scanned pages, so that browsing and printing the whole document is > convenient). > > If it was an important document where I might need the original in the > future, I specify "Filed" when asked where the original went, write the > folder name/ID number in the top right corner of the document with a > pencil (in case of very important documents or certificates I use a > post-it note), and file it on top of a normal paper file folder. > When keeping the original, I do not change the folder name from its > default. Should I have to dig out the original for any reason, I can > manually execute a binary search on my chronologically sorted file > folder(s). > > I have been using this system for a few weeks now, and it has worked > great so far. Its main design goal was not simplicity of implementation, > but simplicity of use: it has to be so simple (and require as few > decisions as possible) to file something that I actually do it instead > of postponing it. > > The system actually evolved along with the aforementioned shell script > for scanning while I was scanning and filing about 20 exercise sheets > (about four to twelve pages each) from the last semester to access them > conveniently when preparing for the exams. > > I also noticed a while ago that very long org files become less > intimidating once you learn to love C-x n s (org-narrow-to-subtree), > which helped with my decision for one big file over many small ones. One > big file also avoids cluttering the buffer list. > > - Jan, > who really should start a blog to do more detailed write-ups of this > and similar things, because they are so much fun to write. > > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode > _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode