I was starting to wonder about the relationship between the hierarchy defined by org files, and the file system hierarchy. This is just thinking out loud really. In fact that might be a generous description of a very vaguely-thought out idea. It is obviously a very standard situation that a file exists that is related to (a) heading(s) in (an) org files(s). And org provides the file link for dealing with this situation. But where does one store the file? The obvious answer is "in the relevant directory". Which implies that in addition to manually curating the structure of your org-files, you are also manually curating an appropriately-structured directory hierarchy. Fair enough; that is what people do with computers, except for those that stick everything on the desktop until they can't find anything... But perhaps there's an alternative, hard-line, org position? This would say something like: My org files are real. My directory hierarchy is merely a manifestation of my org files. So is there any future in thinking about an org extension that would automatically maintain a directory hierarchy, mirroring the hierarchy of headings in certain org files? For example, at the moment, one of my org files contains an entry saying I have to travel somewhere. I want to keep the pdf itinerary somewhere sensible. Here are two options that occur to me: (i) I lamely maintain some sort of meaningful directory hierarchy, perhaps ~/travel/year/month/, or perhaps ~/work/project/travel/, put the file in the relevant place, and make a file link in org. (ii) I throw all such files in a single directory, and rely on org links. But if the structure of org is truly reflecting the structure of my life / thoughts, then wouldn't it make sense for the structure of my directories to be doing that too? If so, then the job of maintaining the correspondence between org and the directory hierarchy should be left to the computer. This would give rise to an org which is a text-based "map" of ones working directories, with org files providing semantics and metadata to the directory hierarchy and its files. The directory hierarchy could be edited by org's structure editing commands. Etc. ... or maybe not. Was there any sense in the above? Perhaps others have already found good solutions to this. Personally I have org files and directories relating to the same subject with some sort of vague but messy correspondence between their structures. Dan -- http://www.stats.ox.ac.uk/~davison
Hi Dan, Dan Davison <davison@stats.ox.ac.uk> writes: > > So is there any future in thinking about an org extension that would > automatically maintain a directory hierarchy, mirroring the hierarchy > of headings in certain org files? > > But if the structure of org is truly reflecting the structure of my > life / thoughts, then wouldn't it make sense for the structure of my > directories to be doing that too? If so, then the job of maintaining > the correspondence between org and the directory hierarchy should be > left to the computer. Good news. Something like this already exists: http://orgmode.org/manual/Attachments.html#Attachments > This would give rise to an org which is a text-based "map" of ones > working directories, with org files providing semantics and metadata > to the directory hierarchy and its files. The directory hierarchy > could be edited by org's structure editing commands. Etc. One caveat. Org attach doesn't work in quite this way. The data directory hierarchy isn't really human readable (i.e., it doesn't mirror the org outline hierarchy). But that would be a nightmare to make work, I imagine, because of constant changes to the org outline structure. Rather, directories containing files are attached to outline headings via automatically generated IDs. - Matt
On 8 Ion 2009, at 17:07, Matthew Lundin wrote:
>
> One caveat. Org attach doesn't work in quite this way. The data
> directory hierarchy isn't really human readable (i.e., it doesn't
> mirror the org outline hierarchy). But that would be a nightmare to
> make work, I imagine, because of constant changes to the org outline
> structure. Rather, directories containing files are attached to
> outline headings via automatically generated IDs.
Well, why not allow the user to choose a directory, there's no real
reason why the directory structure has to match the org file?
I started using attachments when the feature came out and really
liked them, especially the simple interface for choosing a file to
attach (even better with ido). But after a while, I found the fact
that I could only reasonably get to attachments through the org file
difficult to work with - what happens when I've finished a task and
archived it off? I've got to go hunting through the archive file to
find the old task before I can find the attachments. So I stopped
using them and decided I'd use normal hyperlinks instead. But then I
found out just how awkward is is to have to either cut-and-paste the
directory path or type it in manually whenever I want to link to a file.
Regards
David Lord
On Jan 8, 2009, at 9:40 PM, David Lord wrote: > > On 8 Ion 2009, at 17:07, Matthew Lundin wrote: >> >> One caveat. Org attach doesn't work in quite this way. The data >> directory hierarchy isn't really human readable (i.e., it doesn't >> mirror the org outline hierarchy). But that would be a nightmare to >> make work, I imagine, because of constant changes to the org outline >> structure. Rather, directories containing files are attached to >> outline headings via automatically generated IDs. > > Well, why not allow the user to choose a directory, there's no real > reason why the directory structure has to match the org file? > > I started using attachments when the feature came out and really > liked them, especially the simple interface for choosing a file to > attach (even better with ido). But after a while, I found the fact > that I could only reasonably get to attachments through the org file > difficult to work with - what happens when I've finished a task and > archived it off? I've got to go hunting through the archive file to > find the old task before I can find the attachments. So I stopped > using them and decided I'd use normal hyperlinks instead. But then > I found out just how awkward is is to have to either cut-and-paste > the directory path or type it in manually whenever I want to link to > a file. Did you see Matt' answer in the other thread? That will also work for you. - Carsten http://thread.gmane.org/gmane.emacs.orgmode/10330/focus=10331 > > > Regards > David Lord > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 385 bytes --] 2009/1/8 Carsten Dominik <dominik@science.uva.nl> > > Did you see Matt' answer in the other thread? That will also work for you. > I did, and it does work thanks. I've had some difficulty with it previously because I use viper, which rebinds C-u unless you're in insert state. > > - Carsten > > http://thread.gmane.org/gmane.emacs.orgmode/10330/focus=10331 > Regards David Lord [-- Attachment #1.2: Type: text/html, Size: 1310 bytes --] [-- Attachment #2: Type: text/plain, Size: 204 bytes --] _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode