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

Prompt Rendering Issue With Autocomplete - Windows 10 x64 CMD + Powershell #70

Open
niallnsec opened this issue May 17, 2018 · 7 comments · May be fixed by #257
Open

Prompt Rendering Issue With Autocomplete - Windows 10 x64 CMD + Powershell #70

niallnsec opened this issue May 17, 2018 · 7 comments · May be fixed by #257
Assignees

Comments

@niallnsec
Copy link

Bug reports

Expected Behavior

The prompt to allocate additional space when at the end of the consoles buffer for the autocomplete box.

Current Behavior and Steps to Reproduce

When reaching the end of a console windows buffer, if the autocomplete feature is enabled the buffer is not scrolled up to allow for space for the autocomplete suggestions. The result is that while the prompt is rendered at the bottom of the window, the actual cursor position is at the top of where the autocomplete box would have been rendered. For some reason only the bottom line of the autocomplete box is rendered.

In the screenshot below you can see the prompt at the bottom of the window with the cursor out of place a few lines above.
image
As soon as I start typing part of the previous output is erased and the prompt is re-rendered correctly.
image

Note that this only happens when the prompt is at the bottom of the consoles buffer not just the console window. ie. When the scroll bar on the console is all the way to the bottom. When there is still empty buffer space (console window scroll bar is not at the bottom) the previous output scrolls up as expected and the autocomplete box is given enough room to render.

Context

  • Operating System: Windows 10 x64 Build 16299
  • Terminal Emulator: Windows Command Prompt, Powershell
  • tag of go-prompt or commit revision: master
@ninlil
Copy link

ninlil commented Jan 22, 2019

bump | +1

I'm running in WSL (ubuntu 18.04 on Windows 10 build 17763.253) and get this on every autocomplete or similar menu. It does not differ if I'm at the bottom of the window or not.
This makes both go-prompt and the awesome kube-prompt unusable for us.

I have tried simple VT100-sequences to move "down", print some stuff and then "up" again, this works just fine (i.e as it's supposed to do).
I do not know what kind of cursor-commands your package uses but if I did I could try those to see what happens (if it's some error in the Windows 10 Console-code that causes this)

@niallnsec
Copy link
Author

I did a bit of digging last year and I have a feeling that the bug is actually in https://github.com/mattn/go-colorable/blob/master/colorable_windows.go

mattn/go-colorable is responsible for handling the VT control codes and converting them into Windows API calls which manipulate the console. It doesn't look like the package is handling the case where the screen buffer is already at the bottom of the actual buffer.
It is changing the cursor position like it should but neglects to call the appropriate API functions to move all of the existing output buffer up by one, essentially creating a blank line at the bottom of the terminal.

This kind of manual scrolling of the buffer is a pain, I did some tests to see if I could fix the bug myself but eventually left it due to time constraints.

It would also be possible to work around this bug inside of this package but that would go against the flow of the code, so I expect this will be down to mattn/go-colorable to fix.

@ninlil
Copy link

ninlil commented Jan 22, 2019

That is interesting code and I understand that problem with the buffer...
However, I'm compiling the Ubuntu build and that uses GOOS=linux, so it's not using the "windows" build-condition. But I will try to see if I can get the problem with that package standalone.

@unasuke
Copy link
Sponsor Collaborator

unasuke commented Apr 5, 2022

I completely forgot it, sorry. (and I received a notification email about the issue with a new comment, but it's disappeared...?)

I confirm the problem with today's master (82a9122), and here is the result.

8dac188501118e4b6c981453c29acf0f.mp4

Well, I think the problem described as "Current Behavior" cannot reproduce right?

If you have an opinion, please comment here.

@rovindsouza
Copy link

I am responsible for disappearing act :)
The behaviour is still the same but as @niallnsec has mentioned the odd behaviour is only seen when you are at the end of the bottom this becomes evident when you run the package within a terminal in VS code but when you run it in a command prompt or powershell which is launched the prompt behaves as expected.

@unasuke
Copy link
Sponsor Collaborator

unasuke commented Apr 6, 2022

odd behaviour is only seen when you are at the end of the bottom this becomes evident when you run the package within a terminal in VS code

It reproduced. Hmm... 🤔

a9a43b42e0b0ead46034d43cf1399203.mp4

unasuke added a commit that referenced this issue May 4, 2022
Add SaveCursorPosition and
RestoreCurcorPosition to output interafce
and use it in prepareArea
Fix #70

Co-authored-by: Masashi Shibata <c-bata@users.noreply.github.com>
@unasuke unasuke linked a pull request May 4, 2022 that will close this issue
2 tasks
unasuke added a commit that referenced this issue May 4, 2022
Add SaveCursorPosition and RestoreCurcorPosition to output interface
and use it in prepareArea
Fix #70

Co-authored-by: Masashi Shibata <c-bata@users.noreply.github.com>
@super-l
Copy link

super-l commented Jan 31, 2024

还没有解决啊

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

Successfully merging a pull request may close this issue.

7 participants