From: Allen Li <darkfeline@felesatra.moe>
To: No Wayman <iarchivedmywholelife@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]
Date: Sun, 05 Sep 2021 17:48:13 -0700 [thread overview]
Message-ID: <80mtoqttpu.fsf@felesatra.moe> (raw)
In-Reply-To: <87ilzhjwkk.fsf@gmail.com> (No Wayman's message of "Fri, 03 Sep 2021 13:13:45 -0400")
No Wayman <iarchivedmywholelife@gmail.com> writes:
> Allen Li <darkfeline@felesatra.moe> writes:
>> The question here is, which behavior do we want? My philosphy
>> is that
>> programs shouldn't try to silently re-interpret the user's
>> intentions.
>> For example, if I accidentally mistyped the tag "green_blue" as
>> "green-blue", I don't want Org to "helpfully" split one tag into
>> two
>> tags "green:blue". I may not realize the data corruption until
>> too
>> late.
>
> Consider the current behavior of `org-capture-fill-template':
>
> If you were to mistype your tag as "green-blue" it would be
> captured as part of the headline string instead of a set of tags.
> Future tag completions would not include any reference to it, and
> so you likely wouldn't notice until long after the fact
> (especially in the case of a template with a non-nil
> :immediate-finish).
> So the risk of data corruption exists now by allowing the function
> to return an invalid tag string.
green-blue is recoverable, and green:blue is not. Consider a file where
some headings are tagged :green:blue: and some are tagged :green_blue:.
If green-blue gets changed into :green:blue:, then it is no longer
possible to tell which :green:blue: headings are supposed to be
:green_blue:. If they were left as green-blue, it is trivial to fix
them with a search-replace. It is also easy to notice that they were
typed incorrectly because the tags would be highlighted differently (as
they are invalid).
> It defaults to what you've proposed (allowing ":" and "," to
> delimit tags).
> It avoids introducing a new regexp variable which needs to be
> maintained in lockstep with `org-tag-re'.
> It's customizable.
> It informs the user about the tag delimiting characters in the
> prompt.
Yes, I think using only ":" and "," is the best default option. I still
don't think there is a need to make it customizable (I doubt anyone is
typing tags separated with ! or @ or #), but I suppose
there's minimal harm from doing so.
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index c51744680..e51d039d5 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1740,9 +1740,12 @@ The template may still contain \"%?\" for cursor positioning."
(org-add-colon-after-tag-completion t)
(ins (mapconcat
#'identity
- (let ((crm-separator "[ \t]*:[ \t]*"))
+ (let* ((separators (or org-tags-crm-separators '(?: ?,)))
+ (crm-separator (org-tags-crm-regexp separators)))
(completing-read-multiple
- (if prompt (concat prompt ": ") "Tags: ")
+ (if prompt (concat prompt ": ")
+ (format "Tags (%s to delimit): "
+ (mapconcat #'char-to-string separators " ")))
org-last-tags-completion-table nil nil nil
'org-tags-history))
":")))
I am -0.5 on showing the delimiters since this is not conventional for
completing-read-multiple, especially after we add support for "," like
most other uses of completing-read-multiple. It needlessly inflates the
length of the prompt.
I suggest adding a helper function for the:
(separators (or org-tags-crm-separators '(?: ?,)))
(crm-separator (org-tags-crm-regexp separators))
so you can call it like:
(crm-separator (org-tags--crm-separator-regexp))
since you repeat this verbatim below.
diff --git a/lisp/org.el b/lisp/org.el
index ce68f4692..4cd173c99 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2980,6 +2980,11 @@ is better to limit inheritance to certain tags using the variables
(const :tag "Reverse alphabetical" org-string-collate-greaterp)
(function :tag "Custom function" nil)))
+(defcustom org-tags-crm-separators '(?: ?,)
+ "List of tag delimiting characters used when reading multiple tags."
+ :type 'list
+ :group 'org-tags)
+
(defvar org-tags-history nil
"History of minibuffer reads for tags.")
(defvar org-last-tags-completion-table nil
You should make the :type a list of characters so the widget is more
user friendly.
@@ -12007,6 +12012,10 @@ tags."
;; it now points to BLANK-START. Use COLUMN instead.
(if in-blank? (org-move-to-column column) (goto-char origin))))))
+(defun org-tags-crm-regexp (chars)
+ "Return `crm-separator' regexp using CHARS as separators."
+ (format "[ \t]*%s[ \t]*" (regexp-opt (mapcar #'char-to-string chars))))
+
(defun org-set-tags-command (&optional arg)
"Set the tags for the current visible entry.
@@ -12065,11 +12074,13 @@ in Lisp code use `org-set-tags' instead."
inherited-tags
table
(and org-fast-tag-selection-include-todo org-todo-key-alist))
- (let ((org-add-colon-after-tag-completion (< 1 (length table)))
- (crm-separator "[ \t]*:[ \t]*"))
+ (let* ((org-add-colon-after-tag-completion (< 1 (length table)))
+ (separators (or org-tags-crm-separators '(?: ?,)))
+ (crm-separator (org-tags-crm-regexp separators)))
(mapconcat #'identity
(completing-read-multiple
- "Tags: "
+ (format "Tags (%s to delimit): "
+ (mapconcat #'char-to-string separators " "))
org-last-tags-completion-table
nil nil (org-make-tag-string current-tags)
'org-tags-history)
--
2.33.0
next prev parent reply other threads:[~2021-09-06 0:49 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-26 17:04 [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)] No Wayman
2021-08-31 10:17 ` Timothy
2021-09-03 2:05 ` No Wayman
2021-09-03 7:22 ` Timothy
2021-09-03 17:00 ` No Wayman
2021-09-03 6:51 ` Allen Li
2021-09-03 8:08 ` Timothy
2021-09-03 19:20 ` No Wayman
2021-09-17 17:09 ` No Wayman
2021-09-03 17:13 ` No Wayman
2021-09-03 19:42 ` No Wayman
2021-09-03 23:37 ` No Wayman
2021-09-27 8:35 ` Bastien
2021-09-27 15:19 ` No Wayman
2021-09-27 15:49 ` Bastien
2021-09-27 15:56 ` No Wayman
2021-09-06 0:48 ` Allen Li [this message]
2021-09-06 23:23 ` No Wayman
2021-09-12 3:37 ` Allen Li
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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=80mtoqttpu.fsf@felesatra.moe \
--to=darkfeline@felesatra.moe \
--cc=emacs-orgmode@gnu.org \
--cc=iarchivedmywholelife@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).