From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Jan_B=F6cker?= Subject: Re: My reference data management approach with org and emacs Date: Sat, 10 Apr 2010 01:31:12 +0200 Message-ID: <4BBFB8C0.8070208@jboecker.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0NfZ-0007so-KC for emacs-orgmode@gnu.org; Fri, 09 Apr 2010 19:31:25 -0400 Received: from [140.186.70.92] (port=36112 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0NfX-0007s8-TA for emacs-orgmode@gnu.org; Fri, 09 Apr 2010 19:31:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0NfV-00045e-IM for emacs-orgmode@gnu.org; Fri, 09 Apr 2010 19:31:23 -0400 Received: from mail7.worldserver.net ([217.13.200.27]:56121) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0NfV-00045R-61 for emacs-orgmode@gnu.org; Fri, 09 Apr 2010 19:31:21 -0400 In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Marcelo de Moraes Serpa Cc: Org Mode [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-, 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.