Clarification on multi-word keywords about denote

[protesilaos]

The summary looks good!

Thank you! Closing now.

[protesilaos]

That means if that some needs a "multiple word keyword", they will
need to write multiple_word_keyword when entering it through
M-x denote interactively. Is that right?

Yes, this is the idea. What I have not done yet, is to forcibly
interpret spaces as underscores. The reason I have not finalised that
part is because I still have doubts if the underscore is the most
appropriate character. I think it is. Any opinion on that?

To put it a different way, spaces are not allowed in keywords. If
that's the case, then printing out those keywords in any front-matter
format (Org, YAML) will be easier to manage.

Indeed!

[kaushalmodi]

Any opinion on that?

I like to interpret underscores as hyphens, but that's just my opinion. I dislike spaces in things like file names, keywords, etc 😄

[protesilaos]

I am re-opening this, as I think there is scope for change here.

I will make some experiments, but I think we should:

1. Prevent multi-word keywords. They look bad in file names and are generally awkward to use.

2. Configure the crm-separator at the KEYWORDS prompt to treat a space, a comma, and a plus sign as a separator. That way we do not get into counter-intuitive situations. Users shouldn't have to read the manual for such a point and get unwanted results that way.

3. The underscore is a valuable character that we can use in filenames. In a private exchange, someone explained how _tag makes for an easy way to target specific entries directly. I like that approach and will introduce a breaking change so that file names are written thus: DATE--TITLE__KEYWORDS.EXTENSION. For multiple KEYWORDS, it will look like __tag1_tag2_tag3 so all start with an underscore.

4. I ultimately do not like the plus sign in file names. It draws too much attention to itself. Also, + is a common regexp character which adds a little bit of inconvenience.

What do you think?

[kaushalmodi]

Prevent multi-word keywords. They look bad in file names and are generally awkward to use.

.. except that if someone really wants a multi-word keyword, hyphen can be used to separate the keyword parts, but never a space. I agree with the rest of the points below, so _ also cannot be used to separate keyword parts.

Configure the crm-separator at the KEYWORDS prompt to treat a space, a comma, and a plus sign as a separator. That way we do not get into counter-intuitive situations. Users shouldn't have to read the manual for such a point and get unwanted results that way.

Should _ also be added to this? If a user enters "abc_def" at the prompt for entering keywords, they will be read in as 2 keywords.

How about doing this "magic" at the keyword entry prompt? If a user types " " (space), ,, + or _ inside that prompt it auto-converts that types character to a consistent keyword separation character.. may be the ,?

The underscore is a valuable character that we can use in filenames. In a private exchange, someone explained how _tag makes for an easy way to target specific entries directly. I like that approach and will introduce a breaking change so that file names are written thus: DATE--TITLE__KEYWORDS.EXTENSION. For multiple KEYWORDS, it will look like __tag1_tag2_tag3 so all start with an underscore.

💯

I ultimately do not like the plus sign in file names. It draws too much attention to itself. Also, + is a common regexp character which adds a little bit of inconvenience.

💯 * 💯

---

Summary: Looks like you and the other user who provided that feedback collectively read my mind.

[protesilaos]

Seems like you have read my mind! [...] Summary: Looks like you and the other user who provided that feedback collectively read my mind.

Haha! That sounds right. I think many of us are on the same wavelength and figure out what the best design is.

.. except that if someone really wants a multi-word keyword, hyphen can be used to separate the keyword parts, but never a space. I agree with the rest of the points below, so _ also cannot be used to separate keyword parts.

I pushed the changes earlier. Multi-word keywords are separated by a hyphen. Any other character, such as spaces, underscores, the plus sign, is replaced with a hyphen.

Configure the crm-separator at the KEYWORDS

I opted against this. denote can be used from Lisp (e.g. you can have a wrapper function which let binds the denote-file-type) so we want to handle things internally.

To input more than one keyword at the relevant prompt, use the standard crm-separator which should be the comma.

---

To recap on what the state of affairs is.

1. The file name is DATE--TITLE__KEYWORDS.EXTENSION.
2. Distinct keywords in KEYWORDS are separated by an underscore: tag1_tag2.
3. Multi-word keywords are written with hyphens as in tag-one.
4. So tag-one_tag-two is two keywords.
5. The new design lets us search for _tag explicitly.
6. The __ delimiter makes it easier to visually identify where the TITLE field ends and the KEYWORDS begins.

In the manual, I also include this (maybe I should elaborate a bit more):

** Sluggified title and keywords
:PROPERTIES:
:CUSTOM_ID: h:ae8b19a1-7f67-4258-96b3-370a72c43f4e
:END:

Denote has to be highly opinionated about which characters can be used
in file names and the file's front matter in order to enforce its
file-naming scheme.  The private variable ~denote--punctuation-regexp~
holds the relevant value.  In simple terms:

+ What we count as "illegal characters" are converted into hyphens.

+ Input for a file title is hyphenated and downcased.  The original
  value is preserved only in the note's contents ([[#h:13218826-56a5-482a-9b91-5b6de4f14261][Front matter]]).

+ Keywords should not have spaces or other delimiters.  If they do, they
  are converted into hyphens.  Keywords are always downcased.

[kaushalmodi]

Any other character, such as spaces, underscores, the plus sign, is replaced with a hyphen.

👍

To recap on what the state of affairs is. ..

The summary looks good!