Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <BWBCB7VTY8ZD.2GSGD0H9H00LN@rxps>
Date:   Fri, 16 Aug 2019 14:12:21 -0700
Subject: Fwd: Re: [PATCH BlueZ 1/3] client/main: add help option for
 available args
From:   "Ronan Pigott" <rpigott314@gmail.com>
To:     <linux-bluetooth@vger.kernel.org>
Message-Id: <BWBD3RE9KDV9.PK2ODM7IZII9@rxps>
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

On Fri Aug 16, 2019 at 2:29 PM Luiz Augusto von Dentz wrote:
> Can you a description of what the changes does, perhaps a sample when
> uses in some command.
>=20
> > +       if (!strcmp(argv[1], "help")) {
> > +               for (opt =3D arg_table; opt && *opt; opt++) {
> > +                       bt_shell_printf("%s\n", *opt);
> > +               }
> > +               bt_shell_noninteractive_quit(EXIT_SUCCESS);
> > +               return FALSE;
> > +       }

I added the help option to parse_argument so that when the argument
value is "help", the result is to print a newline separated list
of the arg_table containing the other valid arguments. Now
the user gets the following output for the following commands:

$ bluetoothctl agent help
on
off
DisplayOnly
DisplayYesNo
KeyboardDisplay
KeyboardOnly
NoInputNoOutput

$ bluetoothctl advertise help
on
off
peripheral
broadcast

Only agent_arguments[] and ad_arguments[] are defined in client/main.c,
so these are effecively the only new commands. The completion script
can parse the output of `bluetoothctl agent help` and `bluetoothctl
advertise help` to complete those arguments.

Additionally, other commands now don't complain that "help" is invalid,
but otherwise have no output at all. However, I don't think there is a
need to make "help" available in more contexts.

Instead for commands that take a device (similar for controller),
I chose to parse the output of `bluetoothctl devices` to take
advantage of zsh's verbosity in completion menus. Now when completing
such commands the user can get more information than is immediately
available in the interactive shell.

e.g. I am presented with a menu with descriptions like so:

$ bluetoothctl connect <TAB>
04:52:C7:0C:D4:A7  -- Bose QuietComfort 35
40:4E:36:D9:8F:28  -- Pixel 2
A4:38:CC:20:5D:E0  -- Pro Controller

This convenient menu was my original motivation for the zsh completions,
as it makes the connect/disconnect commands much more convenient to use.