emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Maxim Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-refile-use-cache and jumps using org-refile or org-goto
Date: Tue, 2 Mar 2021 19:34:25 -0700	[thread overview]
Message-ID: <CAJcAo8thAftd1VLWYwUK9xxqni3j33oPTx8hCY-sKd+U-iF1rA@mail.gmail.com> (raw)
In-Reply-To: <s1lrqr$nc$1@ciao.gmane.io>

idk if thi will help buit a fwe not3es.  just in case they are
relevant to your case.

fwiw i have not heard of interactions between org-goto and the refile
mechanism and the cache.  i hafve not heard that the latter used a
cache but i do not use it.  refile with and withoyut the goto prefix
should normatively be congruent and both use cache.

i used to use the refile cache, then discovered that ido-hacks sped
ido so much that i didn't need it.  it would cache one fileset and
then be potentially not usable for another.  sort of like one cache
and multiple callers.  idk if htat got fixed.  probably not used much.

until recently in maint, ido and ido hacks with both refile and refile
goto [note: org-refile with a goto arg, not org-goto] has worked
perfectly.  with no cache.  now, there is an issue, where with no
cache that i know of, the first use, or the first use in a long time,
will actually present a huge file list that includes crazy elements
and is not constrained by even the verify function.  thus if i type
faster than it goes, the wrong item gets selected.  even if i use the
same selectors as normal.  so there's some bug or race condition.  it
is slow at those times.  this might not be relevant to your case but
seems worth mentioning.  i think i have not filed a bug report as i
don't know how to repro it at this time.

On 3/2/21, Maxim Nikulin <manikulin@gmail.com> wrote:
> It seems, something goes a bit wrong. However it is rather confusion
> than anything really broken.
> Maybe everybody uses helm, ivy, etc., so nobody is affected.
> Usually I jump from one note to another heading with C-u C-c C-j
> (org-goto interface with target completion). I have not setup helm or
> other similar package. Completion works, maybe it is not really perfect
> (e.g. completion of top-level headings and deeper ones differ a bit). I
> have heard that C-u C-c C-w (org-refile) could work in a similar way. I
> did not like the latter variant due to mandatory file name in the
> beginning of a target.
> I have tried to enable org-refile-use-cache. Now completion options
> depends on what method was called earlier: org-refile or org-goto. If
> after cache clean up (C-u C-u C-u C-c C-w) first command was C-u C-c C-j
> (org-goto) than there is no file name as a prefix for both commands.
> However file name is prepended for both C-u C-c C-j and C-u C-c C-w if
> at first org-refile was called.
> There is one issue however. Default option option does not work if after
> cache clean other command is called, e.g.
> - jump using C-u C-c C-j
> - clean cache C-u C-u C-u C-c C-w
> - try to jump or to refile [C-u] C-c C-w to default offered option
> - "user-error: Invalid target location"
> I have just one file in the org-agenda-files list. It is becoming
> larger, that is why I decided to try org-refile-use-cache. My
> customization is minimal (besides org-default-dir and org-agenda-files):
> (org-refile-targets (quote ((org-agenda-files :maxlevel . 5))))
> (org-outline-path-complete-in-steps nil)
> I have tried to add (nil :maxlevel . 5) to org-refile-targets to check
> if options without file name will appear in addition to ones with file
> name for org-refile, but it has not happened. It was not clear at first
> that it is possible to start query with "/" and file name is added when
> TAB is pressed.
> Is it expected that with cache enabled, command that causes cache update
> affects appearance of completion options to its sibling (org-refile and
> org-goto)?

The Kafka Pandemic

Please learn what misopathy is.

  reply	other threads:[~2021-03-03  2:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 17:15 org-refile-use-cache and jumps using org-refile or org-goto Maxim Nikulin
2021-03-03  2:34 ` Samuel Wales [this message]
2021-03-04 13:51   ` Maxim Nikulin
2021-03-04 21:03     ` Samuel Wales
2021-03-06 16:15       ` [PATCH] optimize org-refile-get-targets Maxim Nikulin
2021-04-25 12:25         ` Bastien
2021-04-25 15:24           ` Maxim Nikulin
2021-03-04 14:47 ` org-refile failed due to default option stored by org-goto Maxim Nikulin
2021-03-04 22:53   ` Samuel Wales
2021-03-09 11:57     ` Maxim Nikulin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcAo8thAftd1VLWYwUK9xxqni3j33oPTx8hCY-sKd+U-iF1rA@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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