Skip to content

Vanishing cursor and prints to wrong lines #7479

@Ennea

Description

@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.

cmd

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.

Windows Terminal

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-OutputRelated to output processing (inserting text into buffer, retrieving buffer text, etc.)Issue-BugIt either shouldn't be doing this or needs an investigation.Priority-2A description (P2)Product-TerminalThe new Windows Terminal.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions