* capture initial "level" and refile of capture buffer
@ 2010-10-22 11:43 Richard Riley
2010-10-23 8:42 ` Noorul Islam
2010-10-26 8:53 ` Carsten Dominik
0 siblings, 2 replies; 11+ messages in thread
From: Richard Riley @ 2010-10-22 11:43 UTC (permalink / raw)
To: emacs-orgmode
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?
regards
r.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-22 11:43 capture initial "level" and refile of capture buffer Richard Riley
@ 2010-10-23 8:42 ` Noorul Islam
2010-10-23 10:16 ` Noorul Islam
2010-10-25 11:34 ` Carsten Dominik
2010-10-26 8:53 ` Carsten Dominik
1 sibling, 2 replies; 11+ messages in thread
From: Noorul Islam @ 2010-10-23 8:42 UTC (permalink / raw)
To: Richard Riley; +Cc: emacs-orgmode
On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rileyrg@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
Thanks and Regards
Noorul
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-23 8:42 ` Noorul Islam
@ 2010-10-23 10:16 ` Noorul Islam
2010-10-23 10:34 ` Noorul Islam
2010-10-25 7:11 ` Carsten Dominik
2010-10-25 11:34 ` Carsten Dominik
1 sibling, 2 replies; 11+ messages in thread
From: Noorul Islam @ 2010-10-23 10:16 UTC (permalink / raw)
To: Richard Riley; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1554 bytes --]
On Sat, Oct 23, 2010 at 2:12 PM, Noorul Islam <noorul@noorul.com> wrote:
> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rileyrg@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.
Thanks and Regards
Noorul
[-- Attachment #2: org.el.txt --]
[-- Type: text/plain, Size: 478 bytes --]
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)
[-- Attachment #3: Type: text/plain, Size: 201 bytes --]
_______________________________________________
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-23 10:16 ` Noorul Islam
@ 2010-10-23 10:34 ` Noorul Islam
2010-10-25 7:11 ` Carsten Dominik
1 sibling, 0 replies; 11+ messages in thread
From: Noorul Islam @ 2010-10-23 10:34 UTC (permalink / raw)
To: Richard Riley; +Cc: emacs-orgmode
On Sat, Oct 23, 2010 at 3:46 PM, Noorul Islam <noorul@noorul.com> wrote:
> On Sat, Oct 23, 2010 at 2:12 PM, Noorul Islam <noorul@noorul.com> wrote:
>> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rileyrg@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.
>
Sorry incorrect log message. Here is the correct one.
Fix org-capture bug.
* lisp/org-capture.el (org-capture-refile): Consider entire temporary buffer
for refiling.
Thanks and Regards
Noorul
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-23 10:16 ` Noorul Islam
2010-10-23 10:34 ` Noorul Islam
@ 2010-10-25 7:11 ` Carsten Dominik
2010-10-25 8:54 ` Noorul Islam
1 sibling, 1 reply; 11+ messages in thread
From: Carsten Dominik @ 2010-10-25 7:11 UTC (permalink / raw)
To: Noorul Islam; +Cc: Richard Riley, emacs-orgmode
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 <noorul@noorul.com>
> wrote:
>> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rileyrg@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.
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-25 7:11 ` Carsten Dominik
@ 2010-10-25 8:54 ` Noorul Islam
2010-10-25 9:11 ` Carsten Dominik
2010-12-12 8:39 ` Carsten Dominik
0 siblings, 2 replies; 11+ messages in thread
From: Noorul Islam @ 2010-10-25 8:54 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Richard Riley, emacs-orgmode
On Mon, Oct 25, 2010 at 12:41 PM, Carsten Dominik
<carsten.dominik@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 <noorul@noorul.com> wrote:
>>>
>>> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rileyrg@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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-25 8:54 ` Noorul Islam
@ 2010-10-25 9:11 ` Carsten Dominik
2010-12-12 8:39 ` Carsten Dominik
1 sibling, 0 replies; 11+ messages in thread
From: Carsten Dominik @ 2010-10-25 9:11 UTC (permalink / raw)
To: Noorul Islam; +Cc: Richard Riley, emacs-orgmode
On Oct 25, 2010, at 10:54 AM, Noorul Islam wrote:
> On Mon, Oct 25, 2010 at 12:41 PM, Carsten Dominik
> <carsten.dominik@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 <noorul@noorul.com>
>>> wrote:
>>>>
>>>> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rileyrg@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?
Still need to look at that one.
- Carsten
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-23 8:42 ` Noorul Islam
2010-10-23 10:16 ` Noorul Islam
@ 2010-10-25 11:34 ` Carsten Dominik
2010-10-26 8:37 ` Noorul Islam
1 sibling, 1 reply; 11+ messages in thread
From: Carsten Dominik @ 2010-10-25 11:34 UTC (permalink / raw)
To: Noorul Islam; +Cc: Richard Riley, emacs-orgmode
Hi Noorul,
could you please make a more detailed test case of this but, with an
example files (capture target and refile target files) and step by
step instructions. I am not sure I understand what exactly you are
doing.
Thanks.
- Carsten
On Oct 23, 2010, at 10:42 AM, Noorul Islam wrote:
> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley
> <rileyrg@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
>
> 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
- Carsten
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-25 11:34 ` Carsten Dominik
@ 2010-10-26 8:37 ` Noorul Islam
0 siblings, 0 replies; 11+ messages in thread
From: Noorul Islam @ 2010-10-26 8:37 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Richard Riley, emacs-orgmode
On Mon, Oct 25, 2010 at 5:04 PM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
> Hi Noorul,
>
> could you please make a more detailed test case of this but, with an example
> files (capture target and refile target files) and step by step
> instructions. I am not sure I understand what exactly you are doing.
>
I think it was my misunderstanding of how C-c C-w works inside org
capture. I think, now I have a clear picture and the behavior that I
mentioned was an expected one.
I was trying to refile to target file.
Thanks and Regards
Noorul
> On Oct 23, 2010, at 10:42 AM, Noorul Islam wrote:
>
>> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rileyrg@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
>>
>> 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
>
> - Carsten
>
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-22 11:43 capture initial "level" and refile of capture buffer Richard Riley
2010-10-23 8:42 ` Noorul Islam
@ 2010-10-26 8:53 ` Carsten Dominik
1 sibling, 0 replies; 11+ messages in thread
From: Carsten Dominik @ 2010-10-26 8:53 UTC (permalink / raw)
To: Richard Riley; +Cc: emacs-orgmode
On Oct 22, 2010, at 1:43 PM, Richard Riley wrote:
>
> What determines the level of a new capture element? e.g I just created
> one and it started at "****".
That is dependent on where your target is. If the target is a level 3
entry,
then the capture item will be level 4.
>
> 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?
You need to move the cursor back to the parent. C-c C-w rund the
normal refiling command, which refiles the entry at point.
HTH
- Carsten
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: capture initial "level" and refile of capture buffer
2010-10-25 8:54 ` Noorul Islam
2010-10-25 9:11 ` Carsten Dominik
@ 2010-12-12 8:39 ` Carsten Dominik
1 sibling, 0 replies; 11+ messages in thread
From: Carsten Dominik @ 2010-12-12 8:39 UTC (permalink / raw)
To: Noorul Islam; +Cc: Richard Riley, emacs-orgmode
On Oct 25, 2010, at 10:54 AM, Noorul Islam wrote:
> On Mon, Oct 25, 2010 at 12:41 PM, Carsten Dominik
> <carsten.dominik@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 <noorul@noorul.com>
>>> wrote:
>>>>
>>>> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley <rileyrg@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?
Which bug was that again? Can you point me to the message/thread?
Thanks.
- Carsten
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-12-12 8:39 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-22 11:43 capture initial "level" and refile of capture buffer Richard Riley
2010-10-23 8:42 ` Noorul Islam
2010-10-23 10:16 ` Noorul Islam
2010-10-23 10:34 ` Noorul Islam
2010-10-25 7:11 ` Carsten Dominik
2010-10-25 8:54 ` Noorul Islam
2010-10-25 9:11 ` Carsten Dominik
2010-12-12 8:39 ` Carsten Dominik
2010-10-25 11:34 ` Carsten Dominik
2010-10-26 8:37 ` Noorul Islam
2010-10-26 8:53 ` Carsten Dominik
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).