Console.Unix: don't calculate cached cursor position from the last column. - #78466
Conversation
…lumn. After printing in the last column, setting CursorLeft is expected to place the cursor back in that same row.
|
Tagging subscribers to this area: @dotnet/area-system-console Issue DetailsAfter printing in the last column, setting CursorLeft is expected to place the cursor back in that same row. Fixes #77995. @adamsitnik ptal. cc @qt-kaneko
|
|
|
||
| // After printing in the last column, setting CursorLeft is expected to | ||
| // place the cursor back in that same row. | ||
| // Invalidate the cursor position rather than moving it to the next row. |
There was a problem hiding this comment.
Is this because behavior varies and so we can't predict what the terminal is actually going to do?
There was a problem hiding this comment.
We need to treat one position past the window width special in that setting CursorLeft from that will remain on the same line.
The position behaves special.
Console.CursorLeft = Console.BufferWidth - 3;
var positions = new (int Left, int Top)[5];
for (int i = 0; i < positions.Length; i++)
{
Console.Write((char)0xA3);
positions[i] = Console.GetCursorPosition();
}
Console.WriteLine();
Console.WriteLine(string.Join(" ", positions));When I run this, I get:
£££
££
(116, 4) (117, 4) (117, 4) (1, 5) (2, 5)
Notice how X is 117 two times. I assume on Windows, you'll see a (0, 5) for the second one.
With this change the visual behavior will now be the same as on Windows.
We could try to distinguish between the two (117, 4) but that brings extra complexity to the caching. Invalidating the cache is simpler.
adamsitnik
left a comment
There was a problem hiding this comment.
LGTM, thank you for the fix @tmds !
After printing in the last column, setting CursorLeft is expected to place the cursor back in that same row.
Fixes #77995.
@adamsitnik ptal.
cc @qt-kaneko