unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Carl Worth <cworth@cworth.org>
To: Jameson Graef Rollins <jrollins@caltech.edu>,
	David Bremner <david@tethera.net>,
	Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
	Jani Nikula <jani@nikula.org>
Cc: notmuch@notmuchmail.org
Subject: Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`
Date: Tue, 05 May 2020 11:28:07 -0700	[thread overview]
Message-ID: <87o8r2tex4.fsf@wondoo.home.cworth.org> (raw)
In-Reply-To: <87y2qemh27.fsf@caltech.edu>


[-- Attachment #1.1: Type: text/plain, Size: 1722 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  parent reply	other threads:[~2020-05-05 18:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-24 12:53 Inconsistencies in handling command flags: `--flag=value` different than `--flag value` Ciprian Dorin Craciun
2020-04-27 17:53 ` David Bremner
2020-04-27 18:02   ` Daniel Kahn Gillmor
2020-04-27 18:20     ` Tomi Ollila
2020-04-27 19:21       ` Ciprian Dorin Craciun
2020-04-29  2:16         ` Daniel Kahn Gillmor
2020-04-29 14:18           ` Tomi Ollila
2020-04-29 15:39             ` David Bremner
2020-04-29 15:45               ` Jameson Graef Rollins
2020-04-29 16:28                 ` David Bremner
2020-05-05 18:28                 ` Carl Worth [this message]
2020-05-07 19:26                   ` [PATCH] notmuch(1): clarify documentation about --option/value separators Daniel Kahn Gillmor
2020-05-07 23:40                     ` Carl Worth
2020-05-08 12:01                       ` David Bremner
2020-05-08 16:06                       ` Daniel Kahn Gillmor
2020-04-29 15:59               ` Inconsistencies in handling command flags: `--flag=value` different than `--flag value` Ciprian Dorin Craciun
2020-04-29 16:07                 ` Jameson Graef Rollins
2020-04-29 15:33           ` Jameson Graef Rollins
2020-04-30 16:59             ` Daniel Kahn Gillmor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8r2tex4.fsf@wondoo.home.cworth.org \
    --to=cworth@cworth.org \
    --cc=david@tethera.net \
    --cc=dkg@fifthhorseman.net \
    --cc=jani@nikula.org \
    --cc=jrollins@caltech.edu \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).