bug.n icon indicating copy to clipboard operation
bug.n copied to clipboard

wsltty / mintty not re-tiled after moving

Open yveslange opened this issue 6 years ago • 11 comments

Current state
3 windows, mintty in the master pane.

capture

Then I pressed: WIN + SHIFT + DOWN to move mintty to the next pane, the window is not resized correctly to the area space. I need to WIN + LEFT to force the size of the mintty window.

capture2

Any idea how to fix this ?

yveslange avatar Jan 28 '19 17:01 yveslange

Same thing happens when I drag a Chrome tab out of Chrome.

A new pane is created but the window doesn't fit it. I need to WIN+LEFT or WIN+RIGHT to make the window fit the area.

yveslange avatar Jan 28 '19 17:01 yveslange

Sounds like a timing problem. Does WinT for resetting the tile layout or resetting the current view have the same effect as WinLeft?

On the second screenshot the bug.n bar is visible, but not on the first one; is this intentional? If possible, please post the window information for mintty (WinI when the windows is active) in the first and second state.

joten avatar Feb 03 '19 13:02 joten

Sounds like a timing problem. Does WinT for resetting the tile layout or resetting the current view have the same effect as WinLeft?

Yes, it does have the same effect. After pressing Win+T the windows is resized correctly.

On the second screenshot the bug.n bar is visible, but not on the first one; is this intentional? If possible, please post the window information for mintty (WinI when the windows is active) in the first and second state.

Yes sorry, mistake on my screenshot. The bar should be visible on both screenshots.

Information about the active window:

ID: 0x1107fe
class:	mintty
title:	~
process:	mintty.exe [9512]
style:	0x14CF0000
metrics:	x: 1768, y: 18, width: 977, height: 912
tags:	1

Config_rule=mintty;~;;1;1;1;0;1;0;

kursion avatar Feb 05 '19 19:02 kursion

What is weird is that the initial placement and size of the windows is correct (after opening mintty.exe).

The issue comes when switching the window from on pane to another

kursion avatar Feb 05 '19 19:02 kursion

Please post the window information of the initial state, too.

Is the error reproducible by pressing WinShiftUp and WinShiftDown again or pressing WinShiftEnter twice?

If it is a timing issue, setting Config_shellMsgDelay=500 (or any other value greater than 350) my help.

joten avatar Feb 10 '19 11:02 joten

Hi,

here is the initial state (when I opened the window), then copying the text from WIN+i

ID: 0xb03e4
class:	mintty
title:	nvim TASKS.md
process:	mintty.exe [13852]
style:	0x150F0000
metrics:	x: 951, y: 15, width: 977, height: 1193
tags:	1

Config_rule=mintty;nvim TASKS.md;;1;1;1;0;0;0;maximize

yveslange avatar Feb 25 '19 14:02 yveslange

I have tested Config_shellMsgDelay=1000 for multiple days. It does not resolve the issue :'(

yveslange avatar Feb 25 '19 14:02 yveslange

I got a chance to test and reproduce the issue. It was a bit odd. At first it looked like a timing issue and that the mintty window got properly resized, but than reset again; inserting a Sleep, % Config_shellMsgDelay at the right place solved it. But in the end I excluded the line SendMessage, WM_ENTERSIZEMOVE, , , , ahk_id %wndId% for mintty -- a bit ugly, but it works and seems to resolve the issue.

Please have a try with the current development version (no executable available, the script 'Main.ahk' needs to be run with AutoHotkey).

joten avatar Mar 06 '19 16:03 joten

Thanks for you update. It seems that the WSL windows is now resized correctly.

yveslange avatar Mar 07 '19 12:03 yveslange

Now it seems that the WSL windows can't be moved to the next pane/previous pane

yveslange avatar Mar 07 '19 12:03 yveslange

That's too bad. I did not test it with WSL mintty, but cygwin's terminal. I reversed the change and put in an attempt regarding the timing issue. Please have a try with the current development version.

joten avatar Mar 08 '19 21:03 joten