Long line wrapping - duplicated new line

[gwenn]

I get

lish> abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrs

t 

instead of

lish> abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrs
t 

I see these commands with kitty --dump-commands:

draw s
screen_cursor_down 1
screen_cursor_back1 78
screen_carriage_return
screen_linefeed
draw
screen_carriage_return
screen_set_mode 25 1

[SolraBizna]

This is with an 80-column terminal, right? In iTerm2 and Konsole, when I try to reproduce this, I see the t on the same line as the rest of the input, in the 80th column. My first guess as to what's going on would be that kitty isn't emulating the line wrap mode command correctly.

[gwenn]

With kitty, I've just tried these libraries:

• linenoise OK
• replxx OK
• liner OK
• linefeed OK
• termwiz OK
• reedline OK

And I managed to reproduce the bug with iterm2: just copy/paste abcdefghijklmnopqrstuvwxyz_0123456789 twice.

[SolraBizna]

Okay, it sounds like the bug is indeed in liso. :)

And I managed to reproduce the bug with iterm2: just copy/paste abcdefghijklmnopqrstuvwxyz_0123456789 twice.

I tried that on my end, and while that doesn't work on its own, if I paste it twice, erase all, then paste twice again that does reproduce it. I'll try to figure out what's going on in here.

Sorry for my slow responses.

Edit: I can also reproduce it by filling a line with characters, deleting the last character, and typing another character. Every time I delete and type, it adds another line.

[SolraBizna]

16bbed4 should fix this. I'm not happy with my solution (I'm not happy with that whole function) but if it works, it works. If you can confirm it fixes it at your end, close the issue and I'll publish this commit as 0.7.1.

Thank you for finding this bug, and providing a reproducer.

[gwenn]

With liso up to date and iterm2, when i copy paste abcdefghijklmnopqrstuvwxyz_0123456789 twice, the cursor is kept on the first line while it should have been at the beginning of the second line.

[SolraBizna]

That's actually intended behavior. Additional lines will be added at the bottom only once there is actual text to put on them.

But now that I've said that out loud, I realize that I can't think of any other readline-alike that operates that way...

[SolraBizna]

I won't have time until next year to test this thoroughly, but c907549 would seem to resolve this with minimal impact to the code. I'd like to rewrite all the output sync code, but this should work for now.

[SolraBizna]

I believe this bug is fixed, and there has been no new activity on this bug.