How can I ignore Minimap's buffer in Zoom-Mode? about zoom HOT 10 CLOSED

This issue has been discussed before, e.g.: #3, #9.

The README states:

Please note that ignored windows are not resized when selected but all the windows are nevertheless arranged with balance-windows.

The fact is that in order to maintain a stable layout, balance-windows needs to be called anyway and in this regard there is no difference between a regular window and the minimap.

I'll add amore explicit FAQ entry for this.

from zoom.

Setting window-size-fixed in buffers I want to be fixed-size seems to work perfectly for me with zoom-mode (other windows are balanced/zoomed as expected for what I've tried). It may be worth mentioning in the FAQ. Is there some problem with this approach I haven't yet encountered?

Edit: As a disclaimer, I did have to advise zoom--handler to prevent zoom from doing anything when in the minibuffer with this setup; it seems the current method was not sufficient. I don't know if it matters, but I've only tried making side windows a fixed size.

from zoom.

@noctuid The problem of setting window-size-fixed to t for buffers it that the window balancing doesn't work well anymore, try this:

+--+--+--+--+
|B1|B2|B2|B2|
+--+--+--+--+

Where buffer B1 has window-size-fixed set to t, then start selecting other windows.

But, you're right, it may be worth it.

from zoom.

Good point. I generally don't have more than 3 buffers (and maybe the minibuffer), so the balancing works fine for my case. Balancing works fine with this layout for example:

------------------------------
|      top fixed size window   |
------------------------------ 
|                |                |
|                |                |
------------------------------

Also, if I use balance-windows-area instead of balance-windows in zoom--update, more complicated layouts like your example (or any amount of splits I tried) work much better. Unlike when using balance-windows, they balance perfectly when focusing the fixed size window, and when focusing other windows, the non-focused windows are balanced evenly. I don't know if the sizing is working perfectly as expected (with a fixed sized window, there's less room for the other windows), but it's good enough that I wouldn't be able to tell. Maybe it is worth experimenting iwth balance-windows-area if it doesn't cause other issues?

from zoom.

Unlike when using balance-windows, they balance perfectly when focusing the fixed size window

Hm, interesting, this looks like a bug in balance-windows. In fact, it just does nothing if there's a fixed window even when Zoom is disabled.

and when focusing other windows, the non-focused windows are balanced evenly.

This doesn't seem to be always the case in my tests.

Maybe it is worth experimenting iwth balance-windows-area if it doesn't cause other issues?

A weird issue appears when using balance-windows-area when I try to select text with the mouse in the current window, the wrong window is resized during the mouse down event.

from zoom.

This doesn't seem to be always the case in my tests.

Well even when using zoom normally (no fixed sized windows) with balance-windows there are cases where one window will become extremely thin comparatively. Any windows that weren't made really thin e.g. because of their relative position to the focused/zoomed window were balanced as expected for me when using balance-windows-area. It's not the same as balance-windows since it balances by area, and that may not always be desirable. For example with this layout,

|   |   |
|   |---|
|   |   |

The left window will be thinner when balanced with balance-windows-area since it has more height than the other two windows. balance-windows might be better here, but there are other cases where balance-windows-area gives a layout where the buffers are more readable/usable. When using zoom (without fixed sized windows), balance-windows-area seems to work as well or better for me. I think it's probably worth adding a customization option to use an alternate balancing function.

A weird issue appears when using balance-windows-area when I try to select text with the mouse in the current window, the wrong window is resized during the mouse down event

That's strange. When I try that, nothing happens.

from zoom.

Well even when using zoom normally (no fixed sized windows) with balance-windows there are cases where one window will become extremely thin comparatively.

Thin with respect to other (not the selected one) windows? Can you provide an example?

I think it's probably worth adding a customization option to use an alternate balancing function.

That's reasonable, I like the idea that the balancing algorithm can be customized, but unfortunately I experience that issue (see below).

In the meanwhile, if you don't want to patch zoom.el you can advise balance-windows in your init file:

(advice-add #'balance-windows :override #'balance-windows-area)

But I'm sure you already know of that. :)

That's strange. When I try that, nothing happens.

It start happening with 4 splits and it only happens with balance-windows-area:

1. C-x 1;
2. C-x 3 3 times;
3. select the second from left with the mouse by clicking in the middle of the window;
4. continue clicking inside that window.

In doing so the first window is resized a bit when the mouse is down.

from zoom.

Another thing I noticed is that with balance-windows-area the minibuffer gets resized when active, as it were a regular window.

from zoom.

Thin with respect to other (not the selected one) windows? Can you provide an example?

split-window-horizontally, split-window-vertically, then split-window-horizontally. Doing windmove-left and windmove-right to move between the two windows will smash the previously focused window for me.

In doing so the first window is resized a bit when the mouse is down.

Ah, I can replicate that. What happens for me is that the first window is visually resized and then resized back to its original size. This can be fixed (I tested it) by also advising before select-window to store the previously selected window and then checking against that in zoom--handler (checking get-mru-window in won't work because it will already be the new/current window in all cases).

Another thing I noticed is that with balance-windows-area the minibuffer gets resized when active, as it were a regular window.

Right, I advised around zoom--handler to prevent it from doing anything in the minibuffer. I put that in an edit in a previous comment but don't think I made it clear that the issue was that the minibuffer itself was being resized.

I definitely think that balance-windows-area probably shouldn't be the default. There are some cases where it doesn't work well/as consistently with zoom--update as balance-windows. I haven't looked into whether zoom--update could easily be changed to work better in these cases. As a more general solution, it may be worth looking at why balance-windows fails. I'll briefly look at that, but using balance-windows-area is good enough for me since I don't use complex window setups.

from zoom.

split-window-horizontally, split-window-vertically, then split-window-horizontally. Doing windmove-left and windmove-right to move between the two windows will smash the previously focused window for me.

That's the intended behavior, at least that's how balance-windows works. In Emacs windows are not a flat list they are more like a tree and balancing occurs siblings-wise.

This can be fixed (I tested it) by also advising before select-window to store the previously selected window and then checking against that in zoom--handler (checking get-mru-window in won't work because it will already be the new/current window in all cases).

I'm working on a new implementation which avoid advising select-windows and hooking window-size-change-functions. You can read more in this thread (originated from this bug report). You can find the current implementation in the devel branch.

The ultimate solution would be writing an ad hoc function to balance windows also taking into consideration the fact that we're going to zoom the selected window, but this looks so hard if you take a look at the implementation of balance-windows. I'd definitely avoid to maintain something like that in this repo. It seems that writing a naive version would be fairly easy but considering all the corner cases would be hell.

from zoom.