emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: akater <nuclearspace@gmail.com>
To: emacs-orgmode@gnu.org
Subject: A possible improvement to org todo keywords completion UI
Date: Thu, 27 Feb 2020 17:38:42 +0000	[thread overview]
Message-ID: <87v9nsorq5.fsf@gmail.com> (raw)

I'd like to discuss a possible improvement to org todo keywords completion UI but

- it could break something as is

- it still needs some polish, or maybe some of org internals better be

Proposal so far:
#+begin_src diff
--- /sudo:portage@localhost:/var/tmp/portage/app-editors/emacs-28.0.9999/work/emacs/lisp/org/org-agenda.el
+++ #<buffer org-agenda.el<org>>
@@ -4774,8 +4774,11 @@
                                                 (nth (1- arg) kwds))))
       (when (equal arg '(4))
         (setq org-select-this-todo-keyword
-              (completing-read "Keyword (or KWD1|K2D2|...): "
-                               (mapcar #'list kwds) nil nil)))
+              (mapconcat #'identity
+                         (completing-read-multiple
+                          "Keyword (or KWD1|KWD2|...): "
+                          (mapcar #'list kwds) nil nil)
+                         "|")))
       (and (equal 0 arg) (setq org-select-this-todo-keyword nil))
       (org-compile-prefix-format 'todo)
       (org-set-sorting-strategy 'todo)

This makes it possible to mark multiple candidates with helm. In what
follows, `crm' means `complete-read-multiple'.

With org-todo-list implemented as it is now, helm user cannot select
multiple todo keywords with helm at all. User has to type keywords
explicitly, togehther with vertical bar separators.

The proposed change makes it possible to do the following C-c a T TAB
<mark one or more candidates with helm> RET and have KWD1,KWD2,...,KWDn
appear in minibuffer.

At this point, user can type another comma, hit TAB again and add more
keywords to the list. Hitting RET without adding anoter comma will
submit the keywords to org-adenga procedure, and the expected Agenda
buffer will be displayed.

There are see several issues however, relevant to inner workings of both
crm and orgmode.

The first three are likely either crm-related or helm-related; I leave
them here so that I can reference to the whole example, with its
context, from other discussions. Skipping them won't prevent you from
being able to reply meaningfully to this message.

- the neccessity to hit the initial TAB to trigger the completion is
somewhat unpleasant: new users likely won't recognise the completion
candidates are there at all. It would be more convenient and less
confusing if candidates appeared immediately.

- it would be natural for crm to allow for arbitrary separator, tailored
to particular callers; in this case it better be vertical bar rather
than comma.

- results entered so far could be safely appended with a trailing
comma. That would make it possible to trigger additional completions
with hitting just TAB each time. One does not need to remove the
trailing separator for the resulting list to be correct, or at least
this is true for org todo keywords. The downside is that the presence of
the trailing separator might confuse users, so that they'd think their
input was still incomplete but (1) I find this unlikely; (2) I guess the
trailing separator could be de-emhasized with a dimmed face (the
downside here, in turn, is that there is no such thing as dimmed face in
console). Trailing separator might also confuse users so that they'd
remove it each time before hitting RET. This is more likely, and I don't
know what to do with this.

orgmode-related questions and issues are:

- could orgmode internals be changed in such a way that this call to
completing-read-multiple could simply return a list and thus we wouldn't
have to rely on some unix-style string passing with explicit characters
as separators, doing it in a civilised manner instead?

- maybe my patch would break something as is?

- reliance on completing-read-multiple will make org-agenda require
Emacs ≥24.4 (or something similar; I'm as precise here as crm help page
is). I suspect it's not an issue but I want to make sure.

I'd like to hear feedback on orgmode-related points, and maybe hints on
where I should discuss the aforementioned crm interface issues: in helm
repository or in some emacs mailing list. Also, it is possible that
those can be mitigated with a patch for `org-agenda.el' that is more
competently made than mine, still providing the intended improvement.

                 reply	other threads:[~2020-02-27 17:46 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=87v9nsorq5.fsf@gmail.com \
    --to=nuclearspace@gmail.com \
    --cc=emacs-orgmode@gnu.org \


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