FS#59965 - pacman zsh completion gives wrong completion for pacman -Qs

Attached to Project: Pacman
Opened by qwence (qwence) - Friday, 07 September 2018, 02:39 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 21 October 2018, 18:31 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Eli Schwartz (eschwartz)
Architecture All
Severity Low
Priority Normal
Reported Version 5.1.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Expected behavior: pacman -Qs chr<tab> (in zsh) completes packages
Actual behavior: this tries to complete files/directories
Other completions I tried (e.g. pacman -Qi) and the bash version of the above work as expected.
This is using pacman version 5.1.1-1.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Sunday, 21 October 2018, 18:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  The default bash and zsh experience are now consistent with https://git.archlinux.org/pacman.git/com mit/?id=ea877c596bc380acd608468e4e38186a c0252197
Comment by Eli Schwartz (eschwartz) - Friday, 07 September 2018, 03:07 GMT
In fact, it doesn't complete anything at all -- I suspect zsh itself is doing fallback filepath completion for you.

On the one hand, it makes sense to not offer completions for what is in fact meant to be a regular expression search of both the package name and package description.

On the other hand, our current bash completion *does* offer package name completions here...
Comment by Dave Reisner (falconindy) - Friday, 07 September 2018, 12:22 GMT
I wouldn't expect search functionality to provide autocompletion of any kind for non-option arguments. The input is arbitrary. If you're using completion to get results, aren't you using the wrong operation?
Comment by Eli Schwartz (eschwartz) - Friday, 07 September 2018, 16:00 GMT
Duly disabled for makepkg as well. Now bash and zsh are consistent.

https://lists.archlinux.org/pipermail/pacman-dev/2018-September/022808.html

Loading...