From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noorul Islam Subject: Re: capture initial "level" and refile of capture buffer Date: Mon, 25 Oct 2010 14:24:52 +0530 Message-ID: References: <4D2F89B4-6F6C-411D-B272-3FF3DAD80B23@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=58618 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PAIpU-00076E-A9 for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:54:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PAIpS-0005CE-Br for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:54:56 -0400 Received: from mail-yw0-f41.google.com ([209.85.213.41]:35108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PAIpS-0005C9-9V for emacs-orgmode@gnu.org; Mon, 25 Oct 2010 04:54:54 -0400 Received: by ywp4 with SMTP id 4so2482615ywp.0 for ; Mon, 25 Oct 2010 01:54:53 -0700 (PDT) In-Reply-To: <4D2F89B4-6F6C-411D-B272-3FF3DAD80B23@gmail.com> 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: Carsten Dominik Cc: Richard Riley , emacs-orgmode@gnu.org On Mon, Oct 25, 2010 at 12:41 PM, Carsten Dominik wrote: > 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 curs= or >>>> 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) >>> =A0of 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." >> =A0 (unless (eq (org-capture-get :type 'local) 'entry) >> =A0 =A0 (error >> =A0 =A0 =A0"Refiling from a capture buffer makes only sense for `entry'-= type >> templates")) >> - =A0(let ((pos (point)) >> + =A0(let ((pos (point-min)) >> =A0 =A0 =A0 =A0(base (buffer-base-buffer (current-buffer))) >> =A0 =A0 =A0 =A0(org-refile-for-capture t)) >> =A0 =A0 (org-capture-finalize) > > > This patch catures the problem and brings forward a correct idea. > But I believe we need to think a bit further. =A0The 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. > =A0 In this case, the outline node *before* the captured tree > =A0 will now be refiled. > > 2. Maybe the user has widened the capture buffer. =A0In this case > =A0 the code will now refile the first node in the buffer, possibly > =A0 very far from the current location of point. =A0Or, it will > =A0 throw an error because the may not be an outline > =A0 node at point min. > > 3. Maybe the user has added several trees (siblings) into the > =A0 capture buffer. =A0In this case, the refile will only > =A0 affect the first of those siblings. > Fair enough. Thank you! > So we have two solutions here: > > Solution 1: =A0Be aware that you are just calling refile, so > =A0 =A0 =A0 =A0 =A0 =A0 move the cursor to the appropriate place before > =A0 =A0 =A0 =A0 =A0 =A0 running the command. > If we insist this in the manual then I think no change is required. But what about the bug that I mentioned earlier, the one that looses the le= vel? Thanks and Regards Noorul