From: Samuel Wales <firstname.lastname@example.org>
Subject: refile ideas
Date: Tue, 7 Jul 2009 21:59:58 -0700 [thread overview]
Message-ID: <email@example.com> (raw)
With ido completion, refiling works excellently. Here are
First (and foremost), input history for refiling recalls the user's
input, not refile targets. I think the latter would work
better, because in ordinary use, the user can specify
further with C-SPC and arrow keys. So the first completion
candidate for any of the history items can be different from
the target that it originally specified. Thus, the natural
action of up arrows can specify an unexpected location.
Even when the user notices the problem, he has to specify
further to duplicate the effort if he wants the original
In my use since ido completion began, I almost never want
the original string, and almost always want the original
target. I don't know if others use refile history differently.
Thus, the proposal is to have the history contain the
The next idea is that we already have a specification of
potentially useful targets in remember templates. I wonder
if a useful interface (perhaps a triple c-u to org-refile or
perhaps using remember) can allow the user to use the
remember templates to specify a target location. Thus a
single key can uniquely specify a target without the user
having to verify.
Another idea is that in ido completion for refile and other
commands that require specification of headlines, perhaps a
more familiar context can be provided. In particular, the
todo keyword and priority, with their original colors, might
be a familiar way of seeing them, and might visually
indicate the start of a new completion candidate. This will
make it quicker to know whether more specification is
necessary or whether right arrows will work.
Another idea is to color the paths separately from the
leaves, or color the olpath components that are matched by
the input string, or color the input string matches. This
might be difficult to implement or too slow. Since ido is already too
slow (but very useful), it would only be worth it if it did not slow
Another idea is to color the vertical bars.
Another idea we've already discussed, but I will mention it
here just for completeness. The olpath could perhaps be
displayed using a uniquification algorithm similar to that
used by uniquify.el. This might or might not be worth it.
Myalgic encephalomyelitis causes death and severe suffering.
You can get it any time and never recover. Conflicts of
interest are destroying research. Do science and justice
matter to you? http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm
next reply other threads:[~2009-07-08 5:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-08 4:59 Samuel Wales [this message]
2009-08-03 4:28 ` refile ideas Carsten Dominik
2009-08-03 22:31 ` Samuel Wales
2009-08-04 12:44 ` Eric S Fraga
2009-08-05 6:41 ` Carsten Dominik
2009-08-05 13:00 ` Interactively add refile targets - was: " Sebastian Rose
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 \
* 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).