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

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

[Samuel Wales]

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.

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.

  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 ')

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

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

  5) a combination.

maybe there are more possibilities.

comments?

samuel

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

[Bastien]

Hi Samnuel,

Samuel Wales <samologist@gmail.com> writes:

> 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.

That's expected.  Users don't think Org is clever enough to
decrypt-demote-subtrees-then-re-encrypt on the fly.

Best,

-- 
 Bastien

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

[Samuel Wales]

On 4/11/14, Bastien <bzg@gnu.org> wrote:
> That's expected.  Users don't think Org is clever enough to
> decrypt-demote-subtrees-then-re-encrypt on the fly.

i was not suggesting this.

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

[Bastien]

Samuel Wales <samologist@gmail.com> writes:

> On 4/11/14, Bastien <bzg@gnu.org> wrote:
>> That's expected.  Users don't think Org is clever enough to
>> decrypt-demote-subtrees-then-re-encrypt on the fly.
>
> i was not suggesting this.

Then I didn't understand what you suggested.  Can you restate
it again?  Thanks,

-- 
 Bastien

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

[Samuel Wales]

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

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

[Achim Gratz]

Samuel Wales writes:
> 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?

There's two ways I can think of:

1. Record the subtree level in a property before doing the encryption
and compare that to the level after decryption.  If there's no match,
then promote or demote as appropriate.

2. Demote the whole subtree to toplevel before encryption and promote
into the correct level on decryption, (much in the same way that
includes are handled).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Bastien]

Hi Samuel and Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> Samuel Wales writes:
>> 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.

I see now, thanks.

>> is there a way to fix it?
>
> There's two ways I can think of:
>
> 1. Record the subtree level in a property before doing the encryption
> and compare that to the level after decryption.  If there's no match,
> then promote or demote as appropriate.

I tried that way, but promoting and demoting the subtrees of the
encrypted entry is tricky.

> 2. Demote the whole subtree to toplevel before encryption and promote
> into the correct level on decryption, (much in the same way that
> includes are handled).

By "correct level on decryption" you mean toplevel?  This would really
circumvent the problem.

Maybe we can store the level in a property on encryption and simply
throw a warning on decryption, letting the user decide whether she
wants to continue decrypting even when it may break the hierarchy.

What do you think?

-- 
 Bastien

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

[Samuel Wales]

org-yank-adjusted-subtrees?

On 7/28/14, Bastien <bzg@gnu.org> wrote:
> Hi Samuel and Achim,
>
> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Samuel Wales writes:
>>> 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.
>
> I see now, thanks.
>
>>> is there a way to fix it?
>>
>> There's two ways I can think of:
>>
>> 1. Record the subtree level in a property before doing the encryption
>> and compare that to the level after decryption.  If there's no match,
>> then promote or demote as appropriate.
>
> I tried that way, but promoting and demoting the subtrees of the
> encrypted entry is tricky.
>
>> 2. Demote the whole subtree to toplevel before encryption and promote
>> into the correct level on decryption, (much in the same way that
>> includes are handled).
>
> By "correct level on decryption" you mean toplevel?  This would really
> circumvent the problem.
>
> Maybe we can store the level in a property on encryption and simply
> throw a warning on decryption, letting the user decide whether she
> wants to continue decrypting even when it may break the hierarchy.
>
> What do you think?
>
> --
>  Bastien
>
>


-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.

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

[Bastien]

Hi Samuel,

Samuel Wales <samologist@gmail.com> writes:

> org-yank-adjusted-subtrees?

I think this would work if the yank contains only one subtree,
which will not be the case most of the times.

Still worth exploring, I'll keep this in my todo list,

-- 
 Bastien

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

[Achim Gratz]

Bastien writes:
>> 2. Demote the whole subtree to toplevel before encryption and promote
>> into the correct level on decryption, (much in the same way that
>> includes are handled).
>
> By "correct level on decryption" you mean toplevel?  This would really
> circumvent the problem.

Not sure what you mean by toplevel, but the way includes are handled is
to check at what level the include is happening and promote the included
content to that level.  That would also make the encrypted subtree
independent of any movements in the hierarchy, which is IMHO desirable.

> Maybe we can store the level in a property on encryption and simply
> throw a warning on decryption, letting the user decide whether she
> wants to continue decrypting even when it may break the hierarchy.

FWIW, I prefer the other solution since it is more general.  Again, the
content from the decryption process can be treated like an include
(except for display rather than during export) or rather an "inline
file", which might be worth having independently of encrypted subtree as
well.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

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

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> FWIW, I prefer the other solution since it is more general.  Again, the
> content from the decryption process can be treated like an include
> (except for display rather than during export) or rather an "inline
> file", which might be worth having independently of encrypted subtree as
> well.

If you think you can have a look in the next weeks, that'd be great.
I'll try following your directions when I'm back.

Thanks,

-- 
 Bastien