[bug]: only considering 1 other window on width set, plus double enlargement with width unset and ':TroubleToggle'

[joehannes]

Problem description

If I got (wide monitor) 3 split windows horizontally next to each other I expect the other 2 unfocussed windows to relatively get smaller both, but only 1 gets resized, the other one stays as big as was and the 1 that gets resized gets really small ...

This happens if I set the width option alongside the minwidth option like so:

use({
	"beauwilliams/focus.nvim",
	config = function()
		require("focus").setup({
			excluded_filetypes = { "floaterm", "aerial" },
                        width = 130, -- useful because of my cursorcolumn=80,100,120 setup
			minwidth = 90,
			bufnew = false,
		})
	end,
})

This kinda makes the plugin useless for me since there is another bug regarding bottom windows like trouble:
when I leave the width option unset and leave it to the golden ratio calculation, if I then open and later close the Trouble window at the bottom ... the resize/focus-algorithm kicks in in a buggy way - it forgets the window has already been resized and resizes/enlarges the window a second time, making the focussed window huge and the others small, however in this golden-ratio mode, the other windows are both taken into account in my 3-split window setup

This way, wether I set the width or don't, I always run into strange sizing issues that I simply can't circumvent ... Please fix!!! Would love to use this :-) <3

[joehannes]

one possibly important comment: I'm mostly switching windows using the mouse, not using :Focus* cmds

[joehannes]

so I just found I might just wrap my TroubleToggle into a fn that would trigger FocusDisable and later FocusEnable ...
Playing around ...
I find FocusEnable itself to do the same wrong thingy ... like so:

Clicking twice into the wrongly sized window doesn't help either ...
I need to click into one of the other windows and then back into the overly sized window, then the algorithm falls back to something that's looking good (taking both horizontal splits into account), like this:

So, logical GIST:

When focussing windows with the mouse and on VimEnter the sizing is correct. When :FocusEnableing it does an oversized calculation and is showing faulty behaviour depending on wether the width option is set in cfg-opts. td

[joehannes]

I actually just found the reason for the odd behavior if the width option is set:
https://github.com/beauwilliams/focus.nvim/blob/3f2f08795d23e7717794592d62adec9003ca3c0b/lua/focus/modules/resizer.lua#L58
At this line you actually should set the winminwidth as well, like you do with the goldenratio option, but you forget about that it seems :-)

[joehannes]

OK, I just created a PR that fixes the problem with the width opt set, that actually was that it wouldn't set winminwidth at all ... if width is set.
Now, the other bug with the TroubleToggle thingy persists still

[beauwilliams]

Okay great so we've got the first issue fixed now. Could you try running :wincmd= next time after running focus disable and see if that normalises the windows?

[joehannes]

@beauwilliams just tried now in various combinations to run :wincmd= when the misbehavior occurs:

1. FocusEnable
2. Trouble
3. Click into your still bigger window to refocus after opening Trouble
   => window gets ultrawide <= that's the bug

At this very state:

• if I enter FocusDisable the windows get equalised and a subsequent wincmd= does nothing
• if I enter wincmd= without disabling Focus or Trouble, here I get exactly the desired layout, the same that actually was present just before I refocussed/reactivated the previously active window by clicking into it with the mouse

=> The bug root actually is - or so it appears to me -, that the focus plugin doesn't remember the active window when focus is passed to the Trouble window when opening Trouble ... when then switching back to the still pronounced previously active editor window instead of keeping it's dimensions (because it already was perfectly pronounced via the focus plugin before calling Trouble), it gets pronounce once again, thus becoming ultrawide ...

So to fix this you could:

• as a dirty hack: add that wincmd= after reentering the previously active buffer window
• as a real solution: add a flag that remembers the last active editorwindow and does prevent an additional pronunciation/enlargement if set (true) ...

[joehannes]

hey, just to report additionally what actually seems logic anyway:
just found that when in a focus-plugin-pronounced window and using telescope (for example to edit a different buffer in that window) the same thing happens:
=> When telescope closes itself and the window is refocussed with the new buffer loaded it gets overpronounced=superwide ...

[beauwilliams]

I will have to see the logic for how the screen dimension is set. As far as I am aware it should set it to a fixed size, but perhaps as you said there is something else happening.

We can force wincmd that would be quite easy for now at least.

I was working on a new API to set the sizes of the windows and the last part of it is tracking the state of all of the windows, quite a task and there were still some limitations that made implementing it hard. So I had to revert back. But the goal was to be able to track and set particular windows as focussed. I will see if I can find the time to work on it again