refile ideas

refile ideas

[Samuel Wales]

With ido completion, refiling works excellently.  Here are
more ideas.

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

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
fully-specified targets.

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

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.

Thanks.

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

Re: refile ideas

[Carsten Dominik]

On Jul 8, 2009, at 6:59 AM, Samuel Wales wrote:

> With ido completion, refiling works excellently.  Here are
> more ideas.
>
> 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
> target.
>
> 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
> fully-specified targets.

This is a good idea, and it works now just so.

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

This is not easy, the remember and refile interfaces
do not easily mix.  Here is an alternative idea:

If you mark some headlines (for example you remember targets)
with a tag like "r", you could make yourself a restricted
refile command like this:

(defun my-org-restricted-refile ()
   (interactive)
   (let ((org-refile-targets '((org-agenda-files :tag . "r"))))
     (call-interactively 'org-refile)))

Not what you proposed, but maybe useful.


Most of the ideas below require hacking ido.el, which I am not
ready to do.  In particular, coloring the vertical bars should
be a feature request to Kim.

Coloring the path, or uniquifying the path is something that
*might* work on the Org side, and I have added these to my
list.

- Carsten

> 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
> it down.
>
> 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.
>
> Thanks.
>
> --  
> 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
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: refile ideas

[Samuel Wales]

Hi Carsten,

On 2009-08-02, Carsten Dominik <carsten.dominik@gmail.com> wrote:
> If you mark some headlines (for example you remember targets)
> with a tag like "r", you could make yourself a restricted
> refile command like this:
>
> (defun my-org-restricted-refile ()
>    (interactive)
>    (let ((org-refile-targets '((org-agenda-files :tag . "r"))))
>      (call-interactively 'org-refile)))
>
> Not what you proposed, but maybe useful.

I like it.

It gives me an idea for remember.  For consistency, we can
optionally make remember use restricted refile as you
propose above.

The way it would work is this.  A template can optionally
specify only format, not target location.  When that is the
case, c-c c-c in the remember buffer asks you where you want
to file using restricted refile.

I would definitely use this, because I want to have the time
between idea and text as short as possible.  Deciding the
target location does not need to happen before the text.

This would allow reduction of remember templates to just the
ones that have different formats.

It would allow you to remember to different locations from a
given template, and different templates to a given location,
without increasing the number of templates or going to a
full refile interface.

In my case, a full refile interface is /very/ slow when it gathers
candidates.  But a restricted refile is much faster and reduces human
error.

Re: refile ideas

[Eric S Fraga]

At Mon, 3 Aug 2009 15:31:55 -0700,
Samuel Wales wrote:
> It gives me an idea for remember.  For consistency, we can
> optionally make remember use restricted refile as you
> propose above.
> 
> The way it would work is this.  A template can optionally
> specify only format, not target location.  When that is the
> case, c-c c-c in the remember buffer asks you where you want
> to file using restricted refile.

+1

Re: refile ideas

[Carsten Dominik]

On Aug 4, 2009, at 2:44 PM, Eric S Fraga wrote:

> At Mon, 3 Aug 2009 15:31:55 -0700,
> Samuel Wales wrote:
>> It gives me an idea for remember.  For consistency, we can
>> optionally make remember use restricted refile as you
>> propose above.
>>
>> The way it would work is this.  A template can optionally
>> specify only format, not target location.  When that is the
>> case, c-c c-c in the remember buffer asks you where you want
>> to file using restricted refile.
>
> +1

We could do this, but I think Bernt Hansen's setup is much better.
Use remember to put new items to a single location, and go back
to them later and refile.  The key to remember is to make it as simple
and as fast as possible.

- Carsten

Interactively add refile targets - was: refile ideas

[Sebastian Rose]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

Samuel Wales <samologist@gmail.com> writes:
> Hi Carsten,
>
> On 2009-08-02, Carsten Dominik <carsten.dominik@gmail.com> wrote:
>> If you mark some headlines (for example you remember targets)
>> with a tag like "r", you could make yourself a restricted
>> refile command like this:
>>
>> (defun my-org-restricted-refile ()
>>    (interactive)
>>    (let ((org-refile-targets '((org-agenda-files :tag . "r"))))
>>      (call-interactively 'org-refile)))
>>
>> Not what you proposed, but maybe useful.


Sorry, for not following the original thread closely. But the above
function does something, I missed when refiling, too. A way to add
refile targets on the fly.

The refile mechanism depends on agenda files and files below
`org-directory' or a somewhat static setup, which is insufficient for
most of my use cases. I often take notes for just any of my project
using a limited set templates (limited, because I don't want to choose
out of many templates for better overview and less thinking while
storing via remember).

But when it comes to refiling, I need to spread all those notes to
several directories, scattered all over the place. I therefor have
`org-refile-targets' set to:

((org-agenda-files :maxlevel . 3)
 (sr-org-refile-targets :maxlevel . 2))


In addition, I use the (far from perfect) functions below. They make it
possible, to add any directory to my refile targets on-the-fly, which is
what I prefer. `sr-add-to-org-refile-targets' adds all *.org files in a
directory to my targets, with a prefix arg (`C-u ....') recursively.

Since a big number of refile targets slows down refiling a lot (the only
area I ever felt a slow down in Org-mode so far), a function to remove
refile targets again (recursively, too) is still missing. Also, a
function to add or remove single files is missing.





[-- Attachment #2: Type: application/emacs-lisp, Size: 2078 bytes --]

[-- Attachment #3: Type: text/plain, Size: 719 bytes --]






A good better alternative would be, to allow for refiling to
arbitrary Org-files.

1. `M-x org-refile-to'
2. Minibuffer prompt:   Find file: ~/
3. Navigate to an *.org file (restrict TAB completion to *.org)
4. RET
5. Org-mode scanns the file and offers the targets as usual.
6. Add the file to the list of refile targets.

Which would mean to add just one simple function to Org-mode.

I'd prefer this simple interface over the directory aproach. In emacs,
the directory aproach is not needed, since we have the history (UP) for
quickly find a second file in the same directory.


Please choose the interface you like most, say `yes, we want it', and
I'll sit down and hack together a proposal.





   Sebastian

[-- Attachment #4: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode