* if we operate on a subtree, perhaps we could adjust levels
@ 2014-03-27 3:44 Samuel Wales
2014-04-11 9:07 ` Bastien
0 siblings, 1 reply; 11+ messages in thread
From: Samuel Wales @ 2014-03-27 3:44 UTC (permalink / raw
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-03-27 3:44 if we operate on a subtree, perhaps we could adjust levels Samuel Wales
@ 2014-04-11 9:07 ` Bastien
2014-04-17 9:43 ` Samuel Wales
0 siblings, 1 reply; 11+ messages in thread
From: Bastien @ 2014-04-11 9:07 UTC (permalink / raw
To: Samuel Wales; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-04-11 9:07 ` Bastien
@ 2014-04-17 9:43 ` Samuel Wales
2014-04-17 10:12 ` Bastien
0 siblings, 1 reply; 11+ messages in thread
From: Samuel Wales @ 2014-04-17 9:43 UTC (permalink / raw
To: Bastien; +Cc: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-04-17 9:43 ` Samuel Wales
@ 2014-04-17 10:12 ` Bastien
2014-06-09 4:54 ` Samuel Wales
0 siblings, 1 reply; 11+ messages in thread
From: Bastien @ 2014-04-17 10:12 UTC (permalink / raw
To: Samuel Wales; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-04-17 10:12 ` Bastien
@ 2014-06-09 4:54 ` Samuel Wales
2014-06-09 5:54 ` Achim Gratz
0 siblings, 1 reply; 11+ messages in thread
From: Samuel Wales @ 2014-06-09 4:54 UTC (permalink / raw
To: Bastien; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-06-09 4:54 ` Samuel Wales
@ 2014-06-09 5:54 ` Achim Gratz
2014-07-28 15:05 ` Bastien
0 siblings, 1 reply; 11+ messages in thread
From: Achim Gratz @ 2014-06-09 5:54 UTC (permalink / raw
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-06-09 5:54 ` Achim Gratz
@ 2014-07-28 15:05 ` Bastien
2014-07-28 19:08 ` Samuel Wales
2014-07-29 16:03 ` Achim Gratz
0 siblings, 2 replies; 11+ messages in thread
From: Bastien @ 2014-07-28 15:05 UTC (permalink / raw
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-07-28 15:05 ` Bastien
@ 2014-07-28 19:08 ` Samuel Wales
2014-07-29 14:30 ` Bastien
2014-07-29 16:03 ` Achim Gratz
1 sibling, 1 reply; 11+ messages in thread
From: Samuel Wales @ 2014-07-28 19:08 UTC (permalink / raw
To: Bastien; +Cc: Achim Gratz, emacs-orgmode
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-07-28 19:08 ` Samuel Wales
@ 2014-07-29 14:30 ` Bastien
0 siblings, 0 replies; 11+ messages in thread
From: Bastien @ 2014-07-29 14:30 UTC (permalink / raw
To: Samuel Wales; +Cc: Achim Gratz, emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-07-28 15:05 ` Bastien
2014-07-28 19:08 ` Samuel Wales
@ 2014-07-29 16:03 ` Achim Gratz
2014-07-29 21:32 ` Bastien
1 sibling, 1 reply; 11+ messages in thread
From: Achim Gratz @ 2014-07-29 16:03 UTC (permalink / raw
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: if we operate on a subtree, perhaps we could adjust levels
2014-07-29 16:03 ` Achim Gratz
@ 2014-07-29 21:32 ` Bastien
0 siblings, 0 replies; 11+ messages in thread
From: Bastien @ 2014-07-29 21:32 UTC (permalink / raw
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-07-29 21:33 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-27 3:44 if we operate on a subtree, perhaps we could adjust levels Samuel Wales
2014-04-11 9:07 ` Bastien
2014-04-17 9:43 ` Samuel Wales
2014-04-17 10:12 ` Bastien
2014-06-09 4:54 ` Samuel Wales
2014-06-09 5:54 ` Achim Gratz
2014-07-28 15:05 ` Bastien
2014-07-28 19:08 ` Samuel Wales
2014-07-29 14:30 ` Bastien
2014-07-29 16:03 ` Achim Gratz
2014-07-29 21:32 ` Bastien
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.