From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: if we operate on a subtree, perhaps we could adjust levels Date: Mon, 28 Jul 2014 17:05:57 +0200 Message-ID: <87d2cpwg3r.fsf@bzg.ath.cx> References: <87y4zc3ss0.fsf@bzg.ath.cx> <8761m81cyh.fsf@bzg.ath.cx> <87k38qwru3.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBog2-0007rm-LK for emacs-orgmode@gnu.org; Mon, 28 Jul 2014 13:25:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XBofj-0005yJ-Lu for emacs-orgmode@gnu.org; Mon, 28 Jul 2014 13:25:34 -0400 Received: from mail-s76.mailgun.info ([184.173.153.204]:46713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XBofj-0005nv-Ap for emacs-orgmode@gnu.org; Mon, 28 Jul 2014 13:25:15 -0400 In-Reply-To: <87k38qwru3.fsf@Rainer.invalid> (Achim Gratz's message of "Mon, 09 Jun 2014 07:54:28 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Achim Gratz Cc: emacs-orgmode@gnu.org Hi Samuel and Achim, Achim Gratz 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