Re: Re: Refile target caching

From: Samuel Wales <samologist@gmail.com>
To: Carsten Dominik <dominik@uva.nl>
Cc: mailing-list-org-mode Mode <emacs-orgmode@gnu.org>
Subject: Re: Re: Refile target caching
Date: Mon, 16 Aug 2010 08:44:10 -0700	[thread overview]
Message-ID: <AANLkTika6JmwQouY=7H6YVeccLNjC59sHvNPzXyAht0d@mail.gmail.com> (raw)
In-Reply-To: <6485A455-5FD5-4AAD-A022-6C63CF914043@uva.nl>

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 <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.