From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: capture initial "level" and refile of capture buffer Date: Sun, 12 Dec 2010 09:39:39 +0100 Message-ID: <64C29BFD-25B1-4C9B-A2BC-CA94CA2166A1@gmail.com> References: <4D2F89B4-6F6C-411D-B272-3FF3DAD80B23@gmail.com> 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=38170 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PRhT9-0004kc-Ik for emacs-orgmode@gnu.org; Sun, 12 Dec 2010 03:39:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PRhT7-0006NO-J5 for emacs-orgmode@gnu.org; Sun, 12 Dec 2010 03:39:47 -0500 Received: from mail-ew0-f43.google.com ([209.85.215.43]:40506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PRhT7-0006NJ-9b for emacs-orgmode@gnu.org; Sun, 12 Dec 2010 03:39:45 -0500 Received: by ewy22 with SMTP id 22so3244414ewy.30 for ; Sun, 12 Dec 2010 00:39:44 -0800 (PST) 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 On Oct 25, 2010, at 10:54 AM, Noorul Islam wrote: > 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 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. >> > > Fair enough. Thank you! > >> 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. >> > > 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 level? Which bug was that again? Can you point me to the message/thread? Thanks. - Carsten