ZSH completion does not allow to specify multiple files to trash

[ohquero]

Describe the bug
Commands provided by this utility allow to specify multiple files to manipulate, but ZSH autocompletions suggest filenames only for one parameter.

trash-cli version
0.23.11.10

Are you using the latest version of trash-cli?
Yes

Have you tried if the bug is present in the latest version of trash-cli?
Yes

Operating system:
Arch Linux

To Reproduce

$ touch bar foo
$ trash-put bar f#Here ZSH autocompletion does not complete with "foo" file
$ trash-put bar foo #But the command works!
$ trash-list
2024-03-28 09:57:28 /home/quero/bar
2024-03-28 09:57:28 /home/quero/foo

Expected behavior
The completions should have completed the command the "foo" filename.

[DMaroo]

Patch

The following patch, when applied to the generated completions, fixes the issue.

23c23
<   "(*)::files:_trash_files"
---
>   "*:: :->file"
28c28
<   local context state line curcontext="$curcontext" one_or_more='(-)*' remainder='(*)'
---
>   local context state line curcontext="$curcontext"
30,33c30
<   if ((${_shtab_trash_put_options[(I)${(q)one_or_more}*]} + ${_shtab_trash_put_options[(I)${(q)remainder}*]} == 0)); then  # noqa: E501
<     _shtab_trash_put_options+=(': :_shtab_trash_put_commands' '*::: :->trash-put')
<   fi
<   _arguments -C -s $_shtab_trash_put_options
---
>   _arguments -C -s -S -A -* $_shtab_trash_put_options
42a40,45
>       ;;
>     file)
>       (( CURRENT > 0 )) && line[CURRENT]=()
>       line=( ${line//(#m)[\[\]()\\*?#<>~\^\|]/\\$MATCH} )
>       _files -F line && ret=0
>       ;;

Of course, this is a hacky fix and it should not be upstreamed. I believe that either there is something wrong in the way shtab is used to generate completions, or shtab has a bug (unlikely).

Behavior

When using -<TAB> without files as any previous arguments, all the flags get auto-completed.

$ trash -<TAB>
--force             -f                       -- silently ignore nonexistent files
--help                                       -- show this help message and exit
--interactive       -i                       -- prompt before every removal
--print-completion                           -- print shell completion script
--recursive         --directory  -R  -r  -d  -- ignored (for GNU rm compatibility)
--trash-dir                                  -- use TRASHDIR as trash folder
--verbose           -v                       -- explain what is being done
--version                                    -- show program's version number and exit

When using just <TAB> (with no - in front of it) with or without files as any previous arguments, the files get autocompleted. If you have a file as one of the previous arguments, and then you use -<TAB>, it will try autocompleting files and will not autocomplete flags.

This behavior is completely identical to rm behavior.

[protist]

@DMaroo just wondering why this shouldn't be upstreamed? Just curious as to whether users should patch this downstream.

[DrummyFloyd]

any update on this ?

[DMaroo]

@DMaroo just wondering why this shouldn't be upstreamed? Just curious as to whether users should patch this downstream.

Ideally, shtab should have generated that code, but it did not. Patching the auto-generated file is not the right way to go IMO.

[protist]

Thanks @DMaroo . I had a look in my system, and I can't find the file to patch. Could you please explain what we should be patching?

[dnswrsrx]

@protist it's one of the directories where ZSH stores completions. You may have to look it up for the OS you're running.

I run Arch, and the completions for trash are stored in /usr/share/zsh/site-functions. In there, the completion for the trash command is named _trash, so I'm applying said patch to this file. Again with my OS, my command to patch the file is patch _trash <patch file name>.

I had to update the patch for it to work on my system. Here's my gist in case it also helps you.

[protist]

Thanks @dnswrsrx. That works great on my system (also Arch). I'm considering opening a task on the Arch tracker to patch it there, since there hasn't been much movement here.