From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Carsten Dominik" Subject: Re: Re: Whitespace and outline structure... Date: Wed, 12 Dec 2007 17:24:04 +0100 Message-ID: References: <87odcxxxkg.fsf@enki.rimspace.net> <873au9gxkh.fsf@bzg.ath.cx> <87fxy9e3oq.fsf@shellarchive.co.uk> <874pepfgcm.fsf@bzg.ath.cx> <87k5nkf6ob.fsf@enki.rimspace.net> <87hcio9c3u.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J2UNT-0006uo-VY for emacs-orgmode@gnu.org; Wed, 12 Dec 2007 11:24:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J2UNS-0006s6-CP for emacs-orgmode@gnu.org; Wed, 12 Dec 2007 11:24:07 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J2UNS-0006rv-8f for emacs-orgmode@gnu.org; Wed, 12 Dec 2007 11:24:06 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J2UNR-0002av-SG for emacs-orgmode@gnu.org; Wed, 12 Dec 2007 11:24:06 -0500 Received: by nz-out-0506.google.com with SMTP id f1so167576nzc.21 for ; Wed, 12 Dec 2007 08:24:04 -0800 (PST) In-Reply-To: <87hcio9c3u.fsf@bzg.ath.cx> Content-Disposition: inline List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org On Dec 12, 2007 4:17 PM, Bastien wrote: > Yes. Considering an option like: > > (setq org-allow-blank-lines ;; or org-allow-max-blank-lines > '((org-level-1 . 2) > (org-level-2 . 1) > (list-item . 1) > (t . delete)) > > The rule for handling trailing blank lines would be as follow : when > moving/cutting a subtree of level N, only allow a definite number of > trailing blank lines (L_n). If there is more than L_n lines, try to > decide whether these additional blank lines are part of the subtree > above... etc. If blank lines cannot be attached to a subtree, either > delete them, or reject them at the end of the subtree. > > Not sure how this could be implemented, but I just wanted to clarify > what I had in mind. I am not sure an option is the right thing here, because it will continue to remain difficult to figure out where to put the boundaries. The best might be to look *before* a heading and see how many empty lines there are, and then include up to that many lines below the subtree. It seems to me that this might get quite close to the right behavior, but I am sure there will be cases where also this idea will not work correctly. - Carsten