Running the fuzzy finder (tab) within a session clears the screen and hides command history

[jrop]

I have my shell set up with the following configuration:

• fish
• starship prompt

Relatively predictably (I'd say around 50% of the time), when I switch "tabs", the prompt does not display until I press "enter". Also, the terminal state is not fully restored reliably. That is, if I have typed a previous command, and I switch away from the tab, and then back, the output of the command I previously ran is not reliably shown.

[austinjones]

Hi @jrop,
Thanks for the bug report! I use fish and starship as well. I'll see if I can reproduce the prompt issue.

The second issue you describe seems strange. Are you invoking tab with multiple users? For security reasons, the daemon runs under the context of your local user account when you invoke tab. If you launch tab foo, disconnect, and then run sudo tab foo, two daemons/sessions would be launched and the behavior would be similar to what you describe.

If you can reproduce this, could you upload the daemon logfile? On OSX it is at ~/Library/Application Support/tab/daemon.log, and on Linux it is at ~/.local/share/tab/daemon.log.

[jrop]

@austinjones I don't see anything abnormal in the logs:

15:23:55.995 DAE [INFO] Resizing tab 0 to (110, 56)
15:24:12.553 DAE [INFO] Resizing tab 1 to (110, 56)
15:24:15.514 DAE [INFO] Resizing tab 0 to (110, 56)
15:24:17.772 DAE [INFO] Resizing tab 1 to (110, 56)
15:24:20.528 DAE [INFO] Resizing tab 0 to (110, 56)
15:24:23.568 DAE [INFO] Resizing tab 1 to (110, 56)
15:24:25.993 DAE [INFO] Resizing tab 0 to (110, 56)
15:24:31.816 DAE [INFO] Retasking subscription from TabId(0) to Some(TabId(1))
15:24:31.816 DAE [INFO] Resizing tab 1 to (110, 56)
15:24:35.279 DAE [INFO] Retasking subscription from TabId(1) to Some(TabId(0))
15:24:35.280 DAE [INFO] Resizing tab 0 to (110, 56)

[austinjones]

Thanks for uploading the log! This rules out all the PTY connection and session init code. That looks like a typical retasked session (when you type tab <name> within a session).

I think somehow scrollback is not being delivered to your client when it is retasked. And when you press enter, it triggers new stdout data. This is starting to make sense...

[austinjones]

I think I have a fix for this! It looks like the cause was an integer underflow in the scrollback buffer code, which caused the buffer to believe that it was massive. The buffer would be emptied, and keep being emptied as data arrived.

[jrop]

@austinjones awesome! I can't wait to try the fix out! (probably tomorrow)

[austinjones]

Ah! The cause here is typing tab with no arguments inside a session. I reconstructed the raw stdout from your debug logs, cat'd it, and started seeing fuzzy finder output (was very surprising) :D

Nothing is being lost. The fuzzy finder output is being saved to the session, and replayed when you reconnect. It includes escape sequences that clear the screen. Thus, no history.

Quick workaround is to use ctrl-T instead of tab with no args to escape from a session. Should have a fix soon though!

[austinjones]

I can see why this was so confusing. It looks identical to the ctrl-T fuzzy finder! What a bug...

[jrop]

@austinjones Ah! Very interesting I should have probably just posted an asciinema, and all would have been clear right away. Thank you for your help in tracking this down!

[austinjones]

Hey @jrop,
@foisonocean I just released v0.5.4 with a quick workaround (now it'll print a message suggesting ctrl-T). In v0.6.0 I'm going to add full retask support, so the outer command-client will be switched into fuzzy-finder mode. Tracking that one in #294