Tested on Debian Bullseye with Python 3.9.

If 'set editing-mode vi' is used in .inputrc and the attached program is run, a bug occurs when navigating the readline history. It seems only to occur when ANSI color escape characters are input to the 'input()' function.

To reproduce the bug:
  Run 'readline-example.py'
  Enter '0123456789' in the prompt without quotes.
  Press enter.
  Press escape and then 'k' to go back in history in vi normal mode.
  The cursor is now placed between '2' and '3' and it is impossible to erase anything after the '2'. (To enter vi insert mode, press i and start editing the text normally.)

This bug does not occur for shorter strings. If for example '012345678' is input, the program behaves normally. If the escape characters are not used in the 'input()' function, program behaves normally.

I can't reproduce on MacOS in both Py 3.9.1 and in dev version. Works fine, I can erase everything after '2' and before it.

Sorry, my mistake. If you remove the last line "input()" from readline.py, it should be reproducible. Tested on Python 3.9.2.

Link to video demonstration of the bug: http://nijoakim.com/readline-example.mp4.

I was able to reproduce something very similar, and I believe essentially the same issue perhaps varying due to config. I think I've actually seen similar glitches with python command line readline handling of <esc>k.

So, entering 1234 always works fine. The issue starts with 5 chars:

1234
12345
12345   12345

As you can see, the line is duplicated and going up to it shifts cursor to the right, at first the duplication on the right side is blank but if I move the cursor to the right, the '1234' are revealed. '5' is still hidden. Then I have to press 'a' to see the '5' revealed and go into insert mode.

There's no way to go to the left of the duplicated string.

I hope someone more experienced in readline or more motivated can look more into this.

I duplicated it in 3.11 built from source, on MacOS Big Sur (on M1 cpu, but that shouldn't matter).

Also this bug happens on both iterm2 and terminal on MacOS, but note that on 'terminal', it's impossible to ctrl-c or ctrl-z out of the test script, so if you test it, you will need to close the window or the tab, and lose shell history and background jobs, so beware.

Joakim: by the way, what I was able to reproduce is just a visual bug. IOW, the text is still the same and all there in the buffer, but it shows up only after a combination of rightward movement and 'a', and a copy of it shows up on the left side. So it's not as serious as if the text was garbled or impossible to enter or change.

Yes, I have noticed that too, and I agree, not as bad as if it was garbled,
but still an annoyance.

On Fri, Jul 30, 2021 at 1:34 AM Andrei Kulakov <report@bugs.python.org>
wrote:

>
> Andrei Kulakov <andrei.avk@gmail.com> added the comment:
>
> Joakim: by the way, what I was able to reproduce is just a visual bug.
> IOW, the text is still the same and all there in the buffer, but it shows
> up only after a combination of rightward movement and 'a', and a copy of it
> shows up on the left side. So it's not as serious as if the text was
> garbled or impossible to enter or change.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue42626>
> _______________________________________
>