From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: capture initial "level" and refile of capture buffer Date: Mon, 25 Oct 2010 09:11:20 +0200 Message-ID: <4D2F89B4-6F6C-411D-B272-3FF3DAD80B23@gmail.com> References: Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=56816 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAI6A-00043D-0v for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:08:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAI68-0003qS-Bs for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:08:05 -0400 Received: from mail-ew0-f41.google.com ([209.85.215.41]:56015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAI68-0003pt-7K for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:08:04 -0400 Received: by mail-ew0-f41.google.com with SMTP id 25so1443443ewy.0 for ; Mon, 25 Oct 2010 01:08:03 -0700 (PDT) In-Reply-To: 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: Noorul Islam Cc: Richard Riley , emacs-orgmode@gnu.org Hi Noorul, hi Richard, On Oct 23, 2010, at 12:16 PM, Noorul Islam wrote: > On Sat, Oct 23, 2010 at 2:12 PM, Noorul Islam > wrote: >> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley > > wrote: >>> >>> What determines the level of a new capture element? e.g I just >>> created >>> one and it started at "****". >>> >>> feature request : when I added some sub elements to a capture >>> buffer e.g >>> >>> * my new capture >>> >>> ** sub point >>> >>> *** sub sub point 1 >>> *** sub sub point 2 >>> >>> and hit C-c C-w to refile, it only refiled the sub element (where >>> cursor >>> was) and then lost the rest. I would like to suggest that refile >>> from >>> the capture buffer should refile the entire buffer and not only the >>> "current nested org item". Or am I missing something in my setup? >> >> On my box I have this observation. >> >> If I have something like this in my capture buffer >> >> * TODO Test >> >> * my new capture >> >> ** sub point >> >> *** sub sub point 1 >> *** sub sub point 2 >> >> >> and if I press C-c C-w at the last line (*** sub sub point 2) and >> refile it to refile.org then what I get in refile.org is this >> >> >> * TODO Test >> >> * my new capture >> >> ** sub point >> >> *** sub sub point 1 >> * sub sub point 2 >> >> >> The last one's level got changed. >> I have latest pull from git repo. >> >> Org-mode version 7.01trans (release_7.01h.833.g21ad0) >> GNU Emacs 23.2.2 (i686-pc-linux-gnu) >> of 2010-06-08 on sajida >> > > Fix org-capture bug. > > * lisp/org.el (org-capture-refile): Consider entire temporary buffer > for refiling. > diff --git a/lisp/org-capture.el b/lisp/org-capture.el > index 7915f7f..6c62114 100644 > --- a/lisp/org-capture.el > +++ b/lisp/org-capture.el > @@ -548,7 +548,7 @@ already gone." > (unless (eq (org-capture-get :type 'local) 'entry) > (error > "Refiling from a capture buffer makes only sense for `entry'- > type templates")) > - (let ((pos (point)) > + (let ((pos (point-min)) > (base (buffer-base-buffer (current-buffer))) > (org-refile-for-capture t)) > (org-capture-finalize) This patch catures the problem and brings forward a correct idea. But I believe we need to think a bit further. The current implementation of C-c C-w as a way to finish capture works as closely as possible to the standard refile mechanism. I.e. the tree *where the cursor is at* will be refiled. Your patch makes the cursor move back to beginning of the accessible part of the buffer and refiles from there. If the captured entry starts at this point, and if all the narrowed section contains is a single tree, this is a good solution. However, if we move away from having refile work in the exact same way as normally, the following questions arise: 1. Maybe the user has entered an empty line before the subtree. In this case, the outline node *before* the captured tree will now be refiled. 2. Maybe the user has widened the capture buffer. In this case the code will now refile the first node in the buffer, possibly very far from the current location of point. Or, it will throw an error because the may not be an outline node at point min. 3. Maybe the user has added several trees (siblings) into the capture buffer. In this case, the refile will only affect the first of those siblings. So we have two solutions here: Solution 1: Be aware that you are just calling refile, so move the cursor to the appropriate place before running the command. Solution 2: Install two markers at the beginning and end of the region to which the buffer has been narrowed, and then select that entire region for refiling. This is non-trivial, but probably can be made to work. In either case we will probably have to update the manual to make things clearer. - Carsten