I like how fd approaches case sensitive search. They refer to their approach as "smart case" and it works as follows:

• Searching by default is case insensitive
• If the search term contains at least one capital letter, search is case sensitive

This covers most use cases of case sensitive search and makes the CLI simpler, as S could be removed.

I just filed a bug but had to refer to "the current version". A flag "--version / -V" could be useful for this.

See #4. The short flag for "version" is now -v instead of -V.

dn -h still prints sensitiveSearch for the "usage" section:

usage: dn [-h] [-V] {add, search, sensitiveSearch, ...}

Flags suggest that multiple can be combined – which they can't.
Would it be reasonable to instead use a single "mode argument", e.g.:

$ dn t
2022-12-19
 * example
$ dn e

Of course, that would either require to add a mode argument for adding notes (which may be suboptimal), or to have two binaries with different names for adding notes vs. editing / viewing etc. Curious to hear your thoughts!

In the new version, using any flag leads to the error "Multiple flags used".

Reproduce:

$ dn -t
Mutiple flags used
[...]

In the old version, the same command worked.

The help used to list the short commands as well as the long ones, e.g.:

  add (a)		Adds note with today's date. Can be omitted if note is longer than three chars.

Now, it only lists the long ones:

  add         Adds note with today's date. Can be omitted if note is longer than three chars.

To get the short one, we have to run dn <cmd> -h, which is one additional step:

$ dn add -h
Adds note with today's date. Can be omitted if note is longer than three chars.

Usage:
  dn add [note] [flags]

Aliases:
  add, a

Examples:
dn add "This note will be added with today's date"

Flags:
  -h, --help   help for add

The original dn has one space indentation, the tool two. This leads to inconsistently indented files if both are used:

2022-12-21
  * a
 * a

Suggestion would be to follow the original script's style, but of course this is a niche case.

Since #6, the $EDITOR is used. In the help for e, this is acknowledged. The help text of et, though, still mentions vim.

Suggestion: Replace vim with $EDITOR

This may be intended, so feel free to close: Commands in the --help are now listed alphabetically, with some rather unimportant ones (e.g., config) before core ones (e.g., today).

This issue is something that really depends on your preference – feel free to discard.

Adding a note currently leads to two lines of output being printed. The note is echoed and a short blurb notes how the operation could be undone.

After the first time, this output is not useful anymore. I would therefore suggest a flag -v that activates verbosity. In that mode, the output is printed. Otherwise, not output is printed.

Alternatively, in my view, this output could also just be removed.

It's relatively easy to configure dn's base directory, as it reads DN_HOME (and the script can of course just be adapted).

Maybe it makes sense to either read DN_HOME as well or to allow configuring the base directory (potentially before building)?

I prefer to use other editors than vim, so it would be nice to be able to configure that.

Suggestion: Read $EDITOR environment variable (seems preferable).

Alternative: Allow custom configuration with (1) own environment variable (e.g., $DN_EDITOR) or config file (may be overblown, though).

I'm on version 1.6.0.

In the --help, a command completion is listed. Yet, it seems to be not recognized:

$ dn -h
Usage:
  dn [command]

Available Commands:
  add         Adds note with today's date. Can be omitted if note is longer than three chars.
  completion  Generate the autocompletion script for the specified shell
  config      Interact with dn's config.
# ...
$ dn completion
Added 'completion' to today's note
If this was not intended, run `dn et` to edit today's note

So either (1) the command is wrongly listed or (2) the argument parsing does not detect it correctly.