Maxim Nikulin writes:
> helm-org-ql.el that is a part of org-ql does not use cache when calling
> org-get-outline-path. helm-org performs sequential scan similar to
> org-refile-get-targets.
Hmm. You are right. But they could. I myself ran into an issue with
helm-org-ql exactly because formatt
On 02/05/2021 13:59, Ihor Radchenko wrote:
Maxim Nikulin writes:
Some additions. org-outline-path-cache is used solely by
org-refile-get-targets (maybe there are some calls in other packages)
but it efficiency is questionable. It was not clear for me earlier that
the cache is reset before each
Tim Cross writes:
> I suspect the reason it is not done automatically is that getting that
> right for all use cases is very hard to do without adding adverse impact
> to performance. A cache which is marked as 'dirty' too often results in
> too frequent cache refresh operations, but at the same
Maxim Nikulin writes:
> Some additions. org-outline-path-cache is used solely by
> org-refile-get-targets (maybe there are some calls in other packages)
> but it efficiency is questionable. It was not clear for me earlier that
> the cache is reset before each scan through a buffer. So if
> or
On 29/04/2021 23:08, Ihor Radchenko wrote:
My experience is exactly opposite. Or maybe I miss something. Can you
elaborate?
Some additions. org-outline-path-cache is used solely by
org-refile-get-targets (maybe there are some calls in other packages)
but it efficiency is questionable. It was
On 29/04/2021 23:08, Ihor Radchenko wrote:
Did you do any benchmarks? I just tried
Outline path without cache:
I have expanded your tests to make them more close to org-get-outline-path
org-get-outline-path without cache
| 5.459114059 | 12 | 1.205358000987 |
org-get-outline-path with cach
some users of org might not know that org-refile can go to the
location without refiling anything if you pass a c-u arg.
thus, org-goto is not the only header-selecting goto mechanism; there
is also refile goto. [and imenu, helm, etc.]
i use refile-goto and find it satisfying for my purposes. t
Ihor Radchenko writes:
> Samuel Wales writes:
>
>> would it be more useful if it automaticaly generated the cache instead
>> of telling you to runt he command to do so?
>
> I think so. To be frank, I do not understand the reason why it is not
> done by default.
>
>> if a solid, perhaps unified
On 29/04/2021 23:08, Ihor Radchenko wrote:
Maxim Nikulin writes:
Curiously my experience is that avoiding this lazy cache with
backtracking and maintaining custom structure during sequential scan of
the buffer works several times faster.
My experience is exactly opposite. Or maybe I miss some
Maxim Nikulin writes:
> Curiously my experience is that avoiding this lazy cache with
> backtracking and maintaining custom structure during sequential scan of
> the buffer works several times faster.
My experience is exactly opposite. Or maybe I miss something. Can you
elaborate?
> ... Howev
On 29/04/2021 21:12, Ihor Radchenko wrote:
There is org-outline-path-cache used by org-get-outline-cache. It avoids
computing parent's outline path multiple times, which is already a great
improvement.
Curiously my experience is that avoiding this lazy cache with
backtracking and maintaining c
Maxim Nikulin writes:
> Maybe I could avoid org-goto as well. Actual reason to use it was that
> it does not ask for file name as the first step in the case of
> (org-refile-use-outline-path 'file). It took enough time to me to
> realize how to jump/refile to non-leaf heading without such sett
Samuel Wales writes:
> would it be more useful if it automaticaly generated the cache instead
> of telling you to runt he command to do so?
I think so. To be frank, I do not understand the reason why it is not
done by default.
> if a solid, perhaps unified, cache existed, would org-id use it to
On 29/04/2021 08:29, Ihor Radchenko wrote:
I do not observe the breakage as described in the first message,
mostly because I use refile cache exclusively for org-refile.
Maybe I could avoid org-goto as well. Actual reason to use it was that
it does not ask for file name as the first step in th
thanks for reporting that you use it.
would it be more useful if it automaticaly generated the cache instead
of telling you to runt he command to do so?
if a solid, perhaps unified, cache existed, would org-id use it too?
On 4/28/21, Ihor Radchenko wrote:
> Samuel Wales writes:
>
>> long ago i
Samuel Wales writes:
> long ago i used to use the refile cache. i think it is probably not
> widely used, or maybe even not at all.
At least, I do use it. A lot. I rely on it.
I do not observe the breakage as described in the first message, mostly
because I use refile cache exclusively for org
long ago i used to use the refile cache. i think it is probably not
widely used, or maybe even not at all.
the reason i stopped was behavior that sounds similar to your
description. such as, it would produce a set of results that did not
match the calling conditions. i cannot reach the thread y
Reviewing my attempt to speedup collecting of refile targets
https://orgmode.org/list/s209r8$16en$1...@ciao.gmane.io/
I have realized that refile cache is unreliable.
With specific customization, cache content and thus refile targets
depend on the function called first: `org-refile' ([C-u] C-c C
18 matches
Mail list logo
