search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.4k stars 819 forks source link

Rendering failure with minicom #2166

Closed ChrisASnyder closed 7 years ago

ChrisASnyder commented 7 years ago

Version

Microsoft Windows [Version 10.0.15063]

Setup

Reproducing behavior

Alternative method:

Issue Description

Minicom creates a bar at the bottom of the terminal displaying connection information. When the window is resized this bar is not getting positioned on the bottom of the window correctly.

There is something with the window size and how minicom is trying to adjust it's display that isn't working correctly compared to Cygwin or linux terminals.

sunjoong commented 7 years ago

@ChrisASnyder

Running minicom directly in the bash shell also causes the same rendering issues

  1. Before resizing 1

  2. After resizing 2

  3. Maximizing - red circle of above screenshot 3

  4. Restoring - red circle of above screenshot 4

  5. After pressing Ctrl+A key 5

I think you want to see 5th in 2nd. If so... using https://github.com/goreliu/wsl-terminal may be a workaround.

zadjii-msft commented 7 years ago

@ChrisASnyder Does this only repro with the maximize/restore button, or does it also happen when resizing using the edges of the window?

sunjoong commented 7 years ago

@zadjii-msft - @ChrisASnyder said about resizing using the edges of the window, I think. I told them using maximize/restore and then Ctrl+A to redraw status bar.

wsl-terminal look like to be able to draw status bar just after resizing, but bash console seems to need maximize/restore.

zadjii-msft commented 7 years ago

Ooooh wait I think I see it. Did you resize only using the bottom of the window?

Try changing the width of the window and see if that makes the status bar appear at the bottom.

sunjoong commented 7 years ago

@zadjii-msft - Who raised this isssue was @ChrisASnyder, not me. But I saw bash console cannot do what wsl-terminal, i.e., Cygwin mintty, can do after to resize only using the bottom of the window, width and/or height.

zadjii-msft commented 7 years ago

@sunjoong I don't really have the time to crawl through old issues looking for the old, longer explanation I gave, but basically there's a compat issue with the console API that prevents us from sending resize events when the height of the console window changes, but the dimensions of the screenbuffer (with a default height of 9001) don't change. This is most resizes where only the height of the window changes.

And of course, because it's legacy behavior, we have to maintain it for legacy reasons -___-

sunjoong commented 7 years ago

@zadjii-msft - Hmm... you look like to misunderstand my word, I think. I mean @ChrisASnyder seems to complain why bash console isn't working correctly compared to Cygwin or linux terminals, and wsl-terminal is basically Cygwin mintty.

Hmm... It could be the best solution for @ChrisASnyder to use wsl-terminal for now becasue of that legacy reasons.

ChrisASnyder commented 7 years ago

@zadjii-msft After some more experimenting, moving only the height the bottom status doesn't update. If then resized right and left, will cause the bottom bar to refresh. Using the corner, as I tend to always do, results in a mixture of the other two behaviors.

It also appears that minicom has a minimum vertical which effects rendering windows getting made small. Something I didn't notice at first.

Knowing now that if I adjust the width after adjusting the height at least lets this stay usable. Less of an issue, there is also some weirdness when the scroll is used. The display only recovers when window width is adjusted. New text arriving in the terminal does snap the view, but doesn't redraw the bottom.

image

ChrisASnyder commented 7 years ago

I also wanted to clarify my point. I spend a lot of time in shells in Ubuntu and Debian, and Cygwin (mintty) with only the Bash on Windows having this inconsistent behavior. (that's probably a better label for the title now that I know a little more about it)

zadjii-msft commented 7 years ago

Yep. This is a known issue with the console. It's not a bash.exe problem, it's a conhost problem.

The WINDOW_BUFFER_SIZE_EVENT from ReadConsoleInput only fires when the screen buffer size changes, not when the window size changes. This is just how the API works unfortunately.

As you can see, resizing the width is a workaround. This is technically a dupe of #1001, so I'm gonna close it as such.

It may be worth pointing out that apps that use the alternate screen buffer (for term settings where smcup=\E[?1049h) won't have this problem - see tmux, emacs, vim, etc. These WILL get vertical resize events. Most full-screen terminal applications use this mode, it may be worthwhile for minicom to add support for that mode.