First letter of command remains when iterating through history

[louy2]

The first letter of the first command longer than a threshold visited when iterating through history remains displayed, pushes subsequent iterations off one char, but does not affect the actual commands iterated.

Examples assume a clear prompt at the beginning.

Example:

1. First type npm
2. Use ↑ to iterate and see:

npm i webpack-dev-server --save-d

1. Use ↑ to iterate and see:

npm irun build

(should be npm run build)
4. Use ↑ to iterate and see:

nwebpack

(shoulde be webpack)
5. Use ↓ to iterate and see:

nnpm run build

(should be npm run build)
6. Use ↓ to get back to clear prompt and see:

n

(should be empty)

Strangely enough, the misdisplay doesn't affect the execution of the commands. The actual executed commands ignore the added letter. Short commands in the history such as ls and npm doesn't trigger this artifact.

[doggy8088]

I met the same problem also.

[louy2]

Went to test ConEmu, v150707 has no such issue. v140707 is used here, but no similar issue reports or related fix from 140707 onward discovered. Probably introduced by Cmder?

[zhaiyusci]

I've tested it more detailed and found that a command longer than 4 letters could trigger the problem. I do not know if you have exactly the same length of trigger one?

[zhfreal]

I got the same problem and replaced the ConEmu with the latest one(150707) , but not solved

[xlijun]

This is a duplicate issue: #506
I have the same problem. When a command larger than 4 character is displayed in the command history, the first letter will remain in the line, and kept pre-pended to other commands in the history.
I guess this has something to do with the system locale? I am using a windows 7 chinese version.

[Stanzilla]

@Maximus5 ConEmu issue or clink issue?

[Maximus5]

ConEmu do not handle command line history. So that would be a clink issue, most probably.
Just get latest clink sources and build it to check if your binaries are obsolete.

Of course, you should check latest ConEmu builds.
There is no sense to report issues about OLD BUILDS!

[Stanzilla]

Yup indeed, guys, go test with https://github.com/Stanzilla/cmder/releases/tag/1.2.6 please.

[Stanzilla]

Just found #264, can you guys try this workaround, please?

[MartiUK]

@Stanzilla Would adding a space after the lambda solve this issue?

[Stanzilla]

Not sure, that would be 3 bits then, no? And I guess the problem is that it's one symbol but two bytes and therefore clink leaves one up.

[Stanzilla]

paging @mridgers for help :)

[mridgers]

It is quite possible that Clink is at fault here - I am suspicious that the lambda character is causing Readline to misbehave because it is a multi-byte character. Does the issue go away if the lambda is replaced with something ASCII-compatible like a $?

[Stanzilla]

Alright so just as I thought, @louy2 @doggy8088 can you test that for us? You'd have to replace the lambda character in cmder\config\cmder.lua

[suimong]

@Stanzilla The problem go away when I replace the lambda character with >, >> or other ASCII characters.

[Stanzilla]

Thank you @suimong for confirming this.

@mridgers any way you can fix this or do we have to change away from the lambda?

[mridgers]

I'll look into the issue and find a fix. There'is no reason at all why you should have to change from the lambda.

[Jackbennett]

Focus testing on #506