From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id SK8fB9l3ql5wNQAA0tVLHw (envelope-from ) for ; Thu, 30 Apr 2020 07:01:45 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id SP35H+F3ql7kSQAAB5/wlQ (envelope-from ) for ; Thu, 30 Apr 2020 07:01:53 +0000 Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:470:142::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AFFA2942314 for ; Thu, 30 Apr 2020 07:01:52 +0000 (UTC) Received: from localhost ([::1]:57528 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jU3Ci-0000TJ-6c for larch@yhetil.org; Thu, 30 Apr 2020 03:01:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60404) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jU3AP-0006s9-Tt for emacs-orgmode@gnu.org; Thu, 30 Apr 2020 02:59:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jU3AO-0004td-FD for emacs-orgmode@gnu.org; Thu, 30 Apr 2020 02:59:29 -0400 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:39588) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jU3AN-0004Zy-Vt for emacs-orgmode@gnu.org; Thu, 30 Apr 2020 02:59:28 -0400 Received: by mail-wm1-x344.google.com with SMTP id y24so588424wma.4 for ; Wed, 29 Apr 2020 23:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=jMhG1SNS9+LRJ6P6OlS3WC2XrJ3B59InB5SAUD0FJ20=; b=os8/gWoyEECGWmDkjMh+EINh4NtzzqPWJNQgSC7BwvRKjKwST3Pk/3UwRTSIOn+XrD DaV8Yokyo62h0QiEwsw931MHGYqQGBR2Uy0SFiovuL0JTcuHzm/hB8AXS1DkD9IC09gc qTMR7yd+FvqhZp6t7muY0DUcyivkbiHL0WXu99E5xtCSZ4jcOi9S/yAgt5EneVwzo1hI Dj40iyBOIaG5FxKAh8THIvYgXmBYC1LZheaz8hOxBKBHeleXMw0nHtvbeCIdgkJo6Vww rqwgy92Xl6OhUE4jnE54qsCKZzSSB9P6S49jtfDGPEg2EWobB7XiAfXO71xF3nXumFZt K0fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=jMhG1SNS9+LRJ6P6OlS3WC2XrJ3B59InB5SAUD0FJ20=; b=J7FPBePqgJDU+cMhZ6djdbY2ALHOf3J81RbPe1KZTIYhxOXXRjwZk0j9WT/570/80z rS81/662Zo6ANxcRQ8UQlvv5GKunU6vLOkWsXLrQv2iun9RnM+F5+rNO7HGddZ0EtUlZ a5Pedv+FG4NG/BdgWjr3/r5hFtnqOe4VIIJNCLh5JzJCBh3srY2OQMYposcuANMToTci asGGvLr66MyV2pbG3gRZ9JQyKBomyC+LIdeJrpbkrri+VR0o7wWfg7ZE4/FTV0f+QK2+ zBrO24u1mT4FB9fBfkLqSi2/qTPXQ1pjRNe7yR8VIz/gkBSVjauKVI/Wr8v6QKZaDFus J0/A== X-Gm-Message-State: AGi0PuYogL8ra3PmNml2WHN+TfisnH92HB4DUmj7veVTcXFduOTKvCn8 fOQT2ob7rM6l0FbRpNibMf0= X-Google-Smtp-Source: APiQypIma4yhfHVJM3n3B9qfco7aSHBdHQO833a2gHxAdR9WimjtiYw0iNSY6mUkNeo63UK7yi5hAg== X-Received: by 2002:a05:600c:21d6:: with SMTP id x22mr1326472wmj.95.1588229965580; Wed, 29 Apr 2020 23:59:25 -0700 (PDT) Received: from localhost (tor-exit-15.zbau.f3netze.de. [185.220.100.242]) by smtp.googlemail.com with ESMTPSA id t20sm10549477wmi.2.2020.04.29.23.59.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Apr 2020 23:59:24 -0700 (PDT) From: akater To: Kyle Meyer , emacs-orgmode@gnu.org Subject: Re: [PATCH] org-agenda.el: Complete multiple todo keywords In-Reply-To: <87tv11liug.fsf@kyleam.com> References: <871ro6z28e.fsf@gmail.com> <87tv11liug.fsf@kyleam.com> Date: Thu, 30 Apr 2020 06:50:31 +0000 Message-ID: <87lfmdxya0.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::344; envelope-from=nuclearspace@gmail.com; helo=mail-wm1-x344.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::344 X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 X-Spam-Score: 3.29 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=os8/gWoy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 2001:470:142::17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Scan-Result: default: False [3.29 / 13.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; GENERIC_REPUTATION(0.00)[-0.49407981635399]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+ip6:2001:470:142::/48:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; IP_REPUTATION_HAM(0.00)[asn: 22989(0.17), country: US(-0.00), ip: 2001:470:142::17(-0.49)]; DWL_DNSWL_FAIL(0.00)[gmail.com:server fail,2001:470:142::17:server fail]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[gmail.com,none]; MX_GOOD(-0.50)[cached: eggs.gnu.org]; MAILLIST(-0.20)[mailman]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; RCVD_IN_DNSWL_FAIL(0.00)[2001:470:142::17:server fail]; MIME_TRACE(0.00)[0:+,1:+,2:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:22989, ipnet:2001:470:142::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[larch=yhetil.org]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_XBL(3.00)[185.220.100.242:received]; R_DKIM_ALLOW(0.00)[gmail.com:s=20161025]; FROM_NEQ_ENVFROM(0.00)[nuclearspace@gmail.com,emacs-orgmode-bounces@gnu.org]; FROM_HAS_DN(0.00)[]; RECEIVED_SPAMHAUS_CSS(1.00)[185.220.100.242:received]; URIBL_BLOCKED(0.00)[kyleam.com:email]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-diff]; PREVIOUSLY_DELIVERED(0.00)[emacs-orgmode@gnu.org]; HAS_LIST_UNSUB(-0.01)[]; BAD_REP_POLICIES(0.10)[]; RCVD_COUNT_SEVEN(0.00)[7]; FORGED_SENDER_MAILLIST(0.00)[] X-TUID: rca4pe+PVhz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kyle Meyer writes: > Thanks for the patch. Looks like a nice improvement to me. > > akater writes: > >> * lisp/org-agenda.el (org-todo-list): Use completing-read-multiple >> instead of completing-read when selecting todo keywords to filter by >> in Agenda. > > This and the rest of the lines were unwrapped. Could you wrap them ~70 > characters? (The Org repo's .dir-locals.el sets fill-column to 70.) >> * lisp/org-agenda.el (org-todo-list): Fix a typo in the prompt. > > Thanks for spotting that typo. I think it'd be more common to append > this description to the entry above rather than adding another > org-todo-list entry. Done. New patch is attached. >> There is minor UX cost to Helm users: while candidates list used to >> appear immediately to Helm users, now Helm users have to hit TAB to >> see the list. > > Just the opinion of one Helm user, but needing to hit tab for crm-based > completion has never bothered me too much. But if it did, Helm allows > specifying that certain commands should go through the built-in > completion. > > Out of curiosity I tried with the latest ivy (9e0803c), and I also > needed to hit tab before seeing anything. > >> This inconsistency is not present in vanilla Emacs >> completion. > > I'm confused by this. When I try with no customization (Emacs 26.3), I > need to hit tab to see any of the candidates. Yes; my point is, in vanilla Emacs completing-read-multiple and completing-read behave similarly while in Helm, singleton completion does not require hitting TAB initially but multiple-candidates completion does. I remember initially thinking that I broke completion altogether when I first introduced crm here. My confusion didn't last long but still, I found this a little unpleasant and tried my best to make it go. > Looks like you stuck with "|" as the separator, which seems like a good > idea to me. > >> However, it is unfortunate that string patterns are strings themselves >> and are thus indistinguishable from strings; it would be better if crm >> exposed separator (the string) on its own in its interface. > > I'm not quite sure I follow what you're suggesting with the last bit. > Could you rephrase the point in a way that is a bit more connected with > the code change? This patch sticks with the same separator, so aside > from being able to complete multiple things, there's no change in > behavior/added restriction here, right? Well, this likely shouldn't be in the patch either. I removed it and it's fine to forget about it. The rest of the message elaborates on this. What type is crm-separator of? According to crm.el, its default value is that of the constant crm-default-separator which is regex, i.e. a string pattern. That means crm-separator is a string pattern. It is employed as a string pattern in (the function) completing-read-multiple to clean some string from unneeded whitespace. And yet, using string pattern modelled on the default one in my patch would break things for Helm users (besides the fact that using it would simply make the code unnecessary cluttered). If you substitute said direct equivalent, activate Helm, eval (let ((crm-separator "[ \t]*\|[ \t]*")) (completing-read-multiple "kwds: " (mapcar #'list '("TODO" "DONE")) nil nil)) , press TAB C-SPC C-SPC RET | TAB C-SPC C-SPC RET, you'll get corrupted result: TODO,DONE|TODO|DONE. This is due to the fact that to make Helm support non-standard crm-separator, Helm developer had to resort to a fairly ugly hack trying to distinguish between a string pattern and an actual separator, otherwise results like TODO,DONE|TODO|DONE would appear in minibuffer. The gist of the problem is, Helm needs a separator to insert into buffer, and it now tries do detect whether crm-separator is regex or not, only uses it as insertion material in the latter case and reverts to the default comma otherwise. Detection is based on string length: https://github.com/emacs-helm/helm/commit/52e1d74f9ec6647c039012626f96596f0= eb4140a which is of course very unreliable. This might be considered a low-quality decision in Helm but I'd say it is natural for a user - of multiple-candidates completion interface (such as Helm) - that has to transform collections of candidates into strings on its own (this would be true for any Emacs application, I guess) to need both the separator to search for and the separator to intersperse a string with. Some collection types, like this collection type =E2=80=9Ca collection of O= rg todo keywords=E2=80=9D, come bundled with specific separator-the-string. I= t is this string that I'm using in mapconcat here. This string is a natural part of the interface of many collections of candidates, due to string-orientedness of everything that Emacs has to deal with, but this separator-the-string is now inaccessible to users of crm because crm de facto only exposes regex separator as part of its interface. These two separators are different objects of different types: one of them is a pattern, another is a string, and the former cannot be reliably used in the role of the latter. Maybe the former (regex, or several such) can always be computed from the latter (the string), and if true, crm.el could provide just separator-the-string for the interface; relevant regexes may be constructed from it when needed. But I did not study all the use cases of crm-separator the regexp so this is merely a guess. --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=org-agenda-complete-multiple-todos.patch Content-Description: Complete multiple todo keywords in org-agenda org-agenda.el: Complete multiple todo keywords * lisp/org-agenda.el (org-todo-list): Use completing-read-multiple instead of completing-read when selecting todo keywords to filter by in Agenda. Fix a typo in the prompt. --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -4790,8 +4790,12 @@ (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 + (let ((crm-separator "|")) + (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) --=-=-=--