Zsh autocompletion: Difference between revisions

From wikinotes
No edit summary
Line 43: Line 43:
* <code>autoload -U ~/.zsh/completion/_yourcompleter:t</code>
* <code>autoload -U ~/.zsh/completion/_yourcompleter:t</code>
</blockquote><!-- Loading Completions -->
</blockquote><!-- Loading Completions -->
= Notes =
<blockquote>
{|
|-
| [[zsh autocompletion configuration]]
|-
| [[zsh autocompletion syntax]]
|-
|}
</blockquote><!-- Notes -->


= Syntax =
= Syntax =

Revision as of 19:49, 24 July 2021

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
compinit

The cleanest way to reload your autocompletion script is:

  • open a new terminal
  • autoload -U ~/.zsh/completion/_yourcompleter:t

Notes

zsh autocompletion configuration
zsh autocompletion syntax

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 match

Actions

_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`
'-u[choose user]:::_users'  # `foo -u $USER` (completes from os users)
'1:foo:_normal'             # positional arg $1 completes to anything (usually defaults to files)
'2:bar:_users'              # positional arg $2 completes to os users
'3:baz:->my-state-name      # (reqs `_arguments -C`) $state assigned val 'my-state-name' (use case to set completer)
'*: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 $arguments
echo {-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.