PuTTY semi-bug win-pterm-line-wrap

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: pterm.exe handles line breaks badly on Windows 10
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: taxing: Needs external things we don't have (standards, users etc)
present-in: 0.77

pterm.exe on Windows 10 has some bad behaviour around line breaks and line wrapping.

If text wraps from one line to the next, and you copy and paste across the line break, pterm will include a physical line break in the pasted data, where the real Windows command prompt would not.

Also, if you type a line at the cmd.exe prompt that's long enough to wrap on to a second line, and then delete characters until the cursor moves back over the line break, a display glitch occurs which leaves the cursor off by one character from where cmd.exe thinks it is.

These look like bugs in pterm.exe, but we think they're actually bugs in the Windows component that translates console devices into escape sequences. In particular, on affected systems, pterm.exe receives exactly the same stream of input data from Windows when text wraps across a line break as it does if the same text is displayed with a deliberate newline. (So it can't treat the two situations differently, because they look identical to it.)

When we tested on Windows 11, these bugs didn't occur, which also supports the theory that a Windows component was causing them. It looks as if the version of that console translation component in Windows 11 has had these bugs fixed. So there's probably nothing we can do about them on Windows 10. Sorry.

(We think at least one of these issues might be related to issue #1245 in MS's Github repository for the terminal-handling code.)


If you want to comment on this web site, see the Feedback page.
Audit trail for this semi-bug.
(last revision of this bug record was at 2022-05-27 09:03:25 +0100)