fish confuses tty line driver; backspace over tab in cooked mode emits wrong number of ^Hs

[gnachman]

To reproduce:

1. Run cat
2. Press tab
3. Press backspace

Expected result:

The terminal emulator should receive 8 ^H control codes to move the cursor over the tab and back into the first column.

Actual result:

Two ^H codes are received. (note: this probably depends on your current directory; see below)

What's happening?

fish prints several escape sequences before running cat. Here's what I see:

^[[30m^[(B^[[m^[]0;cat  /Users/georgen^G^[[30m^[(B^[[m

This confuses the tty line driver into thinking the cursor is somewhere in the middle of the line, so it prints the wrong number of ^Hs when it tries to move the cursor back over the tab.

Solution

Print a carriage return after those escape sequences and just before running the command. Then the tty will know the cursor is in the first column and cooked mode will be happy again.

Here is a very loosely related bug which inspired this report: https://gitlab.com/gnachman/iterm2/issues/3866

[pickfire]

It seems that it can't delete the tab.

[zanchey]

Should be fixed with 13479fb - thanks!

[ridiculousfish]

Reverted as 036a29a pending a fix for #2499.

[ridiculousfish]

Probably this is a simple adjustment - basically we need to tell screen.cpp about our cursor-repositioning shenanigans.

[faho]

I can't reproduce this anymore. @ridiculousfish: Did you simply forget to close?

[ridiculousfish]

I can still reproduce in iTerm2, where this was reported against.

[krader1961]

I can also still reproduce this. I fiddled around trying to fix this by applying @zanchey's change and adding a newline to the "abandon_line" logic in src/screen.cpp but couldn't get it to work. It looks like s_reset() is being passed screen_reset_abandon_line when that isn't appropriate (e.g., after a command like echo foo). Zsh seems to get this right so someone should look at how it does it.

P.S., The screen_reset_abandon_line_and_clear_to_end_of_screen symbol isn't used anywhere. That's suspicious.

[floam]

related?

ixjlyons@0fecba9

https://bugzilla.gnome.org/show_bug.cgi?id=763390#c4

[zanchey]

@ridiculousfish, did you still want to see if we could sort this out? If so I think it's worth trying to get it into 2.3b2 as it's a little risky.

[ridiculousfish]

Thanks for the ping, I'll take a look

[ridiculousfish]

Fixed in master and integration branch. I used zanchey's approach, except suppress the \r when executing it for the prompt. This avoids #2499, because the prompt is the first thing we execute after running a command, but it fixes this bug because we're going to run fish_title again right before running the next command (and then we do issue the \r).

I tried hard to write a test for this, but like window resizing, it's very resistant to automated tests. :(