search

mridgers / clink

Bash's powerful command line editing in cmd.exe
mridgers.github.io/clink
GNU General Public License v3.0
3.22k stars 283 forks source link

Wrong cursor position when a line contains non-printable characters #453

Open kissge opened 7 years ago

kissge commented 7 years ago

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.

clink

chrisant996 commented 4 years ago

Working in chrisant996/clink fork.

SuCasa commented 3 years ago

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

chrisant996 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 notifications@github.com 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 https://github.com/mridgers/clink/issues/453#issuecomment-766465895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFR4KN7GDQCRIWF2H3LHQJDS3SZHRANCNFSM4DMM3ZFA .

-- Andy Holder 2aholder@gmail.com

chrisant996 commented 3 years ago

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.