Terminal: Vanishing cursor and prints to wrong lines

[Ennea]

Environment

Windows build number: Microsoft Windows [Version 10.0.19041.450]
Windows Terminal version: 1.2.2381.0

Steps to reproduce

Run this sample Python script:

import curses

def main(window):
        _, width = window.getmaxyx()
        window.getkey()
        window.addstr(0, 0, '-' * width)
        window.getkey()
        window.addstr(2, 0, '-' * (width - 1))
        window.getkey()
        window.addstr(4, 0, '-' * width)
        window.move(5, 0)
        window.getkey()
        window.addstr(6, 0, '-' * width)
        window.move(7, 1)
        window.getkey()

curses.wrapper(main)

Expected behavior

The script prints a bunch of lines made up of dashes. The first, third and fourth span the entire width of the terminal, the second is one character short. After each print of a line, the cursor should be visible. For the first and second lines, it should be right after the line (wrapped to the second row in case of the first one). For the third and fourth, the cursor is manually moved to the next row.

Actual behavior

Using Windows Terminal, the cursor does not show after printing the first line. It does after printing the second. It again does not after printing the third, and does show again after printing the fourth and last. Additionally, the lines are printed to row 0, 1, 4 and 5, instead of the expected 0, 2, 4 and 6.

Additional info

This one is _weird_. Originally I only wanted to file a bug for the vanishing cursor. When constructing some sample script, I also ran into the issue where successive prints also ended up on the completely wrong lines. So the cursor seems to vanish when printing _just_ as many characters to fill the terminal's width, so that the cursor has to wrap to the next line. Printing one less or one more does not make the cursor vanish. Manually moving it to the first column after printing such a full line will also not fix this, but moving it to the second column will show it again. And for some reason, even though I provide both y and x (in that order) to addstr in my sample script, Windows Terminal will not print these strings to the correct rows/lines.

[Ennea]

Also tested this in the latest preview (1.3.2382.0), bug still exists there.

[jdebp]

If it helps diagnosis any, PDCurses may or may not ignore the actual console screen buffer size (depending from what is in the process's environment), may or may not explicitly move the cursor around when outputting lines in doupdate() (depending from what is in the process's environment and one's colour choices), and doesn't reset the old console mode after changing it (only resetting it at endwin()),

• https://github.com/wmcbrine/PDCurses/blob/b12c4a5212e97cf83f0074618c1473253fad4131/wincon/pdcscrn.c#L418
• https://github.com/wmcbrine/PDCurses/blob/b12c4a5212e97cf83f0074618c1473253fad4131/wincon/pdcscrn.c#L406
• https://github.com/wmcbrine/PDCurses/blob/b12c4a5212e97cf83f0074618c1473253fad4131/wincon/pdcdisp.c#L157
• https://github.com/wmcbrine/PDCurses/blob/b12c4a5212e97cf83f0074618c1473253fad4131/wincon/pdcdisp.c#L129

[zadjii-msft]

@Ennea are you running the above python script with python.exe, or with a python from a WSL distro?

[Ennea]

@zadjii-msft ~Both. Whether I use Windows Terminal to run CMD or my WSL shell, the bug happens in both cases.~ Looks like I was mistaken, this only happens inside WSL. I use WSL 1, if that matters at all. I also tried Python 2 (I normally use 3 for everything nowadays), and the same thing happens.

Okay, second edit, sorry about this... I went back to it and can also successfully reproduce it in CMD, running Python 3.8:

import curses

def main(window):
    _, width = window.getmaxyx()
    curses.curs_set(0)
    window.getkey()
    curses.curs_set(1)
    window.addstr(0, 0, '-' * width)
    window.getkey()
    curses.curs_set(0)
    window.getkey()
    curses.curs_set(1)
    window.addstr(2, 0, '-' * (width - 1))
    window.getkey()

curses.wrapper(main)

What this sample script does, compared to the first one, is also hide the cursor first using curs_set, and then show it immediately before printing the lines. Besides this change, all the symptoms are the same. The lines that the strings are being printed to is off, and the cursor is not shown when it'd end up on the first column of the next line after printing.

[zadjii-msft]

oh man I'm having a faint memory of an issue where moving the cursor while the cursor was hidden at the end of a previous frame would cause us to fail to update it's location before printing the next conpty frame. I can't remember anything more about it off the top of my head though.

Fortunately, we've got a great minimal repro here, so we should be able to turn that into a unittest as well. Thanks!