unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Peter Wang <novalazy@gmail.com>,
	Lukasz Stelmach <l.stelmach@samsung.com>
Cc: notmuch@notmuchmail.org
Subject: Re: [PATCH] completion: remove "setup" from the list of possible completions
Date: Thu, 02 Jul 2020 15:55:24 -0400	[thread overview]
Message-ID: <87o8oxu1xv.fsf@fifthhorseman.net> (raw)
In-Reply-To: <20200624214401.GG10621@kurr.localdomain>


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

On Wed 2020-06-24 21:44:01 +1000, Peter Wang wrote:
> On Mon, 22 Jun 2020 12:22:50 +0200 Lukasz Stelmach <l.stelmach@samsung.com> wrote:
>> It was <2020-06-20 sob 12:53>, when Reto wrote:
>> > On Fri, Jun 19, 2020 at 12:40:49PM +0200, Łukasz Stelmach wrote:
>> >> Having "setup" in the set requires entering three instad of two characters
>> >> for "search". Since "setup" is rearly used it makes little sense to have
>> >> it in the set and cripple UX for much more frequently used "search".
>> >
>> > I very much disagree with this patch.
>> > The completions should contain all possible values, saving a single keystroke is
>> > certainly not a valid reason to remove a valid option from the completions.
>> >
>> > Write an alias into your bashrc if that bothers you so much... Then you can save
>> > much more keystrokes.
>> 
>> I already have several aliases covering most of my use cases, however, I
>> still use "notmuch search" from time to time and I came to a conclusion
>> expressed in this patch. Of course, as a random user, I can only suggest
>> and by no means insist on applying it.
>
> Another possibility may be to rename "notmuch setup" to "notmuch init",
> treating "setup" as a deprecated synonym for "init". The completions
> would include "init" but not "setup".

I sympathize with everyone struggling with the first-world problems in
this thread. :P

If i had to choose between the status quo and Lukasz's suggestion of not
completing "notmuch setup", i'd choose the status quo.

I value having all non-deprecated subcommands show up in tab completion.
This is particularly important for someone who is just starting to use
notmuch, and may use tab completion for discoverability.  If they can't
find the very first expected subcommand to be used in tab completion
exploration, that is pretty weird.

That said, i appreciate Peter's clever attempt to thread the needle.

Unfortunately, changing "setup" to "init" moves "notmuch insert" from
"notmuch i<TAB>" to "notmuch in<TAB>", so you're sort of robbing from
Peter to pay Paul.  And I'm having difficulty coming up with another
good subcommand name with an unambiguous prefix to move "setup" to.

I also note that we have no independent manpage for "notmuch-setup",
it's just symlinked from notmuch.1.gz.

Another "clever" approach to assuage the tab-completion-for-conveience
advocates would be to introduce a (non-deprecated) alias for "search"
that itself would be fewer keystrokes before tab completion (e.g. "srch"
is two keystrokes because "sr" is unambiguous, "query" is just one,
because "q" is unambiguous).

Overall, i value consistency and completeness and i would not like to
see the tab completion be either an inconsistent or incomplete
representation of the options available to the user from the command
line.

    --dkg

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

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

_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org

  reply	other threads:[~2020-07-02 20:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200619104051eucas1p1d5d63105518817bc80b55cfc9158ce2f@eucas1p1.samsung.com>
2020-06-19 10:40 ` [PATCH] completion: remove "setup" from the list of possible completions Łukasz Stelmach
2020-06-20 10:53   ` Reto
2020-06-20 14:04     ` Tomi Ollila
2020-06-20 19:09       ` Ralph Seichter
2020-06-23 21:04         ` Tomi Ollila
2020-06-23 22:46           ` Ralph Seichter
     [not found]     ` <CGME20200622102303eucas1p2121610b68b1d23705237632706cb06ab@eucas1p2.samsung.com>
2020-06-22 10:22       ` Lukasz Stelmach
2020-06-24 11:44         ` Peter Wang
2020-07-02 19:55           ` Daniel Kahn Gillmor [this message]
     [not found]             ` <CGME20200708151938eucas1p26c111da083d7e8248f6d59593ed40fa7@eucas1p2.samsung.com>
2020-07-08 15:19               ` Lukasz Stelmach
2021-06-05 11:42             ` David Bremner
2021-06-05 13:59             ` Felipe Contreras

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=87o8oxu1xv.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=l.stelmach@samsung.com \
    --cc=notmuch@notmuchmail.org \
    --cc=novalazy@gmail.com \
    /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).