Wrong cursor position when a line contains non-printable characters

[kissge]

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.

[chrisant996]

Working in chrisant996/clink fork.

[SuCasa]

Found this same bug still exists in version 1.1.23 (using Ctl-B for smiley faces in prompt)

[chrisant996]

Found this same bug still exists in version 1.1.23 (using Ctl-B for smiley faces in prompt)

Oh, thank you, and I'm sorry -- I had missed that the prompt portion includes an unprintable character, specifically the BEL character. 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).

Opened #64 to track this in the chrisant996 fork.

[chrisant996]

FWIW, bash behaves the same way. Its documentation says the prompt author is responsible for surrounding unprintable characters with \001 (^A) and \002 (^B) characters so that Readline can calculate the prompt length accurately.

So technically it's working as intended, and the prompt just needs additional special characters added.

However, I've added special case code in Clink to automatically surround BEL (^G), just like it automatically surrounds ANSI escape codes.

[SuCasa]

Thanks for the "prompt" response. I hadn't noticed the problem on bash (4.3.46) or my normal zsh (5.1.1), but I've just changed my prompt to drop Ctl-B anyway. Big thanks to you guys for maintaining clink, ESPECIALLY fixing the "leading space cancels doskey macro expansion" error (#4189) that the Microsoft terminal guys haven't fixed for over a year.

…

On Sun, Jan 24, 2021 at 7:10 PM Chris Antos ***@***.***> wrote: FWIW, bash behaves the same way. Its documentation says the prompt author is responsible for surrounding unprintable characters with \001 (^A) and \002 (^B) characters so that Readline can calculate the prompt length accurately. So technically it's working as intended, and the prompt just needs additional special characters added. However, I've added special case code in Clink to automatically surround BEL (^G), just like it automatically surrounds ANSI escape codes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFR4KN7GDQCRIWF2H3LHQJDS3SZHRANCNFSM4DMM3ZFA> .

-- Andy Holder 2aholder@gmail.com

[chrisant996]

Thanks for the "prompt" response.

I see what you did there! 😄

I hadn't noticed the problem on bash (4.3.46) or my normal zsh (5.1.1),

Do you use \a in Bash? That'll work fine because it's a special bash prompt code, rather than a raw BEL (^G) character.