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

[niallnsec]

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. As soon as I start typing part of the previous output is erased and the prompt is re-rendered correctly.

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]

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]

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]

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]

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 (82a91227), and here is the result.

https://user-images.githubusercontent.com/4487291/161781875-c73e717e-2240-4289-84df-4f2a07bd40a7.mp4

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

If you have an opinion, please comment here.

[rovindsouza]

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]

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... 🤔

https://user-images.githubusercontent.com/4487291/161999293-c8d8e532-dd94-447a-891e-582f7954eb5d.mp4

[super-l]

还没有解决啊