eric pouech (@epo) commented about programs/cmd/wcmdmain.c:
len = lstrlenW(inputBuffer);len2 = len;/* Update current input display in console */set_cursor_visible(hOutput, FALSE);/* Calculate cursor position at beginning of prompt, accounting for lines scrolled* due to length of input.*/GetConsoleScreenBufferInfo(hOutput, ¤tConsoleInfo);currentConsoleInfo.dwCursorPosition.X = startConsoleInfo.dwCursorPosition.X;len2 -= (currentConsoleInfo.dwSize.X - currentConsoleInfo.dwCursorPosition.X);if (len2 > 0) {currentConsoleInfo.dwCursorPosition.Y -= ((len2 / currentConsoleInfo.dwSize.X) + 1);}SetConsoleCursorPosition(hOutput, currentConsoleInfo.dwCursorPosition);
did you try just reusing startConsoleInfo.dwCursorPosition here instead of recomputing the initial cursor position?
Actually I'm worried that we have to convert between cursor position from/to number of characters - this makes assumptions about how the string is layed out (one vs multiple lines, one string character == one cell == one glyph on screen (this is not the case for CJK characters; if we support them one day)) - anyway, I don't see a simple straightforward way to do it (ReadConsole doesn't return the farthest cursor point where it has written to, and since it can be on multiple lines...). - but the less code that does it, the better
the pain here comes from conhost wrapping the strings (in WriteConsole) larger than screen buffer width onto different lines... native use an unbounded line length and wraps it depending on window size.