emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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



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