From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Re: Whitespace and outline structure... Date: Wed, 12 Dec 2007 16:17:09 +0100 Message-ID: <87hcio9c3u.fsf@bzg.ath.cx> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J2TKy-0004Rl-Mw for emacs-orgmode@gnu.org; Wed, 12 Dec 2007 10:17:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J2TKx-0004R2-9g for emacs-orgmode@gnu.org; Wed, 12 Dec 2007 10:17:28 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J2TKx-0004Qz-0Y for emacs-orgmode@gnu.org; Wed, 12 Dec 2007 10:17:27 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J2TKw-00042C-Rs for emacs-orgmode@gnu.org; Wed, 12 Dec 2007 10:17:27 -0500 Received: by nf-out-0910.google.com with SMTP id f5so233342nfh.26 for ; Wed, 12 Dec 2007 07:17:20 -0800 (PST) In-Reply-To: <87k5nkf6ob.fsf@enki.rimspace.net> (Daniel Pittman's message of "Wed, 12 Dec 2007 23:17:56 +1100") 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: emacs-orgmode@gnu.org Daniel Pittman writes: > Bastien writes: >> Phil Jackson writes: >> >>>> The problem is that there is no way to tell that the two blank lines >>>> after "** Blah blah" are part of "** Blah blah" or part of "* Some >>>> stuff". >>> >>> [...] >>> >>>> What do you think? >>> >>> I suffer this problem too. I can't think of a situation where blank >>> lines would be useful attached to an item.... but maybe I'm doing it >>> wrong. >> >> No, I feel the same. I think I don't usually need more one or two >> blank lines. Hence my proposal about org-delete-trailing-blank-lines >> based on allowed values... > > Something like that might be good -- for my use a single blank line is > part of the entry, the second one is not, ever. So, for me, a simple > rule. 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. -- Bastien