From mboxrd@z Thu Jan 1 00:00:00 1970 From: akater Subject: A possible improvement to org todo keywords completion UI Date: Thu, 27 Feb 2020 17:38:42 +0000 Message-ID: <87v9nsorq5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:54175) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7NFB-0007um-D7 for emacs-orgmode@gnu.org; Thu, 27 Feb 2020 12:46:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7NFA-0007WR-3T for emacs-orgmode@gnu.org; Thu, 27 Feb 2020 12:46:41 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:35318) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j7NF9-0007Vk-TB for emacs-orgmode@gnu.org; Thu, 27 Feb 2020 12:46:40 -0500 Received: by mail-ed1-x532.google.com with SMTP id c7so87426edu.2 for ; Thu, 27 Feb 2020 09:46:39 -0800 (PST) Received: from localhost (zrh-exit.privateinternetaccess.com. [195.206.105.217]) by smtp.googlemail.com with ESMTPSA id w24sm401971eds.22.2020.02.27.09.46.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Feb 2020 09:46:37 -0800 (PST) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org 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 altered Proposal so far: #+begin_src diff --- /sudo:portage@localhost:/var/tmp/portage/app-editors/emacs-28.0.9999/wo= rk/emacs/lisp/org/org-agenda.el +++ #> @@ -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) #+end_src 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 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 =E2=89=A524.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.