So, this is a case where our completion system could work better.
The best I could come up with so far was in the git completions (
https://github.com/fish-shell/fish-shell/blob/e84200b847901b97332c48546ff87e9570de4e6b/share/completions/git.fish#L97-L131
).
The idea is that you need to skip arguments for options that can accept
them, and the best I could do so far is to hard-code them. Now, ideally it
would be easy to get that information from `complete`, since that already
has it, but so far that's not available.
If your completion isn't as elaborate as the git one, then it's often
sufficient to do
```
set -l zfscommands get # and all the others
complete -c zfs -n "not __fish_seen_subcommand_from $zfscommands" -a "get"
complete -c zfs -n "__fish_seen_subcommand_from get" -a "all $properties"
complete -c zfs -n "__fish_seen_subcommand_from get; and
__fish_seen_subcommand_from all $properties" -a "$filesystems"
```
i.e. to use the second argument like a subcommand (which for this purpose
means a bare word without a "-").
Regarding unit tests, we've skipped doing those for completions since the
interesting ones all rely on the tool being available, and we can't have it
so the fish tests only succeed on a system that has all that stuff (which I
don't think is even possible since we have some completions for linux-only
tools and others for macOS-only ones).
What you could use here is `complete --do-complete`, which will just call
the completions and output whatever they give (note that the argument
handling there is highly fragile, i.e. `complete -C"something"` works,
`complete -C "something"` doesn't).
Hope that helps,
Fabian Homborg.
On Mon, May 8, 2017 at 5:28 PM Mike Meyer <m...@mired.org> wrote:
> I'm working on completions for zfs and zpool. These use the now-popular
> "subcommand" structure, but very few of the subcommands work on files.
> Most of them work on zfs datasets (haven't started on zpool yet), but some
> work on other things associated with them - properties, permissions, users
> and groups so far. While I can complete those, which I need to complete
> against depends on which argument I'm looking at. The one I've got
> partially working is "get", for getting property information:
>
> zfs get [-r|-d depth] [-Hp] [-o field[,...] [-t
> type[,...]] [-s
> source[,...] "all" | property[,...] filesystem|volume|snapshot ...
>
> The problem is that it completes against properties (and "all") for the
> first argument and against three flavors of dataset for the second. I can
> do both of those, but figuring when to apply them is problematical. My
> current code just counts arguments that don't start with a "-", but that
> means that "zfs -d 2 <TAB>" completes against datasets, not properties.
>
> So, can someone suggest an example of handling this kind of thing? The
> things I thought of all seem to be not quite right, or generated and not
> handling the different search spaces.
>
> Second issue. Completion handling for the subcommand style commands seems
> particularly fragile, in that a bug in the handling of one subcommand can
> break completion handling for other subcommands. Makes me really want
> automated tests for the ones I've finished. Any suggestions on how to
> automate testing completions?
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Fish-users mailing list
> Fish-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fish-users
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Fish-users mailing list
Fish-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fish-users
