Skip to content

Completions not erasing with complete -c <command> -e #6716

Closed

Description

@donkopotamus

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.

Activity

  1. faho commented on Mar 6, 2020

    @faho
    Member

    Just like functions, completions are autoloaded, so this is to be expected. Before you try them they don't exist.

  2. donkopotamus commented on Mar 9, 2020

    @donkopotamus
    ContributorAuthor

    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?

  3. zanchey commented on Apr 5, 2020

    @zanchey
    Member

    We do this for functions by adding a tombstone (#213), which seems like a reasonable thing to support to me.

  4. added this to the fish-future milestone on Apr 5, 2020
  5. added 2 commits that reference this issue on Oct 29, 2020
  6. rsteube commented on Nov 15, 2020

    @rsteube

    @donkopotamus seems adding an empty user completion prevents the system one to be autoloaded:

    touch ~/.config/fish/completions/git.fish
  7. ccoVeille commented on Aug 22, 2024

    @ccoVeille
    Contributor

    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

  8. zanchey commented on Aug 24, 2024

    @zanchey
    Member

    Nobody is tackling it as far as I know.

  9. ccoVeille commented on Aug 24, 2024

    @ccoVeille
    Contributor

    Thanks @krobelus

  10. added a commit that references this issue on Aug 24, 2024
    5918bca
  11. modified the milestones: fish-future, fish 4.0 on Aug 24, 2024
  12. locked as resolved and limited conversation to collaborators on Mar 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions