Expel from bottom of column

[gustavcedersjo]

I like the consume/expel functionality. I can, for example, have a large height editor above a small height shell where I run commands related to what I edit.

However, I find the two commands a bit asymmetric. To me, consume feels like a column operation, and expel feels like a window operation. I will try to explain what I mean. When I consume a window, it is the selected column that consumes an extra window. It is not the selected window that is consumed into a column. It feels like a operation on the column. When I expel a window, it is the selected window that is expelled from the column. It is not the selected column that gets a window expelled. It feels like an operation on the window.

I would like expel to expel the bottom window from the column. The main benefit would be that consume always reverts an expel and expel (almost) always reverts a consume. Almost any consume or expel by mistake is easily reverted by the other command. (The exception is if there is more than one window in the column to the right, where consume will take the top window, but expel will expel to a new column.)

The alternative consume/expel commands (consume-or-expel-window-{left,right}) are more symmetrical in their behavior in that the subject is always selected window.

[cyuria]

My understanding of What's Been Said

My generalisation of what you're saying is that currently you categorise the two operations based on the destination or result of the operation as opposed to the operation itself, which leads to a different categorisation of the two operations.

What you want to do is categorise said operations with regard to the operations themselves by reducing the effect of selecting a window, which currently creates the distinction between destinations.

Does this sound roughly correct?

A Possible Issue

The only issue I can see with this is it would be a hassle to expel a window that isn't at the bottom, as you'd have to expel everything underneath it, expel the window and then reconsume the windows that were there previously. The way I sse it you could formulate this as 2*n + 3 operations for some arbitrary depth stack where n is the number of windows underneath the target window.

My Own Suggestions

My suggestion would be to try to flip it around somehow so consuming feels more like a window operation, which would remove this issue. I can't think of a good way to do this right now though.

Possibly implementing some method of selecting multiple windows would help in this regard. Then consuming would affect all selected windows and so would expulsion. There would be edge cases we'd need to figure out, but the general idea is there. This would also allow expel and consume to be proper inverses of each other.

Another possible suggestion I have is that expel expels all windows in the stack below the selected window as well as the selected window. Consume could also maybe do something similar. This should be an easier change to make than my previous selection idea, and it would also solve the "expel and consume being inverses" problem. This solution would also mean at most 2 operations to remove a specific window, unlike the O(n) complexity in OPs solution.

One Last Bit

With any of the previously mentioned suggestions, we could also make them new, separate actions. I personally don't think there is much of an issue with the current actions, but moving around multiple windows is a bit of a hassle atm, which both of my suggestions would, at least partially, solve. I also think the current restriction of moving around just one window is possibly what's led to this issue in the first place.

[gustavcedersjo]

I like your suggestion that expel should expel all windows below the selected, but I think I would call it “split column”. Then the reverse “merge column” would consume the whole column to the right.

A slight modification of that suggestion could be as a variant of consume-or-expel-window-{left,right}, but where the selected window together with the windows below are moved.

However, I seldom (never?) use more than two windows in a column, so I don’t know how that would work out in practice.

[YaLTeR]

I'd like to avoid the complication of selecting multiple windows at once. I also thought some action to at least consume the column in full to the left or right could be useful, so you can "stack up" multiple windows together to the left and not just from the right.

[cyuria]

I figured window selection would be rather complicated to implement. It also would probably constitute a fair number of actions to select multiple windows during regular usage, which would make it not really viable. I personally do think my second suggestion could be useful though.

I also never use more than two stacked windows, but that's mainly because I run niri on my laptop, where I don't have that much vertical space. If I ran it on my desktop, I'd have a bit more vertical space and could see myself using three or more windows in a column. I can also imagine some theoretical application which spawned a number of small sub windows. I think GIMP can do something similar if you float everything. I would definitely be stacking those smaller windows together.

[gustavcedersjo]

I agree that multiple selections would be tricky to handle, mainly from a user's perspective. However, there are actions on multiple windows that are simple and easy to use, for example move-column-{left,right}.

I wonder if a new concept of "subcolumn" could be useful when dealing with multiple windows, where a subcolumn is the selected window and all windows below it in a column? Then one could consume or expel a subcolumn to the left or to the right, similar to the commands consume-or-expel-window-{left,right}, but for a subcolumn. A new pair of commands consume-or-expel-subcolumn-{left,right} could take the selected window and all windows below (i.e. the subcolumn) and move the them in or out of columns to the left and to the right. The selected window should be kept selected, so that a sequence of left or right commands move the same subcolumn further.

Use cases:

1. If you want to split a column, select the first window below the split (i.e. the top window of the new column to be created) and consume-or-expel-subcolumn-right to split the column above the given window.
2. If you want to merge column A into column B, select the top window of the column A and consume-or-expel-subcolumn-{left, right}, to move the (sub)column to column B.

When the subcolumn is exactly one window, the commands should work exactly as their window counterparts (i.e. consume-or-expel-window-{left,right}).

[YaLTeR]

Hm, in PaperWM expel actually works as you describe. And now we also have the consume or expel window as you mentioned. So maybe it makes sense to change expel to work how you describe.

Should it focus the expelled window?

[gustavcedersjo]

I think expel should not focus the expelled window, because I would like expel to revert what consume does. I want to get back where I was.

[YaLTeR]

Even if the expelled window was previously selected in the column, it shouldn't keep being selected? Should check what PaperWM does here.

[YaLTeR]

If you expel with the bottom window focused, PaperWM preserves the expelled bottom window focus (so its new column will be selected).

[YaLTeR]

17861e0 makes it so expel always expels the bottom window and doesn't focus it.