Many have found the default completion order very awkward. If I could choose, ideally, the order would better to be determined by an editing distance score.
One bad example, when write command completion, is:
$ gpg -_
COMPLETING argument
--card-edit Edit Smartcard --import Import key -a Armor -d Decrypt -r Encrypt for recipient
--card-status Show Smartcard -K List secret keys -b Detached signature -e Encrypt -s Sign
--homedir Set homedir -R Hidden recipient -c Symmetric encrypt -k List public keys
It is more reasonable to be able to have short options come before longer, full options. Right now a workaround need to be only provide long options when the input already has --
Matching filename is also awkward.
If set to use subseq to make matching longer files easier,
set edit:completion:matcher[argument] = {|seed| edit:match-subseq $seed &ignore-case=$true }
When I want to match dirfstat.c, it is easy to get unexpected files sorted to be first candidates.
$ cat di_
COMPLETING argument
_p9dialparse.c _p9dir.c dial.c dirfstat.c dirfwstat.c dirmodefmt.c dirstat.c dirwstat.c nulldir.c
But if set to use edit:match-prefix, say if I want testprint.c, it is sorted at the last one, and would have require type 5 input characters to match it.
$ ls test_
COMPLETING argument
test.c testfltfmt.c testfmt.c testfork.c testprint.c
To strike a better balance between matching long filenames and shorter filenames, this is what I use:
set edit:completion:matcher[argument] = {|seed|
if (> (count $seed) 3) {
edit:match-subseq $seed &ignore-case=$false
} else {
edit:match-prefix $seed &ignore-case=$false
}
}
Actually, to make it work more consistent when the path contains parent directories like /usr/local/texlive, the if condition would be (> (count (basename -- $seed)) 3). After the setup the file completion would be at least as usable as bash.