Re: [O] Attachments and refiling
Thanks for this. Added it to my settings for now =) /Gustav 2011/8/2 Matt Lundin m...@imapmail.org Gustav Wikström gustav.e...@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
Re: [O] Attachments and refiling
Hi Darlan, Darlan Cavalcante Moreira darc...@gmail.com writes: At Fri, 19 Aug 2011 10:46:26 +0200, Bastien b...@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
Re: [O] Attachments and refiling
At Wed, 24 Aug 2011 16:12:01 +0200, Bastien b...@altern.org wrote: Hi Darlan, Darlan Cavalcante Moreira darc...@gmail.com writes: At Fri, 19 Aug 2011 10:46:26 +0200, Bastien b...@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
Re: [O] Attachments and refiling
Hi Darlan, Darlan Cavalcante Moreira darc...@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
Re: [O] Attachments and refiling
At Fri, 19 Aug 2011 10:46:26 +0200, Bastien b...@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 darc...@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
Re: [O] Attachments and refiling
Hi Darlan, Darlan Cavalcante Moreira darc...@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
Re: [O] Attachments and refiling
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 b...@altern.org wrote: Hi Darlan, Darlan Cavalcante Moreira darc...@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
Re: [O] Attachments and refiling
Gustav Wikström gustav.e...@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
Re: [O] Attachments and refiling
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 b...@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
Re: [O] Attachments and refiling
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.e...@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 b...@altern.org Hi Gustav, Gustav Wikström gustav.e...@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
Re: [O] Attachments and refiling
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.e...@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.e...@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 b...@altern.org Hi Gustav, Gustav Wikström gustav.e...@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)]
Re: [O] Attachments and refiling
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
Re: [O] Attachments and refiling
Hi Bastien, On Thu, Jul 28, 2011 at 9:51 AM, Bastien b...@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.
Re: [O] Attachments and refiling
suvayu ali fatkasuvayu+li...@gmail.com wrote: Hi Bastien, On Thu, Jul 28, 2011 at 9:51 AM, Bastien b...@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
Re: [O] Attachments and refiling
On Thu, Jul 28, 2011 at 3:46 PM, Nick Dokos nicholas.do...@hp.com wrote: suvayu ali fatkasuvayu+li...@gmail.com wrote: Hi Bastien, On Thu, Jul 28, 2011 at 9:51 AM, Bastien b...@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.
Re: [O] Attachments and refiling
suvayu ali fatkasuvayu+li...@gmail.com wrote: On Thu, Jul 28, 2011 at 3:46 PM, Nick Dokos nicholas.do...@hp.com wrote: suvayu ali fatkasuvayu+li...@gmail.com wrote: Hi Bastien, On Thu, Jul 28, 2011 at 9:51 AM, Bastien b...@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
Re: [O] Attachments and refiling
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 b...@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
Re: [O] Attachments and refiling
At Thu, 28 Jul 2011 09:51:54 +0200, Bastien b...@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 darc...@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.
Re: [O] Attachments and refiling
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 b...@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
Re: [O] Attachments and refiling
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 b...@altern.org Hi Gustav, Gustav Wikström gustav.e...@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
Re: [O] Attachments and refiling
Gustav Wikström gustav.e...@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
Re: [O] Attachments and refiling
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 b...@altern.org wrote: Gustav Wikström gustav.e...@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
Re: [O] Attachments and refiling
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
Re: [O] Attachments and refiling
Hi Gustav, Gustav Wikström gustav.e...@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
Re: [O] Attachments and refiling
2011/7/24 Bastien b...@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
Re: [O] Attachments and refiling
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 darc...@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.e...@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 b...@altern.org
Hi Gustav,
Gustav Wikström gustav.e...@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)]
Re: [O] Attachments and refiling
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.e...@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 b...@altern.org
Hi Gustav,
Gustav Wikström gustav.e...@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)]
[O] Attachments and refiling
Is it possible to make attachment-folders move with the headings when refiling them to other locations? Regards Gustav
Re: [O] Attachments and refiling
Hi Gustav, Gustav Wikström gustav.e...@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
Re: [O] Attachments and refiling
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 b...@altern.org
Hi Gustav,
Gustav Wikström gustav.e...@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
