From: John J Foerch <jjfoerch@earthlink.net>
To: emacs-orgmode@gnu.org
Subject: org-attach-directory
Date: Sat, 10 Oct 2015 10:00:08 -0400 [thread overview]
Message-ID: <871td2ygbb.fsf@hecubus.retroj.net> (raw)
Hello,
I have a collection of org files in a git repository, and am using
git-annex for attachments. I had an idea for a feature related to
org-attach-directory that would improve the usability of git-annex in a
case like this.
Since all attachments from all org files in the repo go into the same
data directory, there isn't a simple way to operate on the attachments
related to a single org file in bulk. For instance, if one wants to
git-annex-get all of the attachments for one org file, but not others,
one must git-annex-get each file individually.
One solution would be for each org file to live in its own subdirectory,
thus each org file would have its own data directory:
org-file: org/work/work.org
attachemts-in: org/work/data/
I don't especially like this solution because it adds a lot of
unnecessary structure to the repo.
Another solution would be for each org file to have its own data
directory alongside it:
org-file: org/work.org
attachments-in: org/work.org.data/
I don't especially like this one either because it makes a mess of the
repository root.
The solution I like best is to store attachments in data/, but to
introduce a subdirectory per org file:
org-file: org/work.org
attachments-in: org/data/work.org/
It keeps the repository root uncluttered, but attachments are grouped by
the file that owns them, so can be operated on in bulk by git-annex or
other tools.
I can set up this configuration with org-mode-hook, but I liked the idea
so well that I wanted to pass it along as something that org-mode might
want to provide itself as an option. Perhaps org-mode could check for
the existence of data/{filename} and when it exists, set the local value
of org-attach-directory to that instead of to "data/". If it were
automatic like this, then org files that used this feature would remain
portable. Perhaps a file-local variable or an org directive would be a
better option.
Any thoughts?
Thank you,
John Foerch
reply other threads:[~2015-10-10 14:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871td2ygbb.fsf@hecubus.retroj.net \
--to=jjfoerch@earthlink.net \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.