Window resize

[Maximus5]

Originally reported on Google Code with ID 1411

OS version: Win7 SP1 x64
ConEmu version: 131225 [64]
Far version: n/a

Resizing the terminal window from a script, function or interactively fails.

Interactive example:

PS> "$([console]::windowWidth) x $([console]::windowHeight)"
120 x 73
PS> [console]::setWindowSize(120,70)
PS> "$([console]::windowWidth) x $([console]::windowHeight)"
120 x 73
PS> [console]::setWindowSize(100,73)
PS> "$([console]::windowWidth) x $([console]::windowHeight)"
120 x 73

Version info:

PS> $PSVersionTable|ft -auto -hide
PSVersion                 4.0
WSManStackVersion         3.0
SerializationVersion      1.1.0.1
CLRVersion                4.0.30319.18408
BuildVersion              6.3.9600.16406
PSCompatibleVersions      {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2

Reported by mb97531 on 2013-12-28 19:35:33

[Maximus5]

This action is prohibited (nite at least).
And, there is already existing issue with discussion about resize, which was initiated
from console application.
This one will be merged.

Reported by ConEmu.Maximus5 on 2013-12-28 19:39:13

[Maximus5]

My current point is that only user may resize terminal window! We said "no" to weird
scripts, programs or external applications.
Look. 
* E.g. you have three tabs. Some script tries to change its (as it think) console size.
Really? And how about two others? It will be definite unexpectedly change of their
size.
* you have splits on one screen. For example, grid 2x2. One pane tries to change its
size. Really? How ConEmu can change it without breaking splits configuration?
* you run the program in your console. And change size of the terminal window. And
close the program. It tries to "restore" it's console size. Really? I don't need that!
I eve can change terminal state Normal/Maximized/Fullscreen.

Prohibited. Definitely.

Reported by ConEmu.Maximus5 on 2013-12-28 22:58:28

[Maximus5]

Isn't there a Windows SIGWINCH equivalent? Normally, programs that care about terminal
size (e.g. vim, less, emacs or anything linked with libtermcap) catch SIGWINCH and
adjust themselves to the new window size. I'm assuming Windows has a similar mechanism,
probably called an event?

Off course, the split panes case does pose a problem. Perhaps, the easiest way to deal
with it is to deny a resize request if at least one tab with split panes exist. But
I don't see why resizing should be prohibited if there are no split pane tabs.

Reported by mb97531 on 2013-12-29 09:03:09

[Maximus5]

Yep, there is. As in the simple (real) console, so in the ConEmu too.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687093(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684961(v=vs.85).aspx

Another example.
One tab, I have Maximized ConEmu window and run second tab.
Worked a little and restore ConEmu to Normal.
Closed first tab.
And now:
* there is only one tab
* this tab (program in it) "thinks" that its original size must be some large (match
maximized window)
And what will happens when I will close it? Even if there is no more tab (but they
can be), we will have annoying flickering of the window.

Well, currently with GuiMacro you may change state of ConEmu window, example:
ConEmuC /GuiMacro WindowMaximize
I can add another macro to allow aware applications to change size of ConEmu window
(may be in pixels, may be in cells).
But console API? No. Not aware applications may (and will from my experience) break
user workflow.

Reported by ConEmu.Maximus5 on 2013-12-29 09:27:11

[Maximus5]

Ok, something like 'conemuc /guimacro WindowSizeInCells(<ncolumns>,<nrows>)' would be
very useful.

Reported by mb97531 on 2013-12-29 12:40:49

[Maximus5]

150216

Reported by ConEmu.Maximus5 on 2015-02-17 09:21:37

• Status changed: Fixed

[Maximus5]

Thank you, Максим!

The new WindowPosSize macro is an excellent enhancement.

Reported by mb97531 on 2015-02-18 01:02:37