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
This one is subtle and the title is confusing. Sorry!
Given a terminal that is 80 characters wide, if 79 characters are entered at the prompt (including the prompt itself), the caret/cursor is now in the 80th column and no wrapping is triggered. Type in one more character and the caret moves to the start of the next line in anticipation of your input. All well and good.
If at this point you choose to execute the command as-is rather than append more text, this wrapped line is preserved in the output. This will appear to be an additional line of output rather than an extra line of input (especially if you typed it out quickly and hit enter knowing you were done, i.e. didn't wait for the cursor to move to the next line after entering a character in the 80th column).
e.g. the last two commands in the screenshot below actually produced identical output, but you wouldn't be able to tell that:
I believe we explicitly move the cursor to the next line regardless of the default terminal behavior/flags, right?
The text was updated successfully, but these errors were encountered:
Checking if the cursor position onscreen is a multiple of the screen width before writing the newline would fix it. However I didn't find a way to get the actual position of the cursor, only the position of the cursor without taking the prompt into account.
Inserting a char to see if the line count increases works, but it's a bit cumbersome and requires a repaint:
Of course the cursor does not have to be positioned at the end of the command when you hit return.
There's a risk that, if we do not emit a newline and instead rely on soft-wrap behavior, copy-and-paste of the terminal contents will discard the soft-wrapped newline. It seems at least iTerm2 does not have this issue.
I think we can still do this safely - we'll see if anyone spots a regression. Fixed in 4f103d7