Re: [O] if we operate on a subtree, perhaps we could adjust levels
Hi Samuel, Samuel Wales samolog...@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: [O] if we operate on a subtree, perhaps we could adjust levels
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: [O] if we operate on a subtree, perhaps we could adjust levels
Hi Achim, Achim Gratz strom...@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
Re: [O] if we operate on a subtree, perhaps we could adjust levels
Hi Samuel and Achim, Achim Gratz strom...@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: [O] if we operate on a subtree, perhaps we could adjust levels
org-yank-adjusted-subtrees? On 7/28/14, Bastien b...@gnu.org wrote: Hi Samuel and Achim, Achim Gratz strom...@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: [O] if we operate on a subtree, perhaps we could adjust levels
hi bastien, On 4/17/14, Bastien b...@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 samolog...@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: [O] if we operate on a subtree, perhaps we could adjust levels
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: [O] if we operate on a subtree, perhaps we could adjust levels
On 4/11/14, Bastien b...@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: [O] if we operate on a subtree, perhaps we could adjust levels
Samuel Wales samolog...@gmail.com writes: On 4/11/14, Bastien b...@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: [O] if we operate on a subtree, perhaps we could adjust levels
Hi Samnuel, Samuel Wales samolog...@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
