mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
9ba742ad9f
Suppose an application tries to print a double-width character starting in the rightmost column of the screen, so that we apply our emergency fix of wrapping to the next line immediately and printing the character in the first two columns. Suppose they then backspace twice, taking the cursor to the RHS and then the LHS of that character. What should happen if they backspace a third time? Our previous behaviour was to completely ignore the unusual situation, and do the same thing we'd do in any other backspace from column 0: anti-wrap the cursor to the last column of the previous line, leaving it in the empty character cell that was skipped when the DW char couldn't be printed in it. But I think this isn't the best response, because it breaks the invariant that printing N columns' worth of graphic characters and then backspacing N times should leave the cursor on the first of those characters. If I print "a가" (for example) and then backspace three times, I want the cursor on the a, _even_ if weird line wrapping behaviour happened somewhere in that sequence. (Rationale: this helps naïve terminal applications which don't even know what the terminal width is, and aren't tracking their absolute x position. In particular, the simplistic line-based input systems that appear in OS kernels and our own lineedit.c will want to emit a fixed number of backspace-space-backspace sequences to delete characters previously entered on to the line by the user. They still need to check the wcwidth of the characters they're emitting, so that they can BSB twice for a DW character or 0 times for a combining one, but it would be *hugely* more awkward for them to ask the terminal where the cursor is so that they can take account of difficult line wraps!) We already have the ability to _recognise_ this situation: on a line that was wrapped in this unusual way, we set the LATTR_WRAPPED2 line attribute flag, to prevent the empty rightmost column from injecting an unwanted space into copy-pastes from the terminal. Now we also use the same flag to cause the backspace control character to do something interesting. This was the fix that inspired me to start writing test_terminal, because I knew it was touching a delicate area. However, in the course of writing this fix and its tests, I encountered two (!) further bugs, which I'll fix in followup commits! |
||
|---|---|---|
| .. | ||
| bidi_gettype.c | ||
| bidi_test.c | ||
| bidi.c | ||
| bidi.h | ||
| lineedit.c | ||
| terminal.c | ||
| terminal.h | ||