Re: Attachments and refiling

[Darlan Cavalcante Moreira <darcamo@gmail.com>]

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