Wrapped line is preserved even if nothing is written before executing

[mqudsi]

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?

[zanchey]

I've actually noticed this before! I think it happens in other shells too.

[krobelus]

Interestingly, it seems to happen in zsh, and bash when invoked as sh, but not in normal bash (with or without --posix) or in dash.

[fratajczak]

The newline comes from this line in reader.cpp:

fish-shell/src/reader.cpp

Line 3584 in 06658cd

ignore_result(write(STDOUT_FILENO, "\n", 1));

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:

	size_t old_line_count = screen.actual.line_count();
	insert_char(active_edit_line(), L'a');
	size_t new_line_count = screen.actual.line_count();
	delete_char();
	repaint();
	if (old_line_count == new_line_count){
		ignore_result(write(STDOUT_FILENO, "\n", 1));
	}

(this also triggers #6951)
Is there a better way?

[ridiculousfish]

There's a few subtleties here:

1. Of course the cursor does not have to be positioned at the end of the command when you hit return.

2. 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