[host] If you resize in a fullscreen app and the cursor is past the right of a line, but above the bottom of the buffer, then we'll insert an extraneous newline with the cursor on it.
#1 225 ouverte le 12 juin 2019
Métriques du dépôt
- Stars
- (35 764 stars)
- Métriques de merge PR
- (Merge moyen 27j 19h) (24 PRs mergées en 30 j)
Description
From MSFT:19938308
Prior to fixing MSFT:16861099, if you change the size of the font in TMUX, then we'll incorrectly do a resize operation (despite the fact that the buffer hasn't changed size). During that resize operation, we won't be able to find the cursor position, because the cursor is on a space character in the middle of the buffer.
When we get to the end of the loop, we'll try and newline to where the cursor is, but because it's above the end of the buffer, we'll leave it in the wrong spot.
If we fix that, then the buffer will still look wrong. This is because after we emitted the last line of text in the buffer, we must have called NewlineCursor, because the cursor is left at col 0 on the new last line of the buffer, and the status line will be on the second-last line of the buffer. If we fix the first part of this bug (being unable to find the cursor position), then the newline will still be there unfortunately. Whatever part of the resize operation that's responsible for newlining the cursor during the reflowing of the last line needs to not do that.
The old easy repro case was to open tmux then change the font size. You'd see a new line below the status line. However, MSFT:16861099 fixes that particular repro case. You can't just resize tmux, because it will get SIGWINCH'd, then redraw it's status line in the right place. I'd need to write another test manually.