ENABLE_WRAP_AT_EOL_OUTPUT is not working with VT100

[Maxim-Kornilov]

The cursor doesn't moves to the beginning of the next row when it reaches the end of the current row. It works as intended when VT100 is disabled.

Windows build number: Microsoft Windows [Version 10.0.17134.523]

Code:

#include <iostream>
#include <string>
#include <Windows.h>

using std::string;
using std::cout;
using std::endl;

int main()
{
    HANDLE stdOut = GetStdHandle(STD_OUTPUT_HANDLE);

    DWORD consoleMode =
        ENABLE_PROCESSED_OUTPUT |
        ENABLE_WRAP_AT_EOL_OUTPUT |
        ENABLE_VIRTUAL_TERMINAL_PROCESSING;

    SetConsoleMode(stdOut, consoleMode);

    CONSOLE_SCREEN_BUFFER_INFO screenBufferInfo;
    GetConsoleScreenBufferInfo(stdOut, &screenBufferInfo);

    SHORT length = screenBufferInfo.dwSize.X;
    string str(length - 1, '.');
    cout << str;

    int before = 0;
    int after = 0;

    GetConsoleScreenBufferInfo(stdOut, &screenBufferInfo);
    before = screenBufferInfo.dwCursorPosition.X;

    cout << 'x';

    GetConsoleScreenBufferInfo(stdOut, &screenBufferInfo);
    after = screenBufferInfo.dwCursorPosition.X;

    cout << endl
        << "before: " << before << endl
        << "after: " << after << endl;
}

Output:

before: 119
after: 119

[miniksa]

End of line wrapping with ENABLE_VIRTUAL_TERMINAL_PROCESSING is visually delayed until we know what the next character is.

This enables applications to draw in the bottom right corner of the console screen without inadvertently triggering a newline and scroll up.

When we implemented this, it was consistent with how terminals on other platforms behaved.

Is there some actual scenario here where you're now experiencing a problem or regression, or is this just a simple observation from trying things out?

[Maxim-Kornilov]

End of line wrapping with ENABLE_VIRTUAL_TERMINAL_PROCESSING is visually delayed until we know what the next character is. When we implemented this, it was consistent with how terminals on other platforms behaved.

But documentation says that there is another flag for this particular behavior - DISABLE_NEWLINE_AUTO_RETURN
https://docs.microsoft.com/en-us/windows/console/setconsolemode

Normally when ENABLE_WRAP_AT_EOL_OUTPUT is set and text reaches the end of the line, the cursor will immediately move to the next line and the contents of the buffer will scroll up by one line. In contrast with this flag set, the scroll operation and cursor move is delayed until the next character arrives.

The typical usage of this flag is intended in conjunction with setting ENABLE_VIRTUAL_TERMINAL_PROCESSING to better emulate a terminal emulator where writing the final character on the screen (in the bottom right corner) without triggering an immediate scroll is the desired behavior.

[miniksa]

Hm, so it is. We'd have to look into it.

Can you please provide your scenario so I can get a sense of the fix priority here?

[Maxim-Kornilov]

I am making a REPL library in my spare time. It have a syntax highlighting, so I need to redraw part of the user input. I cannot rely on the absolute position of the beginning of user input, because it changes when a user resizes the window, so I recalculate it based on the current position and the length of input string. It worked well without VT100 but broke when I enabled it so I can use extended colors.

[malxau]

I also hit this inadvertently.

In my program I query the current cursor location and assume that when writing characters I should be writing to that location. This behavior confused my logic, because when writing to the final character on the line the cursor location is effectively moved one element backwards, so that when my program later goes to display a character, it overwrites the final character on the line rather than writing the first character on the next line. I'm not sure how I could work around this while still querying the cursor location since it becomes ambiguous whether if the cursor is at the final cell on a line whether that cell has been populated or not.

The higher level scenario for me is my program displays a prompt and then accepts user input. If the prompt ends exactly at the end of the line, the cursor will be at the end of the line (as opposed to the beginning of the next line) and user input overwrites the prompt.

I'm not really familiar with how other platforms handle this. I vaguely remember @jstarks mentioning to me that other platforms allowed the cursor to move to a "hidden" location off the end of the buffer in order to implement this behavior (but my memory is awful and I may have misunderstood from the beginning.) Another thought would be to advance the cursor without scrolling the buffer. But both have a strange new semantic that the cursor is no longer guaranteed to be within the buffer bounds, which I could imagine confusing some other application.

[j4james]

But documentation says that there is another flag for this particular behavior - DISABLE_NEWLINE_AUTO_RETURN

The documentation for that flag incorrect. DISABLE_NEWLINE_AUTO_RETURN determines whether a linefeed control character (i.e. \n) will also generate a carriage return. I believe it's set in the WSL bash shell, but not in the Windows cmd shell (i.e. you don't get an automatic carriage return in WSL).