From: Dan Davison <davison@stats.ox.ac.uk>
To: emacs org-mode mailing list <emacs-orgmode@gnu.org>
Subject: org files and directory hierarchies
Date: Thu, 8 Jan 2009 15:58:34 +0000 [thread overview]
Message-ID: <20090108155834.GE14694@stats.ox.ac.uk> (raw)
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
next reply other threads:[~2009-01-08 15:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-08 15:58 Dan Davison [this message]
2009-01-08 17:07 ` org files and directory hierarchies Matthew Lundin
2009-01-08 20:40 ` David Lord
2009-01-08 21:33 ` Carsten Dominik
2009-01-09 11:04 ` David Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090108155834.GE14694@stats.ox.ac.uk \
--to=davison@stats.ox.ac.uk \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).