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
I could swear I had written the apt completions to limit the number of matches but it seems not to be working causing sudo apt install a^I to hang/block due to the number of results (this isn't the issue). In this case:
If after pressing TAB once then, while it is blocked generating completions, ^C is pressed, the completion is aborted (the commandline flashes, the completion is aborted, and the contents of the commandline remain), but
If, after pressing TAB and once the completion generation has begun and the shell is blocked, TAB is pressed again, this seems to put the shell in an invalid state where the completion is aborted (and the commandline flashes but its contents are preserved) but subsequent ^C invocations do not trigger the ctrl-c binding to clear the prompt, though all other commandline manipulation (e.g. bkspc) work just fine. After manipulating the commandline (add a character, backspace out a character, etc) the ctrl-c binding works correctly and clears the prompt thereafter.
(This is all sounding very familiar to me; I think I need to search previous issues some more because I think this happened before and was patched/corrected subsequently.)
The text was updated successfully, but these errors were encountered:
Occasionally it happens that when I hit Control-C while completing a command, no completions are loaded.
If that happens, completions will also not be loaded later in the shell session, so I have to restart fish.
Not sure if it affects just the one original command or all commands.
Sorry, GitHub ate all my vim-denoted keystrokes (à la <ctrl-c>) in the original post (and I didn't notice) making it impossible to tell what keystrokes I was referring to -- I've update it. The problem is hitting tab/^I in the middle of a completion, not ^C - although I think I've run into the bug you describe before (which I also feel has been discussed at one point or the other).
Logging this to look into at a later date
I could swear I had written the
apt
completions to limit the number of matches but it seems not to be working causingsudo apt install a^I
to hang/block due to the number of results (this isn't the issue). In this case:(This is all sounding very familiar to me; I think I need to search previous issues some more because I think this happened before and was patched/corrected subsequently.)
The text was updated successfully, but these errors were encountered: