Bastien <b...@gnu.org> writes:
Hi,
No Wayman <iarchivedmywholel...@gmail.com> writes:
Instead of a defvar that we don't want the user to modify, why
not
hardcoding the addition of the coma? I'd prefer this.
`completing-read-multiple' is currently used in two spots to read
tags:
`org-set-tags-command' and `org-capture-fill-template'.
To be clear, you would rather I hard code the same regexp and
comment in those two locations rather than abstracting it into a
defconst?
Any place in the manual that refers to tag separators,
explicitly or
implicitly, I've not checked if there are some. Also in the
code
itself, as a comment, to explain why both "," and ":" should be
allowed
I don't see why we need to add anything to the manual.
We're not changing the syntax of tags.
We're utilizing the normal behavior of completing-read-multiple.
The manual states for `org-set-tags-command':
"By default Org mode uses the standard minibuffer completion
facilities for entering tags."
The comma is standard when reading multiple items.
That seems to cover it to me.
Another solution I proposed was indicating the delimiters in the
minibuffer prompt similar to what is currently done in
`org-todo-list'.
e.g.
org-todo-list prompt: "Keyword (or KWD1|KWD2|...): "
org-set-tags-command prompt: "Tags ("," or ":" to delimit): "
The only argument I heard against that was from one person who
thought it "wasted space".
I don't consider that a strong argument considering the length of
the prompt for `org-todo-list'.
(avoid the keyboard-based argument, which is too subjective.)
If one can customize their keyboard layout, I don't see why we
should be so rigid about a delimiter in a prompt.
It's a moot point, though, I've abandoned that proposal because it
was apparently too controversial.