From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: refile ideas Date: Tue, 7 Jul 2009 21:59:58 -0700 Message-ID: <20524da70907072159v3604e31ekf4209ea2643942e5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOPGb-0001zB-Ox for emacs-orgmode@gnu.org; Wed, 08 Jul 2009 01:00:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOPGW-0001v5-Um for emacs-orgmode@gnu.org; Wed, 08 Jul 2009 01:00:25 -0400 Received: from [199.232.76.173] (port=51927 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOPGW-0001ud-Ig for emacs-orgmode@gnu.org; Wed, 08 Jul 2009 01:00:20 -0400 Received: from mail-px0-f200.google.com ([209.85.216.200]:64585) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOPGW-0004Km-4B for emacs-orgmode@gnu.org; Wed, 08 Jul 2009 01:00:20 -0400 Received: by pxi38 with SMTP id 38so3724362pxi.14 for ; Tue, 07 Jul 2009 22:00:18 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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