From: Caleb White <cdwhite3@pm.me>
To: Brandon Maier <brandon.maier@collins.com>,
Emil Velikov <emil.l.velikov@gmail.com>
Cc: tools@kernel.org
Subject: Re: [PATCH b4] b4: support optional shell completion
Date: Fri, 11 Oct 2024 18:48:35 +0000 [thread overview]
Message-ID: <D4T79H1PP9GS.3TMUX3X28SOZJ@pm.me> (raw)
In-Reply-To: <D4T4YGGNY30T.29QNDWMMTODP9@collins.com>
On Fri Oct 11, 2024 at 12:00 PM CDT, Brandon Maier wrote:
> Hi Emil, Caleb,
>
> On Fri Oct 11, 2024 at 4:39 PM UTC, Emil Velikov wrote:
>> On Thu, 10 Oct 2024 at 18:12, <cdwhite3@pm.me> wrote:
>> > I would recommend using a `completion` command instead of
>> > `--print-completion` to generate the completion scripts. E.g.,
>> >
>> > b4 completion bash
>> >
>> > This is a more common pattern and is used by many other tools.
>> >
>> > > +Shell completion is provided by the command ``b4 --print-completion
>> > > +{bash,zsh,tcsh}``. To enable shell completion run::
>> > > +
>> > > + eval $(b4 --print-completion bash)
>> > > +
>> > > +To make it permanent on new shells, add that command to your ``$HOME/.bashrc``
>> > > +or ``$HOME/.zshrc``.
>> >
>> > While this works, the more common pattern is to echo the output to a
>> > completion directory which is auto sourced, for example (bash):
>> >
>> > For global installation:
>> > b4 completion bash > /etc/bash_completion.d/b4
>> >
>> > For user installation:
>> > mkdir -p ~/.local/share/bash-completion/completions
>> > b4 completion bash > ~/.local/share/bash-completion/completions/b4
>> >
>
> I haven't seen any good reference docs for this design pattern. All the
> tools I've run across document this manually using either the `eval` or
> bash-completion methods. Same with arguments, `b4 --completion` or `b4
> completion`.
>
> The shtab project also doesn't have any opinions and supports both
> approaches for arguments.
> https://github.com/iterative/shtab
>
> I have no strong preferences either way, I can resubmit with these
> changes.
Some programs that follow the `<program> completion` pattern are:
pip, kubectl, helm, composer, npm, himalaya (Rust email client),
the GitHub `gh` CLI, etc. Ultimately, it's up to you and it and it's not
the biggest thing either way, but this is the first thing I look for
when I'm trying to figure out how to get completion for a new tool.
Usually, installation docs will show both the eval and the completion
directory methods. The completion directory method allows for lazy
loading of completions, which can speed up shell startup time, but
it could just depend on your shell.
Best,
next prev parent reply other threads:[~2024-10-11 18:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 17:12 [PATCH b4] b4: support optional shell completion cdwhite3
2024-10-11 16:39 ` Emil Velikov
2024-10-11 17:00 ` Brandon Maier
2024-10-11 18:48 ` Caleb White [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-10-09 19:38 Brandon Maier
2025-01-22 15:44 ` Konstantin Ryabitsev
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D4T79H1PP9GS.3TMUX3X28SOZJ@pm.me \
--to=cdwhite3@pm.me \
--cc=brandon.maier@collins.com \
--cc=emil.l.velikov@gmail.com \
--cc=tools@kernel.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.
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 NNTP newsgroup(s).