Re: [Orgmode] Re: Refile target caching

2010-08-16 Thread Carsten Dominik


On Aug 2, 2010, at 4:49 AM, Samuel Wales wrote:


Hi Carsten,

Thank you for thinking of our bugs.  This is superb.

I have used it for a while now.

It speeds things up enormously, making the difference between  
usability and not.


However, I have definitely had headlines get refiled to the wrong
place.


Ouch, this is bad.

If you do a lot of moving stuff around in the buffer, the markers
pointing to refile locations will become wrong.  So you then need
to clear the cache, to make sure you get fresh positions.

A good example where it goes wrong would, of cause, be useful.

- Carsten



 I am not able to track it down now, but I do have a
suggestion.

== Would it be possible to print the actual target that the headline
got refiled to, instead of the name associated with the marker?  At
present, org says that it successfully refiled to the target headline
when it did not.

== Alternatively, org could compare the actual headline it was
refiled to against the headline it was supposed to refile to.  Then
you'd get an error if they do not match.

As for the bugs, I cannot investigate further now.  Debugging is
difficult for me.

Perhaps more error checking as above will make the bug show up better.

Thanks.

Samuel

On 2010-05-17, Carsten Dominik domi...@uva.nl wrote:

Hi Sebastian, hi Samuel,

I remember that both of you have in the past reported that refiling
has a long startup time because of target collection.

I have now built a cache for refile targets and would like you to try
it out.

(setq org-refile-use-cache t)

This will speed up refile target collection for the second and  
further

instance.
If you are moving or adding entries that are targets themselves, that
chace needs to be cleared with prefix arg 0 (zero), i.e. `C-0 C-c C- 
w'

or, if you prefer, with a triple C-u prefix.

Samuel, note that this only speeds up target collection - it does
nothing to the overhead added by ido - so we will have to see how  
much

this helps for your use-case.


- Carsten







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for  
25 years]

==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html

___
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




___
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


Re: [Orgmode] Re: Refile target caching

2010-08-16 Thread Carsten Dominik


On Aug 16, 2010, at 5:44 PM, Samuel Wales wrote:


Hi Carsten,

I proposed a way in the rest of my bug report to find out when this
happens.  Without that, I don't think I can track it down.

I sort outline entries all the time.  Therefore, I run into marker
problems all the time.

So that would not be surprising.


Yes, sorting is one of the issues that will loose markers.

- Carsten



Samuel


P.S.  The running clock also gets lost all the time.  Even when  
point is in it!


On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:


On Aug 2, 2010, at 4:49 AM, Samuel Wales wrote:


Hi Carsten,

Thank you for thinking of our bugs.  This is superb.

I have used it for a while now.

It speeds things up enormously, making the difference between
usability and not.

However, I have definitely had headlines get refiled to the wrong
place.


Ouch, this is bad.

If you do a lot of moving stuff around in the buffer, the markers
pointing to refile locations will become wrong.  So you then need
to clear the cache, to make sure you get fresh positions.

A good example where it goes wrong would, of cause, be useful.

- Carsten



I am not able to track it down now, but I do have a
suggestion.

== Would it be possible to print the actual target that the  
headline

got refiled to, instead of the name associated with the marker?  At
present, org says that it successfully refiled to the target  
headline

when it did not.

== Alternatively, org could compare the actual headline it was
refiled to against the headline it was supposed to refile to.  Then
you'd get an error if they do not match.

As for the bugs, I cannot investigate further now.  Debugging is
difficult for me.

Perhaps more error checking as above will make the bug show up  
better.


Thanks.

Samuel

On 2010-05-17, Carsten Dominik domi...@uva.nl wrote:

Hi Sebastian, hi Samuel,

I remember that both of you have in the past reported that refiling
has a long startup time because of target collection.

I have now built a cache for refile targets and would like you to  
try

it out.

(setq org-refile-use-cache t)

This will speed up refile target collection for the second and
further
instance.
If you are moving or adding entries that are targets themselves,  
that
chace needs to be cleared with prefix arg 0 (zero), i.e. `C-0 C-c  
C-

w'
or, if you prefer, with a triple C-u prefix.

Samuel, note that this only speeds up target collection - it does
nothing to the overhead added by ido - so we will have to see how
much
this helps for your use-case.


- Carsten







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for
25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html

___
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







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for  
25 years]

==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE  
DONATE

===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.


- Carsten




___
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


Re: [Orgmode] Re: Refile target caching

2010-08-16 Thread Samuel Wales
Hi Carsten,

I proposed a way in the rest of my bug report to find out when this
happens.  Without that, I don't think I can track it down.

I sort outline entries all the time.  Therefore, I run into marker
problems all the time.

So that would not be surprising.

Samuel


P.S.  The running clock also gets lost all the time.  Even when point is in it!

On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:

 On Aug 2, 2010, at 4:49 AM, Samuel Wales wrote:

 Hi Carsten,

 Thank you for thinking of our bugs.  This is superb.

 I have used it for a while now.

 It speeds things up enormously, making the difference between
 usability and not.

 However, I have definitely had headlines get refiled to the wrong
 place.

 Ouch, this is bad.

 If you do a lot of moving stuff around in the buffer, the markers
 pointing to refile locations will become wrong.  So you then need
 to clear the cache, to make sure you get fresh positions.

 A good example where it goes wrong would, of cause, be useful.

 - Carsten


  I am not able to track it down now, but I do have a
 suggestion.

 == Would it be possible to print the actual target that the headline
 got refiled to, instead of the name associated with the marker?  At
 present, org says that it successfully refiled to the target headline
 when it did not.

 == Alternatively, org could compare the actual headline it was
 refiled to against the headline it was supposed to refile to.  Then
 you'd get an error if they do not match.

 As for the bugs, I cannot investigate further now.  Debugging is
 difficult for me.

 Perhaps more error checking as above will make the bug show up better.

 Thanks.

 Samuel

 On 2010-05-17, Carsten Dominik domi...@uva.nl wrote:
 Hi Sebastian, hi Samuel,

 I remember that both of you have in the past reported that refiling
 has a long startup time because of target collection.

 I have now built a cache for refile targets and would like you to try
 it out.

 (setq org-refile-use-cache t)

 This will speed up refile target collection for the second and
 further
 instance.
 If you are moving or adding entries that are targets themselves, that
 chace needs to be cleared with prefix arg 0 (zero), i.e. `C-0 C-c C-
 w'
 or, if you prefer, with a triple C-u prefix.

 Samuel, note that this only speeds up target collection - it does
 nothing to the overhead added by ido - so we will have to see how
 much
 this helps for your use-case.


 - Carsten






 --
 Q: How many CDC scientists does it take to change a lightbulb?
 A: You only think it's dark. [CDC has denied a deadly disease for
 25 years]
 ==
 Retrovirus: http://www.wpinstitute.org/xmrv/index.html

 ___
 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






-- 
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for 25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.

___
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


Re: [Orgmode] Re: Refile target caching

2010-08-16 Thread Samuel Wales
On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:
 Yes, sorting is one of the issues that will loose markers.

Do you think that a cautious move here would be to compare the
headline of the target to the headline you think matches the target?
Then the refile can be aborted if they do not match.


 - Carsten


 Samuel


 P.S.  The running clock also gets lost all the time.  Even when
 point is in it!

 On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:

 On Aug 2, 2010, at 4:49 AM, Samuel Wales wrote:

 Hi Carsten,

 Thank you for thinking of our bugs.  This is superb.

 I have used it for a while now.

 It speeds things up enormously, making the difference between
 usability and not.

 However, I have definitely had headlines get refiled to the wrong
 place.

 Ouch, this is bad.

 If you do a lot of moving stuff around in the buffer, the markers
 pointing to refile locations will become wrong.  So you then need
 to clear the cache, to make sure you get fresh positions.

 A good example where it goes wrong would, of cause, be useful.

 - Carsten


 I am not able to track it down now, but I do have a
 suggestion.

 == Would it be possible to print the actual target that the
 headline
 got refiled to, instead of the name associated with the marker?  At
 present, org says that it successfully refiled to the target
 headline
 when it did not.

 == Alternatively, org could compare the actual headline it was
 refiled to against the headline it was supposed to refile to.  Then
 you'd get an error if they do not match.

 As for the bugs, I cannot investigate further now.  Debugging is
 difficult for me.

 Perhaps more error checking as above will make the bug show up
 better.

 Thanks.

 Samuel

 On 2010-05-17, Carsten Dominik domi...@uva.nl wrote:
 Hi Sebastian, hi Samuel,

 I remember that both of you have in the past reported that refiling
 has a long startup time because of target collection.

 I have now built a cache for refile targets and would like you to
 try
 it out.

 (setq org-refile-use-cache t)

 This will speed up refile target collection for the second and
 further
 instance.
 If you are moving or adding entries that are targets themselves,
 that
 chace needs to be cleared with prefix arg 0 (zero), i.e. `C-0 C-c
 C-
 w'
 or, if you prefer, with a triple C-u prefix.

 Samuel, note that this only speeds up target collection - it does
 nothing to the overhead added by ido - so we will have to see how
 much
 this helps for your use-case.


 - Carsten






 --
 Q: How many CDC scientists does it take to change a lightbulb?
 A: You only think it's dark. [CDC has denied a deadly disease for
 25 years]
 ==
 Retrovirus: http://www.wpinstitute.org/xmrv/index.html

 ___
 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






 --
 Q: How many CDC scientists does it take to change a lightbulb?
 A: You only think it's dark. [CDC has denied a deadly disease for
 25 years]
 ==
 Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE
 DONATE
 ===
 PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
 verbatim along with the new paper.

 - Carsten






-- 
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for 25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.

___
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


Re: [Orgmode] Re: Refile target caching

2010-08-16 Thread Carsten Dominik


On Aug 16, 2010, at 5:55 PM, Samuel Wales wrote:


On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:

Yes, sorting is one of the issues that will loose markers.


Do you think that a cautious move here would be to compare the
headline of the target to the headline you think matches the target?
Then the refile can be aborted if they do not match.


Hi Samuel,

yes, this is in fact a good secure measure - sorry for making it you
say it three times before getting the idea.

This should be working now.

Best wishes

- Carsten





- Carsten



Samuel


P.S.  The running clock also gets lost all the time.  Even when
point is in it!

On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:


On Aug 2, 2010, at 4:49 AM, Samuel Wales wrote:


Hi Carsten,

Thank you for thinking of our bugs.  This is superb.

I have used it for a while now.

It speeds things up enormously, making the difference between
usability and not.

However, I have definitely had headlines get refiled to the wrong
place.


Ouch, this is bad.

If you do a lot of moving stuff around in the buffer, the markers
pointing to refile locations will become wrong.  So you then need
to clear the cache, to make sure you get fresh positions.

A good example where it goes wrong would, of cause, be useful.

- Carsten



I am not able to track it down now, but I do have a
suggestion.

== Would it be possible to print the actual target that the
headline
got refiled to, instead of the name associated with the marker?   
At

present, org says that it successfully refiled to the target
headline
when it did not.

== Alternatively, org could compare the actual headline it was
refiled to against the headline it was supposed to refile to.   
Then

you'd get an error if they do not match.

As for the bugs, I cannot investigate further now.  Debugging is
difficult for me.

Perhaps more error checking as above will make the bug show up
better.

Thanks.

Samuel

On 2010-05-17, Carsten Dominik domi...@uva.nl wrote:

Hi Sebastian, hi Samuel,

I remember that both of you have in the past reported that  
refiling

has a long startup time because of target collection.

I have now built a cache for refile targets and would like you to
try
it out.

(setq org-refile-use-cache t)

This will speed up refile target collection for the second and
further
instance.
If you are moving or adding entries that are targets themselves,
that
chace needs to be cleared with prefix arg 0 (zero), i.e. `C-0 C-c
C-
w'
or, if you prefer, with a triple C-u prefix.

Samuel, note that this only speeds up target collection - it does
nothing to the overhead added by ido - so we will have to see how
much
this helps for your use-case.


- Carsten







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease  
for

25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html

___
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







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for
25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE
DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.


- Carsten







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for  
25 years]

==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE  
DONATE

===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.

___
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




___
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


Re: [Orgmode] Re: Refile target caching

2010-08-16 Thread Samuel Wales
Thanks, Carsten.

___
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


Re: [Orgmode] Re: Refile target caching

2010-08-16 Thread Samuel Wales
It tries to call looking-at-p.

Is that a 23ism?

I run Emacs 22.

If that isn't it, I will do a backtrace etc.

Thanks.

On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:

 On Aug 16, 2010, at 5:55 PM, Samuel Wales wrote:

 On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:
 Yes, sorting is one of the issues that will loose markers.

 Do you think that a cautious move here would be to compare the
 headline of the target to the headline you think matches the target?
 Then the refile can be aborted if they do not match.

 Hi Samuel,

 yes, this is in fact a good secure measure - sorry for making it you
 say it three times before getting the idea.

 This should be working now.

 Best wishes

 - Carsten



 - Carsten


 Samuel


 P.S.  The running clock also gets lost all the time.  Even when
 point is in it!

 On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:

 On Aug 2, 2010, at 4:49 AM, Samuel Wales wrote:

 Hi Carsten,

 Thank you for thinking of our bugs.  This is superb.

 I have used it for a while now.

 It speeds things up enormously, making the difference between
 usability and not.

 However, I have definitely had headlines get refiled to the wrong
 place.

 Ouch, this is bad.

 If you do a lot of moving stuff around in the buffer, the markers
 pointing to refile locations will become wrong.  So you then need
 to clear the cache, to make sure you get fresh positions.

 A good example where it goes wrong would, of cause, be useful.

 - Carsten


 I am not able to track it down now, but I do have a
 suggestion.

 == Would it be possible to print the actual target that the
 headline
 got refiled to, instead of the name associated with the marker?
 At
 present, org says that it successfully refiled to the target
 headline
 when it did not.

 == Alternatively, org could compare the actual headline it was
 refiled to against the headline it was supposed to refile to.
 Then
 you'd get an error if they do not match.

 As for the bugs, I cannot investigate further now.  Debugging is
 difficult for me.

 Perhaps more error checking as above will make the bug show up
 better.

 Thanks.

 Samuel

 On 2010-05-17, Carsten Dominik domi...@uva.nl wrote:
 Hi Sebastian, hi Samuel,

 I remember that both of you have in the past reported that
 refiling
 has a long startup time because of target collection.

 I have now built a cache for refile targets and would like you to
 try
 it out.

 (setq org-refile-use-cache t)

 This will speed up refile target collection for the second and
 further
 instance.
 If you are moving or adding entries that are targets themselves,
 that
 chace needs to be cleared with prefix arg 0 (zero), i.e. `C-0 C-c
 C-
 w'
 or, if you prefer, with a triple C-u prefix.

 Samuel, note that this only speeds up target collection - it does
 nothing to the overhead added by ido - so we will have to see how
 much
 this helps for your use-case.


 - Carsten






 --
 Q: How many CDC scientists does it take to change a lightbulb?
 A: You only think it's dark. [CDC has denied a deadly disease
 for
 25 years]
 ==
 Retrovirus: http://www.wpinstitute.org/xmrv/index.html

 ___
 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






 --
 Q: How many CDC scientists does it take to change a lightbulb?
 A: You only think it's dark. [CDC has denied a deadly disease for
 25 years]
 ==
 Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE
 DONATE
 ===
 PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
 verbatim along with the new paper.

 - Carsten






 --
 Q: How many CDC scientists does it take to change a lightbulb?
 A: You only think it's dark. [CDC has denied a deadly disease for
 25 years]
 ==
 Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE
 DONATE
 ===
 PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
 verbatim along with the new paper.

 ___
 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






-- 
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for 25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.

___
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


Re: [Orgmode] Re: Refile target caching

2010-08-16 Thread Carsten Dominik


On Aug 17, 2010, at 3:11 AM, Samuel Wales wrote:


It tries to call looking-at-p.


Oops, bug.  Fixed now.

- Carsten



Is that a 23ism?

I run Emacs 22.

If that isn't it, I will do a backtrace etc.

Thanks.

On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:


On Aug 16, 2010, at 5:55 PM, Samuel Wales wrote:


On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:

Yes, sorting is one of the issues that will loose markers.


Do you think that a cautious move here would be to compare the
headline of the target to the headline you think matches the target?
Then the refile can be aborted if they do not match.


Hi Samuel,

yes, this is in fact a good secure measure - sorry for making it you
say it three times before getting the idea.

This should be working now.

Best wishes

- Carsten





- Carsten



Samuel


P.S.  The running clock also gets lost all the time.  Even when
point is in it!

On 2010-08-16, Carsten Dominik domi...@uva.nl wrote:


On Aug 2, 2010, at 4:49 AM, Samuel Wales wrote:


Hi Carsten,

Thank you for thinking of our bugs.  This is superb.

I have used it for a while now.

It speeds things up enormously, making the difference between
usability and not.

However, I have definitely had headlines get refiled to the  
wrong

place.


Ouch, this is bad.

If you do a lot of moving stuff around in the buffer, the markers
pointing to refile locations will become wrong.  So you then need
to clear the cache, to make sure you get fresh positions.

A good example where it goes wrong would, of cause, be useful.

- Carsten



I am not able to track it down now, but I do have a
suggestion.

== Would it be possible to print the actual target that the
headline
got refiled to, instead of the name associated with the marker?
At
present, org says that it successfully refiled to the target
headline
when it did not.

== Alternatively, org could compare the actual headline it was
refiled to against the headline it was supposed to refile to.
Then
you'd get an error if they do not match.

As for the bugs, I cannot investigate further now.  Debugging is
difficult for me.

Perhaps more error checking as above will make the bug show up
better.

Thanks.

Samuel

On 2010-05-17, Carsten Dominik domi...@uva.nl wrote:

Hi Sebastian, hi Samuel,

I remember that both of you have in the past reported that
refiling
has a long startup time because of target collection.

I have now built a cache for refile targets and would like  
you to

try
it out.

(setq org-refile-use-cache t)

This will speed up refile target collection for the second and
further
instance.
If you are moving or adding entries that are targets  
themselves,

that
chace needs to be cleared with prefix arg 0 (zero), i.e. `C-0  
C-c

C-
w'
or, if you prefer, with a triple C-u prefix.

Samuel, note that this only speeds up target collection - it  
does
nothing to the overhead added by ido - so we will have to see  
how

much
this helps for your use-case.


- Carsten







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease
for
25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html

___
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







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease  
for

25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE
DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.


- Carsten







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for
25 years]
==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE
DONATE
===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.

___
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







--
Q: How many CDC scientists does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied a deadly disease for  
25 years]

==
Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE  
DONATE

===
PNAS must publish the original Lo and Alter NIH/FDA XMRV paper
verbatim along with the new paper.


- Carsten




___
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


Re: [Orgmode] Re: Refile target caching

2010-05-18 Thread Carsten Dominik


On May 18, 2010, at 2:14 AM, Richard Riley wrote:


Carsten Dominik domi...@uva.nl writes:


Hi Sebastian, hi Samuel,

I remember that both of you have in the past reported that refiling
has a long startup time because of target collection.

I have now built a cache for refile targets and would like you to try
it out.

(setq org-refile-use-cache t)

This will speed up refile target collection for the second and  
further

instance.
If you are moving or adding entries that are targets themselves, that
chace needs to be cleared with prefix arg 0 (zero), i.e. `C-0 C-c C- 
w'

or, if you prefer, with a triple C-u prefix.

Samuel, note that this only speeds up target collection - it does
nothing to the overhead added by ido - so we will have to see how  
much

this helps for your use-case.

- Carsten



On the subject of refile, I frequently refile C-c C-w from the new  
item

buffer in which case the item is correctly refiled but the new item
buffer empties and remains open. Is there a way to configure it that  
after

the C-c C-w the new org item buffer closes?



By new item buffer, do you mean a remember buffer?  Then:

Just exit with `C-1 C-c C-c'.  This will use refile to file the
new entry, and it will remove the buffer.

HTH

- Carsten





___
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




___
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