Re: if we operate on a subtree, perhaps we could adjust levels

[Samuel Wales <samologist@gmail.com>]

hi bastien,

On 4/17/14, Bastien <bzg@gnu.org> wrote:
> Then I didn't understand what you suggested.  Can you restate
> it again?  Thanks,

will try.

On 3/26/14, Samuel Wales <samologist@gmail.com> wrote:
> in maint, if you encrypt with org-crypt on an entry with children, then
> demote, then decrypt, the subtree levels do not match up.
> for example, the children can end up as uncle/aunt nodes.

1 take a subtree, go to the top level of that subtree, encrypt.

2 this encrypts the entire subtree as a frozen-in-time unit.

3 when you subsequently decrypt, it decrypts the entire subtree.

4 so far so good.

5 notice the levels on the subtree.  they are identical to the levels
that existed at the time of encryption.  so far so good.

now do exactly as above, but between steps 2 and 3, move the encrypted entry.

move it to a very demoted place.

much more demoted than the original subtree was.

so far so good.

now decrypt.

you will notice that the decrypted subtree is actually at a higher
level than its parent.  this is a violation of org structure.

in consequence, it can silently swallow the entire rest of the file.

this is not desired.

is there a way to fix it?

let's find out.

> maybe something like these are possibilities:
>
>   1) optionally adjust subtree levels to match the location
>      of the header at time of decryption.  this is similar
>      to how org-yank behaves.  it would have to re-encrypt
>      if you encrypt, demote, decrypt, encrypt.

there is nothing special here.  all it does is demote the contents
properly upon decryption.  however, it is dwim.

please do c-h v org-yank-adjusted-subtrees for more information.

>
>   2) optionally put the subtree in an org source block so
>      that it is no longer an active subtree (can't search
>      headlines in agenda, they are not where they belong, can't export
> as part of parent, have to edit with c-c ')

this works around it.  however, i don't like those drawbacks.

>
>   3) restrict the function to only operate on body text
>      (can't do subtrees).

this is the hardass fix.

>
>   4) status quo (allow outline corruption at user's risk).

i don't like this one.

>
>   5) a combination.
>
> maybe there are more possibilities.
>
> comments?

i suggest 3 by default but you can enable 1.

samuel