Re: Re: Refile target caching

[Carsten Dominik <dominik@uva.nl>]

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 <dominik@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 <dominik@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