You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similarly, if my cursor is in the middle of the screen, and I start winpty on cmd, then press F7, the F7 popup appears at the bottom of the terminal, but the popup always appears in the center of the console:
This happens because winpty must translate between the console (which is initially entirely blank) and the terminal, which typically has content on startup. winpty could have avoided this issue by clearing the terminal on startup, but that would hurt user experience overall.
So far, I'd considered this issue a limitation, but now I think it might be solvable by initializing the console cursor position to the terminal's cursor position. winpty would need to determine the cursor position at startup, which is possible using the DSR (Device Status Report) escape sequence.
When scraping, winpty wouldn't output the blank lines prior to the initial line. It would only output those lines once they changed, or once the cursor moved into them. Ideally, it would make some effort to shift the lines into the terminal's scrollback -- which I think happens with either Erase Display or Scroll Up.
Things to consider:
Are things like Agent::resetConsoleTracking and Terminal::reset affected somehow?
The new Windows 10 rewrapping behavior can already result in blank lines at the top of a console window that are not output. Are these situations related somehow?
The idea of blocking startup until the terminal responds to queries also came up with color translation (#45).
The text was updated successfully, but these errors were encountered:
Currently, running
console.exe cmd.exe /c cls
appears to have no effect:Similarly, if my cursor is in the middle of the screen, and I start winpty on cmd, then press F7, the F7 popup appears at the bottom of the terminal, but the popup always appears in the center of the console:
This happens because winpty must translate between the console (which is initially entirely blank) and the terminal, which typically has content on startup. winpty could have avoided this issue by clearing the terminal on startup, but that would hurt user experience overall.
So far, I'd considered this issue a limitation, but now I think it might be solvable by initializing the console cursor position to the terminal's cursor position. winpty would need to determine the cursor position at startup, which is possible using the DSR (Device Status Report) escape sequence.
When scraping, winpty wouldn't output the blank lines prior to the initial line. It would only output those lines once they changed, or once the cursor moved into them. Ideally, it would make some effort to shift the lines into the terminal's scrollback -- which I think happens with either Erase Display or Scroll Up.
Things to consider:
Agent::resetConsoleTracking
andTerminal::reset
affected somehow?The idea of blocking startup until the terminal responds to queries also came up with color translation (#45).
The text was updated successfully, but these errors were encountered: