[-- Attachment #1: Type: text/plain, Size: 120 bytes --] Is it possible to make attachment-folders move with the headings when refiling them to other locations? Regards Gustav [-- Attachment #2: Type: text/html, Size: 138 bytes --]
Hi Gustav,
Gustav Wikström <gustav.erik@gmail.com> writes:
> Is it possible to make attachment-folders move with the headings when
> refiling them to other locations?
I'm not sure what you mean.
Can you give an example?
--
Bastien
[-- Attachment #1: Type: text/plain, Size: 939 bytes --] Hello Bastien! To clarify a bit. Lets say I have a file c:\temp\agenda.org (I'm calling it file 'a'). When marked with TODO item: done, headings in this file are archived to another file called c:\temp\archive\agenda.org_archive ('b') If i use C-c C-a to attach a file to a certain topic in 'a' and then refile this topic to 'b', when done the attachment still resides in c:\temp\data and will not be found when looking at the attachment in 'b'. Thus my question is if it is possible to also refile the attachment so the attachment-folder resides in c:\temp\archive\data and is avaliable in 'b'? /Gustav 2011/7/15 Bastien <bzg@altern.org> > Hi Gustav, > > Gustav Wikström <gustav.erik@gmail.com> writes: > > > Is it possible to make attachment-folders move with the headings when > > refiling them to other locations? > > I'm not sure what you mean. > > Can you give an example? > > -- > Bastien > [-- Attachment #2: Type: text/html, Size: 1507 bytes --]
I use org-attach regularly and consider it to be a great feature of
org-mode. Since I only attach to the sub-tree (instead of to a different
file) I have not this problem. However, sometimes a set the attach
directory of two different headings to the same folder (when it makes
sense) and if org always moved the attached files it would break the other
sub-tree.
An alternative is to change the attach directory in the archived entry to
point to the original attach directory where the files are. When archiving
to a file in a different folder org could ask if it should also move the
attached files or simply change the attach directory accordingly (I would
prefer this as the default if "ask" as the default was considered too
annoying).
--
Darlan
At Fri, 15 Jul 2011 16:55:06 +0200,
Gustav Wikström <gustav.erik@gmail.com> wrote:
>
> [1 <text/plain; ISO-8859-1 (quoted-printable)>]
> Hello Bastien!
>
> To clarify a bit. Lets say I have a file c:\temp\agenda.org (I'm calling it
> file 'a').
>
> When marked with TODO item: done, headings in this file are archived to
> another file called c:\temp\archive\agenda.org_archive ('b')
>
> If i use C-c C-a to attach a file to a certain topic in 'a' and then refile
> this topic to 'b', when done the attachment still resides in c:\temp\data
> and will not be found when looking at the attachment in 'b'.
>
> Thus my question is if it is possible to also refile the attachment so the
> attachment-folder resides in c:\temp\archive\data and is avaliable in 'b'?
>
> /Gustav
>
> 2011/7/15 Bastien <bzg@altern.org>
>
> > Hi Gustav,
> >
> > Gustav Wikström <gustav.erik@gmail.com> writes:
> >
> > > Is it possible to make attachment-folders move with the headings when
> > > refiling them to other locations?
> >
> > I'm not sure what you mean.
> >
> > Can you give an example?
> >
> > --
> > Bastien
> >
> [2 <text/html; ISO-8859-1 (quoted-printable)>]
>
[-- Attachment #1: Type: text/plain, Size: 2541 bytes --] Ok. I would really like attachments to be integrated with refiling though even if it was a non-default option. Another feature that could improve the use of attachments is to allow links to the attached folders also via the C-c C-l interface in a similar way as stored links (C-c l ). I.E to get the attachment-folder as an item in the C-c C-l buffer with TAB-completion. regards G 2011/7/16 Darlan Cavalcante Moreira <darcamo@gmail.com> > > I use org-attach regularly and consider it to be a great feature of > org-mode. Since I only attach to the sub-tree (instead of to a different > file) I have not this problem. However, sometimes a set the attach > directory of two different headings to the same folder (when it makes > sense) and if org always moved the attached files it would break the other > sub-tree. > > An alternative is to change the attach directory in the archived entry to > point to the original attach directory where the files are. When archiving > to a file in a different folder org could ask if it should also move the > attached files or simply change the attach directory accordingly (I would > prefer this as the default if "ask" as the default was considered too > annoying). > > -- > Darlan > > At Fri, 15 Jul 2011 16:55:06 +0200, > Gustav Wikström <gustav.erik@gmail.com> wrote: > > > > [1 <text/plain; ISO-8859-1 (quoted-printable)>] > > Hello Bastien! > > > > To clarify a bit. Lets say I have a file c:\temp\agenda.org (I'm calling > it > > file 'a'). > > > > When marked with TODO item: done, headings in this file are archived to > > another file called c:\temp\archive\agenda.org_archive ('b') > > > > If i use C-c C-a to attach a file to a certain topic in 'a' and then > refile > > this topic to 'b', when done the attachment still resides in c:\temp\data > > and will not be found when looking at the attachment in 'b'. > > > > Thus my question is if it is possible to also refile the attachment so > the > > attachment-folder resides in c:\temp\archive\data and is avaliable in > 'b'? > > > > /Gustav > > > > 2011/7/15 Bastien <bzg@altern.org> > > > > > Hi Gustav, > > > > > > Gustav Wikström <gustav.erik@gmail.com> writes: > > > > > > > Is it possible to make attachment-folders move with the headings when > > > > refiling them to other locations? > > > > > > I'm not sure what you mean. > > > > > > Can you give an example? > > > > > > -- > > > Bastien > > > > > [2 <text/html; ISO-8859-1 (quoted-printable)>] > > > [-- Attachment #2: Type: text/html, Size: 3369 bytes --]
Hi Gustav and Darlan, one solution I can think of is to set `org-attach-directory' to an absolute path instead of "data/" (the current default value). This way, refiling an entry will not lose attachments. I'm considering using "~/.org-data/" as the default value. What do you think? -- Bastien
Hi Gustav,
Gustav Wikström <gustav.erik@gmail.com> writes:
> Another feature that could improve the use of attachments is to allow
> links to the attached folders also via the C-c C-l interface in a
> similar way as stored links (C-c l ). I.E to get the attachment-folder
> as an item in the C-c C-l buffer with TAB-completion.
You can already use (setq org-attach-store-link-p t) to create a link
while attaching a file.
Since links are deleted as soon as they are inserted, this will be
usable only once. We can imagine *persistent links* -- and links to
attached files could be a good example of persistent links.
What do you think?
--
Bastien
2011/7/24 Bastien <bzg@altern.org>:
> Hi Gustav and Darlan,
>
> one solution I can think of is to set `org-attach-directory'
> to an absolute path instead of "data/" (the current default
> value).
>
> This way, refiling an entry will not lose attachments.
>
> I'm considering using "~/.org-data/" as the default value.
>
> What do you think?
>
> --
> Bastien
I don't make much use of attachments, but I would think something like
(setq org-attach-dir (concat org-directory ".data"))
would make more sense. I, at least, prefer to have all of my org
related data living in one directory tree.
Best,
Brian vdB
[-- Attachment #1: Type: text/plain, Size: 599 bytes --] I'm leaning towards not moving my archive to a different folder. I like having the attachments relative. Are archive- and refile-hooks implemented b.t.w.? This would make it possible to hack a personal setting, or am I wrong? /Gustav 2011/7/24 Bastien <bzg@altern.org> > Hi Gustav and Darlan, > > one solution I can think of is to set `org-attach-directory' > to an absolute path instead of "data/" (the current default > value). > > This way, refiling an entry will not lose attachments. > > I'm considering using "~/.org-data/" as the default value. > > What do you think? > > -- > Bastien > [-- Attachment #2: Type: text/html, Size: 983 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --] To make org-mode look for attachments in the current sub-tree when using org-insert-link would simplify the process of "linking" to attached files (useful at least when exporting). Persistent links, in in this regard, seems like a nice idea! /Gustav 2011/7/24 Bastien <bzg@altern.org> > Hi Gustav, > > Gustav Wikström <gustav.erik@gmail.com> writes: > > > Another feature that could improve the use of attachments is to allow > > links to the attached folders also via the C-c C-l interface in a > > similar way as stored links (C-c l ). I.E to get the attachment-folder > > as an item in the C-c C-l buffer with TAB-completion. > > You can already use (setq org-attach-store-link-p t) to create a link > while attaching a file. > > Since links are deleted as soon as they are inserted, this will be > usable only once. We can imagine *persistent links* -- and links to > attached files could be a good example of persistent links. > > What do you think? > > -- > Bastien > [-- Attachment #2: Type: text/html, Size: 1496 bytes --]
Gustav Wikström <gustav.erik@gmail.com> writes: > I'm leaning towards not moving my archive to a different folder. I > like having the attachments relative. Okay. But as Darlan pointed out, moving the attached files when refiling the entry might be dangerous, because files in this attached directory can also be attached in a different subtree. I don't have a good general solution to this -- if someone has, please share. > Are archive- and refile-hooks implemented b.t.w.? C-h v org-archive-*-hook TAG C-h v org-refile-*-hook TAG helps. There is `org-after-refile-insert-hook' but there is no `org-archive-hook'. I'll consider adding this. > This would make it > possible to hack a personal setting, or am I wrong? You're probably right. Code is proof. -- Bastien
As I see changing the attach directory to point to the original one is the
easiest solution that has no chances of breaking anything and would keep
attachments working in the refiled/archived sub-trees.
Maybe a org-attach-move-files function could also be implemented to easily
move an attachment directory to a different place. It should move the
directory and automatically set the ATTACH_DIR property to the appropriated
value. Of course org could try to find out if this attach directory is also
used in a different file/sub-tree (maybe search in the agenda files and in
the current directory for org-files using this attach directory) and change
ATTACH_DIR in that file/sub-tree or warn the user before moving the
files. This won't be bullet proof but if the users only set the same attach
directory for headings in the same file, for instance (I do this), then it
would work perfectly.
Then, when the user wants the refiling/archiving process to also move the
attached files it could pass an argument before refiling/archiving and
org-attach-move-files would be called appropriately.
--
Darlan
At Mon, 25 Jul 2011 09:45:24 +0200,
Bastien <bzg@altern.org> wrote:
>
> Gustav Wikström <gustav.erik@gmail.com> writes:
>
> > I'm leaning towards not moving my archive to a different folder. I
> > like having the attachments relative.
>
> Okay.
>
> But as Darlan pointed out, moving the attached files when refiling the
> entry might be dangerous, because files in this attached directory can
> also be attached in a different subtree.
>
> I don't have a good general solution to this -- if someone has, please
> share.
>
> > Are archive- and refile-hooks implemented b.t.w.?
>
> C-h v org-archive-*-hook TAG
> C-h v org-refile-*-hook TAG
>
> helps.
>
> There is `org-after-refile-insert-hook' but there is no
> `org-archive-hook'. I'll consider adding this.
>
> > This would make it
> > possible to hack a personal setting, or am I wrong?
>
> You're probably right. Code is proof.
>
> --
> Bastien
Hi Darlan, here is how I see the situation regarding attachments: 1. org-attach.el is nice because it makes it easy to attach a file to a task, while not *worrying* about where the file is on the harddrive. 2. Adding an ATTACH_DIR property will always add an absolute path, so there is no problem when moving an entry with an explicit ATTACH_DIR. 3. Refiling/archiving subtrees lose track of some attachments when the attach directory "data/" is *relative* to the org file (which is the default) and when the target org file is not in the same directory. 4. Moving an entry with an ATTACH_DIR_INHERIT will lose attachments when the ATTACH_DIR of the target entry is different. (3) and (4) are two distinct problems. I suggest fixing problem (3) by making `org-attach-dir' defaulting to "~/.org-attachments/". I I suggest fixing problem (4) by explicitely replacing ATTACH_DIR_INHERIT with the corresponding ATTACH_DIR when the target subtree has a different ATTACH_DIR. The core idea is that I want to avoid moving files themselves: I think it's a risky road, and I hope the solutions above will make this road unnecessary. I'm interested in feedback and ideas about such proposed changes. Thanks a lot! -- Bastien
Hi Bastien,
On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote:
> I suggest fixing problem (3) by making `org-attach-dir' defaulting to
> "~/.org-attachments/".
Since most of us like to put our org files under version control,
maybe setting it to
(concat org-directory "/.org-attachments/")
would be a better default?
--
Suvayu
Open source is the future. It sets us free.
suvayu ali <fatkasuvayu+linux@gmail.com> wrote:
> Hi Bastien,
>
> On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote:
> > I suggest fixing problem (3) by making `org-attach-dir' defaulting to
> > "~/.org-attachments/".
>
> Since most of us like to put our org files under version control,
> maybe setting it to
>
> (concat org-directory "/.org-attachments/")
>
> would be a better default?
>
Why is it better?
Nick
On Thu, Jul 28, 2011 at 3:46 PM, Nick Dokos <nicholas.dokos@hp.com> wrote: > suvayu ali <fatkasuvayu+linux@gmail.com> wrote: > >> Hi Bastien, >> >> On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote: >> > I suggest fixing problem (3) by making `org-attach-dir' defaulting to >> > "~/.org-attachments/". >> >> Since most of us like to put our org files under version control, >> maybe setting it to >> >> (concat org-directory "/.org-attachments/") >> >> would be a better default? >> > > Why is it better? > Then the attachments can also be version controlled. If it is under ~/.org-attachments/, then it is outside the directory tree. > Nick > -- Suvayu Open source is the future. It sets us free.
suvayu ali <fatkasuvayu+linux@gmail.com> wrote:
> On Thu, Jul 28, 2011 at 3:46 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:
> > suvayu ali <fatkasuvayu+linux@gmail.com> wrote:
> >
> >> Hi Bastien,
> >>
> >> On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote:
> >> > I suggest fixing problem (3) by making `org-attach-dir' defaulting to
> >> > "~/.org-attachments/".
> >>
> >> Since most of us like to put our org files under version control,
> >> maybe setting it to
> >>
> >> (concat org-directory "/.org-attachments/")
> >>
> >> would be a better default?
> >>
> >
> > Why is it better?
> >
>
> Then the attachments can also be version controlled. If it is under
> ~/.org-attachments/, then it is outside the directory tree.
>
D'oh! thanks.
Nick
Regarding (2), is this a design decision? Currently I have the ATTACH_DIR
property of some headings set to a relative path from the org file and it
works perfectly. That is, it is possible to use either absolute or relative
path for the ATTACH_DIR property right now.
But if this is a design decision then I should not consider this behavior
as granted, right?
Also, Suvayu's suggestion for the default attachments directory is the best
solution IMHO. That is, the default attach directory should be relative to
org-directory.
--
Darlan
At Thu, 28 Jul 2011 09:51:54 +0200,
Bastien <bzg@altern.org> wrote:
>
> Hi Darlan,
>
> here is how I see the situation regarding attachments:
>
> 1. org-attach.el is nice because it makes it easy to attach a file to a
> task, while not *worrying* about where the file is on the harddrive.
>
> 2. Adding an ATTACH_DIR property will always add an absolute path, so
> there is no problem when moving an entry with an explicit ATTACH_DIR.
>
> 3. Refiling/archiving subtrees lose track of some attachments when the
> attach directory "data/" is *relative* to the org file (which is the
> default) and when the target org file is not in the same directory.
>
> 4. Moving an entry with an ATTACH_DIR_INHERIT will lose attachments
> when the ATTACH_DIR of the target entry is different.
>
> (3) and (4) are two distinct problems.
>
> I suggest fixing problem (3) by making `org-attach-dir' defaulting to
> "~/.org-attachments/". I
>
> I suggest fixing problem (4) by explicitely replacing ATTACH_DIR_INHERIT
> with the corresponding ATTACH_DIR when the target subtree has a
> different ATTACH_DIR.
>
> The core idea is that I want to avoid moving files themselves: I think
> it's a risky road, and I hope the solutions above will make this road
> unnecessary.
>
> I'm interested in feedback and ideas about such proposed changes.
>
> Thanks a lot!
>
> --
> Bastien
> At Thu, 28 Jul 2011 09:51:54 +0200, > Bastien <bzg@altern.org> wrote: >> >> Hi Darlan, >> >> here is how I see the situation regarding attachments: >> >> 1. org-attach.el is nice because it makes it easy to attach a file to a >> task, while not *worrying* about where the file is on the harddrive. >> >> 2. Adding an ATTACH_DIR property will always add an absolute path, so >> there is no problem when moving an entry with an explicit ATTACH_DIR. >> >> 3. Refiling/archiving subtrees lose track of some attachments when the >> attach directory "data/" is *relative* to the org file (which is the >> default) and when the target org file is not in the same directory. >> >> 4. Moving an entry with an ATTACH_DIR_INHERIT will lose attachments >> when the ATTACH_DIR of the target entry is different. >> >> (3) and (4) are two distinct problems. >> >> I suggest fixing problem (3) by making `org-attach-dir' defaulting to >> "~/.org-attachments/". I >> >> I suggest fixing problem (4) by explicitely replacing ATTACH_DIR_INHERIT >> with the corresponding ATTACH_DIR when the target subtree has a >> different ATTACH_DIR. >> >> The core idea is that I want to avoid moving files themselves: I think >> it's a risky road, and I hope the solutions above will make this road >> unnecessary. >> >> I'm interested in feedback and ideas about such proposed changes. Darlan Cavalcante Moreira <darcamo@gmail.com> writes: > Regarding (2), is this a design decision? Currently I have the ATTACH_DIR > property of some headings set to a relative path from the org file and it > works perfectly. That is, it is possible to use either absolute or relative > path for the ATTACH_DIR property right now. > > But if this is a design decision then I should not consider this behavior > as granted, right? > > Also, Suvayu's suggestion for the default attachments directory is the best > solution IMHO. That is, the default attach directory should be relative to > org-directory. I've used attachments in the past to *copy* attached files somewhere into my org git repository (~/git/org) with attachments under ~/git/org/data/... Since the files are copied I can refile the task with the attachment anywhere in the same git repository without worrying about the details of exactly where it lives. Since then I've stopped using attachments regularly but I still have archived tasks with attachments in my git repo. None of my existing entries have ever specified an ATTACH_DIR* property. Whatever solution is arrived at from this thread I would like my existing (old) attachments to still be retrievable. -Bernt PS. Darlan: Please don't top-post, it makes articles much harder to read.
[-- Attachment #1: Type: text/plain, Size: 2792 bytes --] In case the "not worrying about where.." in (1) is part the purpose of the attachment functionality the idea of an absolute path seems sound. I agree with it being a nice feature, and probably the best to have as default. However I think it also is nice to also be able to use custom names to attachment folders. And it would be nice be able to use some logic with this, like automatically setting the folder name to the same as the heading it's attached to. And to allow properties on a file/heading/sub-tree basis which defines the base-path to where attachments to that particular file/heading/sub-tree should reside on the system, relative or non-relative. This would allow for more atomic solutions if i'm writing a document on the side of my main setup and want to add some attachments in the same path. This adds a bit to the complexity of designing the functionality, and questions about refiling and archiving arise.. But maybe just adding a warning for these events might be enough as a first step. Although, with file-properties for attachment directories it might be possible to ask if the attachment-dir should also be moved (or copied) to this new location. But still, it is a really nice feature to have control over the attachments. So from my point of view it seems sound to try to reason about different solutions to this or at least keep it in mind for future functionality. Just some thoughts Gustav On Thu, Jul 28, 2011 at 9:51 AM, Bastien <bzg@altern.org> wrote: > Hi Darlan, > > here is how I see the situation regarding attachments: > > 1. org-attach.el is nice because it makes it easy to attach a file to a > task, while not *worrying* about where the file is on the harddrive. > > 2. Adding an ATTACH_DIR property will always add an absolute path, so > there is no problem when moving an entry with an explicit ATTACH_DIR. > > 3. Refiling/archiving subtrees lose track of some attachments when the > attach directory "data/" is *relative* to the org file (which is the > default) and when the target org file is not in the same directory. > > 4. Moving an entry with an ATTACH_DIR_INHERIT will lose attachments > when the ATTACH_DIR of the target entry is different. > > (3) and (4) are two distinct problems. > > I suggest fixing problem (3) by making `org-attach-dir' defaulting to > "~/.org-attachments/". I > > I suggest fixing problem (4) by explicitely replacing ATTACH_DIR_INHERIT > with the corresponding ATTACH_DIR when the target subtree has a > different ATTACH_DIR. > > The core idea is that I want to avoid moving files themselves: I think > it's a risky road, and I hope the solutions above will make this road > unnecessary. > > I'm interested in feedback and ideas about such proposed changes. > > Thanks a lot! > > -- > Bastien > [-- Attachment #2: Type: text/html, Size: 3343 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --] What about being able to link to attachments in a similar way as one links to files or web-pages? Using [[attachment:some_file.sql][some link name]] ? Comments? Problems with this? 2011/7/25 Gustav Wikström <gustav.erik@gmail.com> > To make org-mode look for attachments in the current sub-tree when using > org-insert-link would simplify the process of "linking" to attached files > (useful at least when exporting). Persistent links, in in this regard, seems > like a nice idea! > > /Gustav > > 2011/7/24 Bastien <bzg@altern.org> > >> Hi Gustav, >> >> Gustav Wikström <gustav.erik@gmail.com> writes: >> >> > Another feature that could improve the use of attachments is to allow >> > links to the attached folders also via the C-c C-l interface in a >> > similar way as stored links (C-c l ). I.E to get the attachment-folder >> > as an item in the C-c C-l buffer with TAB-completion. >> >> You can already use (setq org-attach-store-link-p t) to create a link >> while attaching a file. >> >> Since links are deleted as soon as they are inserted, this will be >> usable only once. We can imagine *persistent links* -- and links to >> attached files could be a good example of persistent links. >> >> What do you think? >> >> -- >> Bastien >> > > [-- Attachment #2: Type: text/html, Size: 2032 bytes --]
I requested this some time ago [1]. While there is not a built-in attach link type, org provides you with ways to easily create this functionality. In the setup part in my org-files I put --8<---------------cut here---------------start------------->8--- #+LINK: attach elisp:(org-open-file (org-attach-expand "%s")) --8<---------------cut here---------------end--------------->8--- Now I can use the "attach" link type, but org will ask me if I want to allow executing the elisp code. To avoid this you can even set org-confirm-elisp-link-function to nil (I don't like this because it allows any elisp code in links) or you can set org-confirm-elisp-link-not-regexp appropriately. In my case I use : (setq org-confirm-elisp-link-not-regexp "org-open-file") This works very well. -- Darlan [1] http://www.mail-archive.com/emacs-orgmode@gnu.org/msg37613.html At Fri, 29 Jul 2011 10:33:37 +0200, Gustav Wikström <gustav.erik@gmail.com> wrote: > > [1 <text/plain; ISO-8859-1 (quoted-printable)>] > What about being able to link to attachments in a similar way as one links > to files or web-pages? Using [[attachment:some_file.sql][some link name]] ? > Comments? Problems with this? > > 2011/7/25 Gustav Wikström <gustav.erik@gmail.com> > > > To make org-mode look for attachments in the current sub-tree when using > > org-insert-link would simplify the process of "linking" to attached files > > (useful at least when exporting). Persistent links, in in this regard, seems > > like a nice idea! > > > > /Gustav > > > > 2011/7/24 Bastien <bzg@altern.org> > > > >> Hi Gustav, > >> > >> Gustav Wikström <gustav.erik@gmail.com> writes: > >> > >> > Another feature that could improve the use of attachments is to allow > >> > links to the attached folders also via the C-c C-l interface in a > >> > similar way as stored links (C-c l ). I.E to get the attachment-folder > >> > as an item in the C-c C-l buffer with TAB-completion. > >> > >> You can already use (setq org-attach-store-link-p t) to create a link > >> while attaching a file. > >> > >> Since links are deleted as soon as they are inserted, this will be > >> usable only once. We can imagine *persistent links* -- and links to > >> attached files could be a good example of persistent links. > >> > >> What do you think? > >> > >> -- > >> Bastien > >> > > > > > [2 <text/html; ISO-8859-1 (quoted-printable)>] >
Gustav Wikström <gustav.erik@gmail.com> writes:
> However I think it also is nice to also be able to use custom names to
> attachment folders. And it would be nice be able to use some logic with
> this, like automatically setting the folder name to the same as the
> heading it's attached to. And to allow properties on a file/heading/
> sub-tree basis which defines the base-path to where attachments to that
> particular file/heading/sub-tree should reside on the system, relative
> or non-relative. This would allow for more atomic solutions if i'm
> writing a document on the side of my main setup and want to add some
> attachments in the same path.
>
> But still, it is a really nice feature to have control over the
> attachments. So from my point of view it seems sound to try to reason
> about different solutions to this or at least keep it in mind for
> future functionality.
One possibility is to advise the function org-attach-dir to call
org-attach-set-directory (and, optionally, org-attach-set-inherit) if
the entry does not already have an ATTACH_DIR property:
--8<---------------cut here---------------start------------->8---
(defadvice org-attach-dir (before my-org-attach-set-dir-before-attach activate)
"Prompt for attachment directory (thus preempting org-get-id)."
(unless (org-entry-get nil "ATTACH_DIR" 'inherit)
(org-attach-set-directory)))
--8<---------------cut here---------------end--------------->8---
This allows one to enter the name of the directory *before* org attaches
the file. This is the way I use org-attach, as I prefer human-readable
directories to UUIDs.
Best,
Matt
Hi Darlan,
Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> I requested this some time ago [1]. While there is not a built-in attach
> link type, org provides you with ways to easily create this functionality.
>
> In the setup part in my org-files I put
> #+LINK: attach elisp:(org-open-file (org-attach-expand "%s"))
>
> Now I can use the "attach" link type, but org will ask me if I want to
> allow executing the elisp code. To avoid this you can even set
> org-confirm-elisp-link-function to nil (I don't like this because it allows
> any elisp code in links) or you can set org-confirm-elisp-link-not-regexp
> appropriately.
>
> In my case I use
> : (setq org-confirm-elisp-link-not-regexp "org-open-file")
>
> This works very well.
This is a nice and useful hack -- I added it to Worg/org-hacks.org.
Thanks!
--
Bastien
Hello Bastien,
I'm glad to help (even if such a small contribution).
The downside of this hack is that it does not work when you export the
buffer. If you use the file: link type then the link will works when you
export the org buffer, but you have to type the whole path of the attached
file. Therefore, there is this trade-off for now.
There is probably a way to make the attach link type also work when
exporting the org buffer, but since I don't need this right now I didn't
search how to do it.
--
Darlan
At Thu, 18 Aug 2011 19:33:37 +0200,
Bastien <bzg@altern.org> wrote:
>
> Hi Darlan,
>
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
>
> > I requested this some time ago [1]. While there is not a built-in attach
> > link type, org provides you with ways to easily create this functionality.
> >
> > In the setup part in my org-files I put
> > #+LINK: attach elisp:(org-open-file (org-attach-expand "%s"))
> >
> > Now I can use the "attach" link type, but org will ask me if I want to
> > allow executing the elisp code. To avoid this you can even set
> > org-confirm-elisp-link-function to nil (I don't like this because it allows
> > any elisp code in links) or you can set org-confirm-elisp-link-not-regexp
> > appropriately.
> >
> > In my case I use
> > : (setq org-confirm-elisp-link-not-regexp "org-open-file")
> >
> > This works very well.
>
> This is a nice and useful hack -- I added it to Worg/org-hacks.org.
>
> Thanks!
>
> --
> Bastien
Hi Darlan,
Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> There is probably a way to make the attach link type also work when
> exporting the org buffer, but since I don't need this right now I didn't
> search how to do it.
You could use a `org-export-preprocess-hook' to convert those "attach"
links into proper "file" links.
--
Bastien
At Fri, 19 Aug 2011 10:46:26 +0200,
Bastien <bzg@altern.org> wrote:
What about org-add-link-type?
Besides the new link type name, org-add-link-type can receives two
functions, one used to follow the link and another to export the link.
I was able to make the attach link type work by using org-add-link-type,
where the "follow" function is practically the same code I have used
with #+LINK.
However, I could not make the the "export" part work because I can't use
org-attach-expand in it. Therefore, I don't know how to get the attach
directory inside a function that I can pass to org-add-link-type as the
export function. Unfortunately, my elisp skills are very limited to go any
further for now.
--
Darlan
>
> Hi Darlan,
>
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
>
> > There is probably a way to make the attach link type also work when
> > exporting the org buffer, but since I don't need this right now I didn't
> > search how to do it.
>
> You could use a `org-export-preprocess-hook' to convert those "attach"
> links into proper "file" links.
>
> --
> Bastien
Hi Darlan, Darlan Cavalcante Moreira <darcamo@gmail.com> writes: > At Fri, 19 Aug 2011 10:46:26 +0200, > Bastien <bzg@altern.org> wrote: > > What about org-add-link-type? Mmhh.. yes. We should be able to use something like: (org-add-link-type "attach" 'org-attach-open 'org-attach-export) > However, I could not make the the "export" part work because I can't use > org-attach-expand in it. Therefore, I don't know how to get the attach > directory inside a function that I can pass to org-add-link-type as the > export function. That's not possible for now. That's something we can keep in mind while working an a new export engine: exporting part of the content should be done in a context-aware fashion, where it's possible to get the value of org-attach-dir. > Unfortunately, my elisp skills are very limited to go any further for > now. Even with good elisp skills I'm afraid we cannot achieve this for the moment. HTH, -- Bastien
At Wed, 24 Aug 2011 16:12:01 +0200, Bastien <bzg@altern.org> wrote: > > Hi Darlan, > > Darlan Cavalcante Moreira <darcamo@gmail.com> writes: > > > At Fri, 19 Aug 2011 10:46:26 +0200, > > Bastien <bzg@altern.org> wrote: > > > > What about org-add-link-type? > > Mmhh.. yes. We should be able to use something like: > > (org-add-link-type "attach" 'org-attach-open 'org-attach-export) > > > However, I could not make the the "export" part work because I can't use > > org-attach-expand in it. Therefore, I don't know how to get the attach > > directory inside a function that I can pass to org-add-link-type as the > > export function. > > That's not possible for now. That's something we can keep in mind > while working an a new export engine: exporting part of the content > should be done in a context-aware fashion, where it's possible to > get the value of org-attach-dir. Thanks for the confirmation Bastien. At least for me the export part is not very important right now. A context aware export engine would make this easy to achieve with org-add-link-type and probably open up many other possibilities, but I understand it is a lot of work. > > > Unfortunately, my elisp skills are very limited to go any further for > > now. > > Even with good elisp skills I'm afraid we cannot achieve this for > the moment. > > HTH, > > -- > Bastien -- Darlan
[-- Attachment #1: Type: text/plain, Size: 1832 bytes --] Thanks for this. Added it to my settings for now =) /Gustav 2011/8/2 Matt Lundin <mdl@imapmail.org> > Gustav Wikström <gustav.erik@gmail.com> writes: > > > However I think it also is nice to also be able to use custom names to > > attachment folders. And it would be nice be able to use some logic with > > this, like automatically setting the folder name to the same as the > > heading it's attached to. And to allow properties on a file/heading/ > > sub-tree basis which defines the base-path to where attachments to that > > particular file/heading/sub-tree should reside on the system, relative > > or non-relative. This would allow for more atomic solutions if i'm > > writing a document on the side of my main setup and want to add some > > attachments in the same path. > > > > But still, it is a really nice feature to have control over the > > attachments. So from my point of view it seems sound to try to reason > > about different solutions to this or at least keep it in mind for > > future functionality. > > One possibility is to advise the function org-attach-dir to call > org-attach-set-directory (and, optionally, org-attach-set-inherit) if > the entry does not already have an ATTACH_DIR property: > > --8<---------------cut here---------------start------------->8--- > (defadvice org-attach-dir (before my-org-attach-set-dir-before-attach > activate) > "Prompt for attachment directory (thus preempting org-get-id)." > (unless (org-entry-get nil "ATTACH_DIR" 'inherit) > (org-attach-set-directory))) > --8<---------------cut here---------------end--------------->8--- > > This allows one to enter the name of the directory *before* org attaches > the file. This is the way I use org-attach, as I prefer human-readable > directories to UUIDs. > > Best, > Matt > [-- Attachment #2: Type: text/html, Size: 2428 bytes --]