Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to delete the text input #119

Closed
ajay15283 opened this issue Sep 7, 2021 · 19 comments
Closed

Unable to delete the text input #119

ajay15283 opened this issue Sep 7, 2021 · 19 comments

Comments

@ajay15283
Copy link

While using inquirer.Text or inquirer.shortcuts.text in any case the value typed is wrong unable to delete and retype the correct input

For eg:

[?] Provide the VM Size [example:Standard_B2s]: asdasdasdasd - Junk value entered , I need to delete and retype correct information, I know the "validation" can be an option but my question is when user realized he typed a wrong value and want to correct it

If there is already an option available to overcome this problem please let me know

OS : Linux
inquirer version 2.7.0
python: 3.6.13

@huhuang03
Copy link

same issue

@jonnieey
Copy link

jonnieey commented Jan 6, 2022

Same issue but works with ctrl-h

@skokado
Copy link

skokado commented Jan 19, 2022

I faced the same issue.
So I did the following debugging into inquirer.render.console._text.Text.process_input

Version info: inquirer==2.9.1

class Text(BaseConsoleRender):
    ...
    def process_input(self, pressed):
+       print("##", print(pressed))
        if pressed == key.CTRL_C:
  • my_cli.py
import inquirer

questions = [
    inquirer.Text("name", message="What's your name?"),
]

answers = inquirer.prompt(questions)
print(answers)

And, the result is as follows:

$ python3 my_cli.py
[?] What's your name?: a    # <= Pressed "a"
## None
[?] What's your name?: ab   # <= Pressed "b"
## None
[?] What's your name?: abc  # <= Pressed "c"
## None
[?] What's your name?: abc  # <= Pressed Backspace
## None
[?] What's your name?: abc  # <= Pressed Backspace
## None
[?] What's your name?: abc  # <= Pressed Enter
## None

{'name': 'abc\x7f\x7f'}

I think, pressed argument in process_input() is not passing values properly.
This library is too complex for me to give a PR for a quick fix, but I hope it helps :)

@skokado
Copy link

skokado commented Jan 24, 2022

Sorry, there was an error in the above debugging code.

class Text(BaseConsoleRender):
    ...
    def process_input(self, pressed):
-       print("##", print(pressed))
+       print()
+       print('##', pressed, type(pressed))
        if pressed == key.CTRL_C:

It is natural that print(... . print(pressed)) should result in None.
In any case, it looks like the Backspace key is not captured well.

[?] What's your name?:      # <= Pressed a
## a <class 'str'>
[?] What's your name?: a    # <= Pressed b
## b <class 'str'>
[?] What's your name?: ab   # <= Pressed c
## c <class 'str'>
[?] What's your name?: abc  # <= Pressed Backspace
##  <class 'str'>
[?] What's your name?: abc  # <= Pressed Backspace
##  <class 'str'>
[?] What's your name?: abc  # <= Pressed Enter
 <class 'str'>

{'name': 'abc\x7f\x7f'}

@alejandro-angulo
Copy link

alejandro-angulo commented Jan 24, 2022

I've also ran into this issue. I think the bug was introduced in 2.9.0 (I'm unable to reproduce this issue using 2.8.0).

@zahedul
Copy link

zahedul commented Feb 15, 2022

face the same issue. so I downgrade the version

@tim-hitchins-ekkosense
Copy link

This issue doesn't occur when installing directly from the github repo. Try

pip install git+https://github.com/magmax/[email protected]

and it will work. So I'm not sure what has been deployed to Pypi...

@eeriksp
Copy link

eeriksp commented Feb 19, 2022

Installing directly from Github still produces the same issue. Tested on Ubuntu 21 with Python 3.10.

@shymmq
Copy link

shymmq commented Mar 4, 2022

I got the issue on v2.9.1, but not on v2.9.0 (both versions from PyPI).

@cleeistaken
Copy link

OSX 12.1
Python 3.9.5
Inquirer 2.8.0: backspace works as expected
Inquirer 2.9.0: backspace does not work
Inquirer 2.9.1: backspace does not work

@OskarZyg
Copy link

not working on pop os 22.04 / python 3.10 with inquirer 2.9.2 either!

this is literally the most basic thing the library is supposed to be able to do, yet still cant handle text??

@Subetov
Copy link

Subetov commented May 17, 2022

OSX 12.3.1
Python 3.9.12
Inquirer 2.9.2
The same issue =(
Backspace doesn't work.
I can't remove or edit "default" value.

@ian-grover
Copy link

ian-grover commented May 27, 2022

The problem seems to be (at least on OSX 11.6.5) that backspace is interpreted as \x7f but CTRL+H is handled as \x08. For whatever reason, CTRL+H is captured and interpreted correctly but backspace just adds the escape character to the string. I think it will be related to readchar.key.BACKSPACE not recognising this other escape character.

A workaround which might be useful is to place this somewhere before using inquirer:

import sys, readchar
if sys.platform == "darwin":
		# change readchar key backspace
		readchar.key.BACKSPACE = '\x7F'

@OskarZyg
Copy link

Thanks, @ian-grover, that solution also works on Linux. Updated patch:

import sys, readchar
# fix inquirer
if any(x in sys.platform for x in ['darwin', 'linux']):
    # change readchar key backspace
    readchar.key.BACKSPACE = '\x7F'

I'll make a PR fixing this if I can.

@Cube707
Copy link
Collaborator

Cube707 commented Jun 27, 2022

This is actually a problem with V3.0.5 of the underlying readchar libary. It accepted and shipped a bad PR with the latest Version. I provided a fix as magmax/python-readchar#76, but the maintainer is not responding... (I also put instructions on how to install that PR's version as a worksround)

@Cube707
Copy link
Collaborator

Cube707 commented Jul 28, 2022

fixed with the new version of readchar, which is required by inquirer as per #206

@tekumara
Copy link

tekumara commented Aug 1, 2022

thanks @Cube707 upgrading to readchar 3.1.0 fixed this for me, eg:

pip install --upgrade readchar

@staticdev
Copy link
Collaborator

@Cube707 should this issue be closed then?

@Cube707
Copy link
Collaborator

Cube707 commented Aug 1, 2022

From my side, yes. Your decision if you want to wait on feedback from the participants. But as they could just reopen, I would close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests