classification
Title: readline history, vi-editingmode and ANSI color codes bug
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: andrei.avk, nijoakim
Priority: normal Keywords:

Created on 2020-12-12 17:51 by nijoakim, last changed 2021-07-30 09:29 by nijoakim.

Files
File name Uploaded Description Edit
readline-example.py nijoakim, 2020-12-12 17:51 Minimal program to reproduce the bug
readline-example.py nijoakim, 2021-07-29 15:05 Remove mistake in example
Messages (7)
msg382917 - (view) Author: Joakim Nilsson (nijoakim) Date: 2020-12-12 17:51
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.
msg397626 - (view) Author: Andrei Kulakov (andrei.avk) * (Python triager) Date: 2021-07-16 13:33
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.
msg398488 - (view) Author: Joakim Nilsson (nijoakim) Date: 2021-07-29 15:05
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.
msg398498 - (view) Author: Andrei Kulakov (andrei.avk) * (Python triager) Date: 2021-07-29 16:30
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).
msg398499 - (view) Author: Andrei Kulakov (andrei.avk) * (Python triager) Date: 2021-07-29 16:38
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.
msg398523 - (view) Author: Andrei Kulakov (andrei.avk) * (Python triager) Date: 2021-07-29 23:34
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.
msg398530 - (view) Author: Joakim Nilsson (nijoakim) Date: 2021-07-30 09:29
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>
> _______________________________________
>
History
Date User Action Args
2021-07-30 09:29:04nijoakimsetmessages: + msg398530
2021-07-29 23:34:45andrei.avksetmessages: + msg398523
2021-07-29 16:38:11andrei.avksetmessages: + msg398499
2021-07-29 16:30:47andrei.avksetmessages: + msg398498
2021-07-29 15:05:39nijoakimsetfiles: + readline-example.py

messages: + msg398488
2021-07-16 13:33:50andrei.avksetnosy: + andrei.avk
messages: + msg397626
2020-12-12 17:51:50nijoakimcreate