Re: [O] Archive subtrees hierarchical (keep the parent structure)

[Eric Abrahamsen]

Florian Adamsky <address@hidden> writes:

> Dear Eric,
>
> On Tuesday, Aug 05 2014, Eric Abrahamsen <address@hidden> wrote:
>
>> Thanks for this work -- I think this is a nice feature. One concern
>> about the above is that, if you're archiving many FOOs, then you'll get
>> a whole bunch of duplicate A/B parent structures. There are several
>> places in my agenda files where I have the exact structure in your
>> example, and a *whole* lot of FOOs going in and getting archived out.
>> How hard would it be to look for an existing A/B parent structure in the
>> archive file, and put FOO there if it's found? Not a perfect solution,
>> since you might have more than one A/B, but seems like it would help in
>> a majority of cases...
>
> if I understand you correctly, then I have already implemented that. If
> I would like to archive "*** Foo", the function (fa/org-struct-subtree)
> returns the parent headings as a list, e.g. ("*A " "** B"). Inside the
> archive file, I search for "* A" and inside that heading I search for
> "** B". If "** B" was not found, it inserts the remaining list that was
> not found and does not create a new "* A" again. This means if you have
> "*A " and "** B" already in your archive file it will not add a new A/B.

Excellent! That's just what I meant, and it sounds like you've already
taken care of it. Personally I don't mind if items get filed under the
wrong parent structure (in case of duplicate parent structures), but if
you wanted to do the unique id trick, that would be nice too!

Thanks,
Eric

> A problem exists if you have the exact same structure twice in one file like
> the following example:
>
> * A
> ** B
> *** FOO
>
> * A
> ** B
> *** FOO
>
> If you would archive both *** FOO, then the archive file would look like
> this:
>
> * A
> ** B
> *** FOO
> *** FOO
>
> In order to fix that problem we need a unique id for every heading. My
> current implementation implies that at least the first heading is
> unique. Then it should not be a problem.
>
> Best regards
> --
> Florian Adamsky
> http://florian.adamsky.it/