On Mon, Oct 25, 2010 at 12:41 PM, Carsten Dominik <carsten.domi...@gmail.com> 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 <noo...@noorul.com> wrote: >>> >>> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rile...@googlemail.com> >>> 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? Thanks and Regards Noorul _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
