Ctrl-C overwrites multi-line prompt

[karate]

fish version installed (version 2.4.0):

OS/terminal used: Fedora 24, gnome-terminal

When using a multi-line prompt, pressing ctrl-c will not preserve previously written command

Reproduction steps

1. Change fish_prompt function to show newlines

function fish_prompt
  echo (whoami)@(hostname)
  echo '$ '
end

2. Re-run fish, and type asdfasdf[CTRL-C]

[faho]

I can reproduce this. It seems we don't adjust the prompt position properly in this case, so we'll overwrite parts of the output (i.e. the previous commandline contents) with the prompt.

As a workaround, in __fish_cancel_commandline, you can change for i in (seq (commandline -L)) to

        for i in (seq (commandline -L)) (seq 2 1 (count (fish_prompt)))

This will rerun your prompt function which should usually be safe.

I'm not going to commit this because I'm pretty sure that it should be fixed in c++ (since this might show up elsewhere) and because I don't know how BSD seq handles this (@floam?).

[ghost]

I've had an issue that I think is related to this one (appeared after 2.3.1 -> 2.4.0 upgrade): I have a multiline Powerline prompt which gets broken when I Ctrl-C a prompt. It looks something like this:

If I apply @faho's fix (with an extra closing paren for syntactic correctness), it seems to work:

FYI, I'm running Manjaro with powerline-status v2.5 and urxvt v9.22.

[faho]

@bacondropped: Yes, that's the same issue.

[floam]

Well, if count (fish_prompt) is ever 1, then (seq 2 1 (count (fish_prompt))) with BSD seq will of course do this:

$ seq 2 1 1
seq: needs negative decrement

[faho]

So all we'd need is to ignore stderr? I wanted it to not generate a sequence. That was me being a smarty-pants.

Though again this executes fish_prompt again which might be slow or wrong, and I'm pretty sure that this is a symptom of a larger problem.

[floam]

Probably the entire ^C printing behavior would be better done in the c++.

[karate]

Even with @faho's workaround, the bug is still there when pressing ctrl-c after a multiline command. eg:

$ this is\
a multiline\
command[CTRL-C]

[ghost]

I don't have the problem @karate does: Ctrl-C inserts a highlighted ^C at cursor and breaks with a correct multiline prompt.

EDIT: actually, it sporadically inserts one-three empty lines after the broken command and before the multiline prompt. I can't seem to find any logic in when exactly it does that, but it seems to preserve both the interrupted command and the new prompt.

[samdmarshall]

I'm seeing this with a single line prompt, but I do have a function that gets run on change of PWD:

function current_path --on-variable PWD
    printf '<‌'
    printf '%s' $__fish_prompt_host
    printf '%s' $__fish_prompt_hostname
    printf '%s' $__fish_prompt_normal
    printf '‌> <‌'
    printf '%s' $__fish_prompt_path
    printf '%s' (prompt_pwd)
    printf '%s' $__fish_prompt_normal
    printf '‌>'
    printf '\n'
end

[sassanh]

After upgrading to 2.4 Ctrl-C shows a highlighted ^Cand breaks the command. It used to clear the line and I prefer clearing the line.

[ghost]

I prefer clearing the line

Same, to be honest. I'd prefer it to be configurable, though, but the user-friendly default is clearing for me, as opposed to breaking.

[faho]

I'd prefer it to be configurable, though

Rejoice, it is!

function fish_user_key_bindings
      bind \cc 'commandline ""'
end

[samdmarshall]

Thanks! that solved my problem completely.

[ghost]

And there was much rejoicing! Works perfectly both with and without the first workaround.

[sassanh]

Yeah I found this #3535 (comment) after commenting on this issue. I wonder if any of these approaches have benefits over the other one though. Currently I'm using the ridiculousfish approach and it seems to be alright.

[suut]

The same problem happens when we use alt+arrows to navigate through past folders, if we're at one end of the list the multiline prompt gets half rewritten.

Why couldn't the stuff do nothing when we're at one end of the list ? It's pretty disgracious.

[ridiculousfish]

I'm in favor of removing the "Hit end of history..." stuff if someone wants to open a PR.

[floam]

I'm making one. I'd like there to be some negative feedback, I prefer to output a terminal bell.

[floam]

No PR yet, but I like what floam@d524bad does

[zanchey]

@floam, any progress? Want to try and get a simple change in for 2.5b1?

[krader1961]

Moving the milestone since it would not be appropriate to cherry-pick a change to this behavior even if floam merged a fix today.

[Shadowigor]

Any progress on this issue? Ctrl-C has been broken for quite some time now for multiline prompts.

[zanchey]

Not at this stage; you can always subscribe to notifications using the GitHub interface if you're interested.

[edouard-lopez]

We have a similar issue with pure-fish/pure#157`, using a multiline prompt, hitting Ctrl+C when prompt command has text display double home folder.

❯ fish --version
fish, version 3.0.2

[faho]

Okay, it's possible I have a fix for this, and it's laughably simple:

# This is meant to be bound to something like \cC.
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 set -q fish_color_cancel
            echo -ns (set_color $fish_color_cancel) "^C" (set_color normal)
        else
            echo -ns "^C"
        end
        if command -sq tput
            # Clear to EOL (to erase any autosuggestion).
            echo -n (tput el; or tput ce)
        end
        for i in (seq (commandline -L))
            echo ""
        end
        commandline ""
        commandline -f execute
    end
end

[jgierer12]

@faho I have a similar workaround (bind \cc 'commandline ""') which works for the most part, but the issue still occurs if the commandline is redrawn by other means such as resizing the terminal window, or using commandline -f repaint like this plugin. Nothing deal breaking but still annoying.

[tjkirch]

@faho: Thanks for the suggestion in #3537 (comment)! That execute definitely improves things. The only issue is that the "^C" appears at your cursor position and clears the rest of the line, whereas I think the goal is to see the whole command that was canceled, and so the cursor position should be irrelevant. I thought the commandline -C 1000000 line near the top would be enough to make sure the user's cursor position wouldn't matter, so the tput would only clear suggestions and not the typed command line, but that doesn't seem to be the case.

Anyway, I'm assuming that your change eb35975 (the real cancel-commandline input function) is intended to replace this, and should resolve this issue with multi-line prompts, and become available in 3.2.

[faho]

I can't reproduce this anymore with the new bind function, so I'm closing it.