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.




Reply via email to