You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Completions not erasing with complete -c <command> -e #6716
I have been investigating a large slowdown in git completions in 3.1 on Windows (running under msys2), where completion times have ballooned out to between 3-10 seconds for some commands.
In doing so I have noticed that I seem unable to erase completion rules in a shell until they have actually been used. For example, in a fresh shell
$ sh -c 'env HOME=$(mktemp -d) fish'
Welcome to fish, the friendly interactive shell
Type `help` for instructions on how to use fish
$ fish --version
fish, version 3.1.0
# we think we are erasing the completion rules
$ complete -c git -e
# but this generates a tonne of completions (and is *very* slow)
$ complete -C"git checkout " | wc -l
1524
# try erasing again
$ complete -c git -e
# now it behaves as expected
$ complete -C"git checkout " | wc -l
56
I've observed the same behaviour, in terms of rules not being erased until having somehow been used, in 3.0.2 on RHEL7.5. This does not feel like "expected" behaviour.
Hmm, I understand. However is that "expected" from a user point of view? I may just be extrapolating from my own experience, but If a user puts complete -c git -e in their .config/fish/config.fish, they are probably expecting that to disable the completion ... as opposed to needing to artificially trigger the completion before disabling it.
From an implementation point of view, could complete -e effectively maintain a blacklist preventing such completions from autoloading?
Activity
faho commentedon Mar 6, 2020
Just like functions, completions are autoloaded, so this is to be expected. Before you try them they don't exist.
donkopotamus commentedon Mar 9, 2020
Hmm, I understand. However is that "expected" from a user point of view? I may just be extrapolating from my own experience, but If a user puts
complete -c git -ein their.config/fish/config.fish, they are probably expecting that to disable the completion ... as opposed to needing to artificially trigger the completion before disabling it.From an implementation point of view, could
complete -eeffectively maintain a blacklist preventing such completions from autoloading?zanchey commentedon Apr 5, 2020
We do this for functions by adding a tombstone (#213), which seems like a reasonable thing to support to me.
fix completion
fix completion
rsteube commentedon Nov 15, 2020
@donkopotamus seems adding an empty user completion prevents the system one to be autoloaded:
touch ~/.config/fish/completions/git.fishccoVeille commentedon Aug 22, 2024
Hi everyone, I'm reactivating this old issue
I found it by trying to understand why the project carapace was suggesting a strange hack for fish
I opened
I had a discussion with the maintainer of this project, and we agree the problem cannot be handled at carapace level.
I would like you guys to read the issue I quote, and if possible give us feedback here.
is there any hope to work on this ?
Thanks
zanchey commentedon Aug 24, 2024
Nobody is tackling it as far as I know.
ccoVeille commentedon Aug 24, 2024
Thanks @krobelus
Make "complete -e" prevent completion autoloading