Wrong cursor position when PROMPT contains non-printable characters

[chrisant996]

Importing from mridgers #453, originally posted by @SuCasa:

Here is the instruction to reproduce this bug:

1. Start a normal CMD.exe session
2. set PROMPT=$P$G^G (note: ^G = 1 character, type Ctrl+G)
3. Inject a clink session
4. Type a line that is longer than window width so that it wraps to the second line; just type it, do not hit Enter
5. Hit ↑
6. The first character is left uncleared, and also cursor position is weird (try ←)

Tested on clink 0.4.8 and Windows 10 Creators Update.
And also on clink 1.1.23.

[chrisant996]

Certain unprintable characters in the prompt aren't getting accounted for properly. I'll fix that for BEL, but it's difficult to make a fully comprehensive change that handles all possible unprintable characters for all of Unicode and for all fonts, so for now I'll only target certain well known characters like the BEL character, and maybe backspace (though that one gets weird with UTF8).

[chrisant996]

FWIW, git-bash has the same problem; this issue is inherited from bash and Readline. Bash/Readline documentation says it's the responsibility of the prompt author to add 001 (^A) and 002 (^B) characters before and after unprintable characters so that Readline knows which characters are unprintable.

However, I'll make Clink automatically handle the BEL (^G) character.