Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

[Carl Worth]

On Wed, Apr 29 2020, Jameson Graef Rollins wrote:
> I dare say there are few people that have muscle memory for the notmuch
> command line (especially for notmuch show), and fewer that aren't
> themselves developers...

Here, the concern isn't just "muscle memory" (forcing users to learn how
to retype commands at the command line) but also that users can have
developed scripts that call notmuch, and we would need to have an
extremely significant reason to break those.

And the notmuch CLI, from the beginning, was intentionally designed to
be comfortable for users to use directly (by typing at an interactive
shell), and for users to also incorporate into various scripts.

And even if they _are_ developers, they don't deserve to have their
environments broken either.

That said, it is unfortunate that some confusion has crept into the API.

I have to admit that I do not understand what this sentence of the
documentation means:

	For the cases where it's not ambiguous (in particular excluding
	boolean options), a space can also be used.

What are the possible cases where it could be ambiguous?

I'm personally opposed to adding any new option like --strict that
changes how command-line options are parsed.

I'm also opposed to renaming any of our existing command-line options.

It seems clear we could at least fix the wording of the above
documentation to make it clear that a space separator cannot be used for
Boolean options.

The only further change that could possibly make sense (to improve
consistency) would be to back out support for using a space separator
for _any_ options. But that introduces all the opportunities to break
users' environments, so it's probably a non-starter as well.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20200505/b23cca17/attachment.sig>