kill-whole-line bound to \cc breaks subsequent autocompletion

[ftilde]

• fish version: 3.1.0
• uname -a: Linux charon 5.6.6-arch1-1 #1 SMP PREEMPT Tue, 21 Apr 2020 10:35:16 +0000 x86_64 GNU/Linux
• $TERM: alacritty, but also happens in xterm

Problem description/steps to reproduce:

• Start a shell without additional configuration using sh -c 'env HOME=$(mktemp -d) fish'
• Execute bind \cc kill-whole-line
• Initiate autocompletion by typing (for example) fish --ver<TAB> (should be completed to fish --version)
• Kill the whole line using Ctrl-c
• Try to initiate the autocompletion for the same command again fish --ver<TAB>. Result: Nothing happens!

This also works/breaks for example for cd .con<TAB>, but interestingly not when mixing commands (i.e., first completing fish and then completing a folder for cd works find).
Also, this seems to be specific to binding it to Ctrl-c. I also tried Ctrl-f and Ctrl-d, but here the problem does not occur.

[zanchey]

I can't reproduce here on 2.7.1, 3.1.0 or master as of 2421eb6 - are you able to make a screencast or similar?

[ftilde]

Sure! Does this help? https://asciinema.org/a/YlhHJ6E88tVIglljOVSAHAOes

When trying to complete the second time the prompt flashes once, but nothing is completed, when pressing TAB (once or repeatedly).

[ftilde]

It looks like the problem is not present in 3.0.2, but does appear in both 3.1.0 and master for me. I'll try to bisect and report back.

[ftilde]

Bisecting reveals that 1978ac8 is the first bad commit which does indeed change a cancelation check complete.cpp which might be related to Ctrl-c also sending a sigint or something like that?

[krobelus]

I can reproduce on Linux.
IIRC the kill-whole-line is what Ctrl-c used to do many moons ago.

[ftilde]

I've stumbled upon this bug because I like Ctrl-c to (just) clear what I've typed (and possibly update the (multiline) prompt). If anyone else is having the same problem, I found a work around/another way to achieve the same when reading #3537. Just overwrite __fish_cancel_commandline:

function __fish_cancel_commandline
    # Close the pager if it's open (#4298)
    commandline -f cancel

    set -l cmd (commandline)
    if test -n "$cmd"
        commandline -C 1000000
        if command -sq tput
            # Clear to EOL (to erase any autosuggestion).
            echo -n (tput el; or tput ce)
        end
        commandline ""
    end
    # Repaint even if we haven't cancelled anything,
    # so the prompt refreshes and the terminal scrolls to it.
    commandline -f repaint
end

[krobelus]

Nice workaround, you can even replace the whole if block with commandline ""

[faho]

Okay, I think I have a rough idea what's going on here.

If you do commandline "", then that's a builtin, and we block signals and do some other stuff and run it.

But if you do kill-whole-line, then that's a bind function, and I think we might skip some of the ceremony, and that causes us to still receive sigint via \cc, which is why \cc is important.

@ridiculousfish should know more.

[ftilde]

Nice workaround, you can even replace the whole if block with commandline ""

Huh, indeed. Thanks! For reference here is the even more reduced version:

# Adapted from original function
function __fish_cancel_commandline
    # Close the pager if it's open (#4298)
    commandline -f cancel

    # Clear current command line buffer
    commandline ""

    # Redraw prompt (including now empty command line)
    commandline -f repaint
end

[ridiculousfish]

Looks like this is specific to bind \cc. This sends a SIGINT which sets the cancel flag, and this doesn't get cleared until fish script is next executed.

[ridiculousfish]

Thanks for filing!

[ftilde]

I can confirm that this fixes the issue. Excellent!