org files and directory hierarchies

org files and directory hierarchies

[Dan Davison]

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

Re: org files and directory hierarchies

[Matthew Lundin]

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

Re: org files and directory hierarchies

[David Lord]

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

Re: org files and directory hierarchies

[Carsten Dominik]

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

Re: org files and directory hierarchies

[David Lord]

[-- 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