Zsh autocompletion
Documentation
official docs http://zsh.sourceforge.net/Doc/Release/Completion-System.html
Tutorials
completion funcs https://github.com/zsh-users/zsh-completions/blob/master/zsh-completions-howto.org intro to autocomp https://askql.wordpress.com/2011/01/11/zsh-writing-own-completion/ intermediate autocomp http://www.linux-mag.com/id/1106/
Locations
/usr/share/zsh/functions/Completion/*/*
completion scripts (see $fpath
)
Loading Completions
fpath=(~/.zsh/completion $fpath) # add completion dir to $fpath autoload -U compinit # init autocompletion compinitThe cleanest way to reload your autocompletion script is:
- open a new terminal
autoload -U ~/.zsh/completion/_yourcompleter:t
Syntax
Basics
Now that we have created
~/.zsh/completion
, and have added it to$fpath
, you can start creating autocompletion files. First, some things to know:
- zsh autocompletion scripts are written in SHELL.
_arguments
is a function written in shellscript, and each argument you add to it is an argument against the shell script. That should give you some hints about the expected syntax, and how it is expanded.- zsh autocompletions do not need to be paired with any actual function. It compares the word typed on the shell against the list.
- zsh autocompletion scripts are sourced once, when the shell is first entered. You can reload them using a custom function (see above)
I highly recommend reading Completion/Unix/_zpool. It is fairly short, and very understandable.
Filesystem and Setup
Each program has it's own autocompletion script. It is named after the program with a prefix of '_'. The first line in the program should be '#compdef <programName>'
touch ~/.zsh/completion/_hello #### ~/.zsh/completion/_hello #compdef hello ... ####Special Filetypes
Standard executables are recognized on for autocompletion ('git' uses '_git'). This gets complicated with aliases and scripts with extensions (ex: script.py). You can manually tell compinit to be used for certain files with the compinit command.
compdef _wsearch wsearch.py #### _wsearch #compdef wsearch wsearch.py -p *.py ## the '-p' flag to compinit makes it a regex matchActions
_normal --> A normal argument. Expects a word (this seems to be the default) _files --> Complete filepaths _net_interfaces --> Net Interfaces _users --> users _groups --> groups _parameters --> expect a word argument to follow (can be file, word... pretty much anything. Can be restricted.)_arguments
_arguments
expects a bash array of arguments. Each argument is a string following the format laid out below."(exclude )--opt [description ]:message:action" (exclude) --> If any flag named within exclude has been used, don't autocomplete with this option. --opt --> The commandline flag (you may have arguments without flags) [description] --> The Description displayed next to the flag on autocompletion message --> Displayed Text? Unsure what this does... action --> One of ZSH's custom autocompletion actions like _files (which autocompletes to filepaths)Argument Examples
'-o[output file]' # `foo -o` {-h,--help}'[show help]' # `foo -h` OR `foo --help` '1:foo:_normal' # positional arg $1 completes to anything (usually defaults to files) '2:foo:_directories' # positional arg $2 completes to directories '*:foo:(one two three)' # completes 1x optional un-named param (rest arg) to 'one', 'two' or 'three' '*::foo:(one two three)' # completes unlimited optional un-named params (rest args) to 'one', 'two' or 'tree'
More Clear Way of Defining Args#compdef wsearch wsearch.py local arguments arguments=( {-b,-m}'[Few words of description.]' {-B,--always-make}'[Short and long variant.]' {-C,--directory}'[This description is on the next line.]' ) _arguments -s $argumentsecho {-b,-m}'[abd def hij]' >> -b[abd def hij] -m[abd def hij] echo {-b,\ -m}'[abd def hij]'Flag Based Arguments
Each Flag based argument is made of a single SHELL argument. Just like shell you can break up the arguments onto separate lines, by using the '\' character.
Each argument consists of 3 parts:
( 'right' 'center' )
Do not autocomplete current entry if one of these flags has been used.-left
The name of your argument[ this is my description ]
Description that appears when flag is suggested
#compdef hello _arguments \ "1::filename:_files" \ ## Positional and Flag based arguments can be mixed "('--right' '--center')--left [ align text to the left ]"\ "( )--stuff [ do something else neat ]"Positional Arguments
Positional arguments seem to replace keyword arguments in use.
1
The argument position:heroes:
A label for the arguments('batman' 'cat woman' 'robin')
Every option that is allowed to be presented on autocompletion_arguments \ "1:heroes:('batman' 'bat girl' 'robin')"\ ## First Argument Autocompletions "2:villains:('joker' 'bane')"\ ## Second Argument Autocompletions "*:ambiguous:('catwoman' 'lex luthor')" ## Every Remaining Argument will be one of these
Optional Arguments
Optional Arguments are marked by a double
::
. Optional arguments are anchored to positional arguments. In the following case, after 'interface', you have the option to add a file before the second positional argument 'blah'._arguments \ "1:interface:_net_interfaces" \ "::optional:_files" \ "2:blah[testing second var]" ### So for instance if you were completing an argparse list: _arguments \ "1:first:_parameters" \ ## This will allow you to complete as many parameters as you'd like "::next:_parameters" \ ## and as soon as you enter a '-' it will start completing the next flags. "-s[search]" \ "-m[match]"Subparsers
Sometimes, the use of a particular flag opens up a chain of possible sub-commands. (ex: git add, git commit, ...). This can be handled in ZSH as follows:
#compdef wtest _wtest() { local context state line expl implementation local -a subcmds ## list of arguments with their own parser-options subcmds=( archive display data ) ## Determine completer for subcommand ## (based on 1st positional argument) _arguments -C \ {-h,--help}'[show help information]' \ '1:subcommand:compadd -a subcmds' \ '*:: :->subcmd' && return service="$words[1]" curcontext="${curcontext%:*}-$service:" ## completers for each subcommand of ## 1st argument. case $service in (archive) _arguments -A "-*" \ '-a[append files to archive]' \ '-e[extract files to archive]' ;; (display) _arguments -A "-*" \ '-n[next file in archive]' \ '-p[previous file in archive]' ;; (data) _arguments -A "-*" \ '-s[shuffle order of wallpapers]' ;; (*) _message "unknown sub-command: $service" ;; esac } _wtest "$@"
Dynamic Arguments
Generate autocomplete options based on the options that were entered previously. This can do just about anything you need it to, it's really cool. This isn't my example, and I haven't yet needed this level of flexibility yet. This example is just so clear, I had to add it.
Some Background Info:
$words[]
is an array of all arguments used so far$state
is set in_arguments
. In the below example. If completion is used for '1', the value of $state will be 'country'#compdef hello _hello() { local curcontext="$curcontext" state line ## These two lines are required, typeset -A opt_args ## they initialize some internal variables ## for your function _arguments \ ## Initial Arguments '1: :->country'\ '*: :->city' case $state in ## Expand Arguments based on their category country) _arguments '1:Countries:(France Germany Italy)' ;; *) case $words[2] in France) compadd "$@" Paris Lyon Marseille ;; Germany) compadd "$@" Berlin Munich Dresden ;; Italy) compadd "$@" Rome Napoli Palermo ;; *) _files esac esac } _hello "$@" ## Passes _hello() function all arguments that was passed to the script.