[Feature Request] Add --boundaries options to move command

[gabsrp2002]

Motivation

I'm currently trying to do something like:

If you can move the current window to the left in the current workspace, do it! Otherwise, move the window to the monitor in the left (wrapping around)

So I thought that the following simple zsh script would do it for me:

aerospace move left || aerospace move-node-to-monitor --wrap-around left

Unfortunately, that doesn't work, since aerospace move left does not fail when it can't move.

Feature request

I think it would be nice for aerospace commands to return something to indicate if they "failed" to do what they were supposed to do. It would be enough to solve my problem.

Alternative

Another way to solve it would be to make move to work similarly to the focus command (with boundaries and boundaries actions).

[nikitabobko]

If you can move the current window to the left in the current workspace, do it! Otherwise, move the window to the monitor in the left (wrapping around)

I agree that a workflow like this should be supported. Right now, it's, unfortunately, not supported

Unfortunately, that doesn't work, since aerospace move left does not fail when it can't move.

It doesn't fail because the mental model is different. When you "move window out", an implicit container is created. (See the "implicit container example" in the docs https://nikitabobko.github.io/AeroSpace/commands#move)

Creating an implicit container is always successful

---

Another way to solve it would be to make move to work similarly to the focus command (with boundaries and boundaries actions).

I need more time to think about it, but right now I agree. The synopsis could look like:

aerospace move
  --move-boundaries (workspace|all-monitors-outer-frame)
  --boundaries-action (stop|create-implicit-container)
  (left|down|up|right)

then your desired workflow could be achieved in the following way: aerospace move --move-boundaries all-monitors-outer-frame

One more alternative could be to introduce --no-create-implicit-container. But this alternative can be generalized with --boundaries-action fail (fail is like stop but with non-zero exit code)

[gabsrp2002]

Sure! It would be nice to have something like that.

I realized I wasn't clear when I talked about failing commands. I'll explain it better here:

I'd still like to create implicit containers when in a situation like

v_tiles
├── window 1 (focused)
├── window 2
└── window 3

then executing move left would give

h_tiles
├── window 1 (focused)
└── v_tiles
    ├── window 2
    └── window 3

I agree that this case shouldn't fail, because it changes the way windows are being displayed. I think it should fail when executing move left in a case like this:

h_tiles
├── window 1 (focused)
├── window 2
└── window 3

I think It doesn't make sense to have a h_tiles node parent with a h_tiles node child, since they would be displayed the same way in the monitor. In a case like that, I think it would make sense for the move left command to give a non-zero exit code.

I think this is a simpler workaround for the problem. What do you think?

[nikitabobko]

I agree that this case shouldn't fail, because it changes the way windows are being displayed. I think it should fail when executing move left in a case like this:

It shouldn't fail because there other valid workflows

Workflow 1. Suppose that enable-normalization-opposite-orientation-for-nested-containers is enabled
Given

h_tiles
  window 1 (focused)
  window 2
  window 3

move left will produce

h_tiles (implicitly created container)
  window 1 (focused)
  v_tiles (this h_tiles is from the previous state. It just got normalized and changed its orientation)
    window 2
    window 3

Workflow 2. Even if enable-normalization-opposite-orientation-for-nested-containers is disabled, there are valid workflows

Given

h_tiles
  window 1 (width=1/3, focused)
  window 2 (width=1/3)
  window 3 (width=1/3)

move left will produce

h_tiles
  window 1 (width=1/2, focused)
  h_tiles
    window 2 (width=1/4)
    window 3 (width=1/4)

---

The takeaway is that "create implicit container" cannot fail, it's always a successful operation.

I understand what you are trying to achieve, you want to get the best of both worlds somehow. But I'd like to ask: isn't aerospace move --move-boundaries all-monitors-outer-frame --boundaries-action create-implicit-container already the best of both worlds?

When there is another monitor in the move direction, we will move the window to that monitor. When there is no monitor in that direction, we will create an implicit container.

---

One more alternative could be to create an implicit container only in the case when the user moves out the window in a "perpendicular" direction. But I can't suggest an elegant synopsis for it (suggestions are welcome!). It might be too much of a generalization, and users are better off writing scripts around the aerospace tree command #16 (the command that'd allow to inspect the tree)

[gabsrp2002]

Got it. It makes sense to me now.

So the feature requested could be:

move [-h|--help] [--boundaries <boundary>] 
          [--boundaries-action <action>] (left|down|up|right)

OPTIONS

-h, --help
Print help

--boundaries <boundary>
Defines move boundaries.
<boundary> possible values: (workspace|all-monitors-outer-frame).
The default is: workspace

--boundaries-action <action>
Defines the behavior when requested to cross the <boundary>.
<action> possible values: (stop|fail|create-implicit-container)
The fail action makes the command return a non-zero exit code
The default is: create-implicit-container

The tree cli command sounds like a really cool feature. I'd love to see it in a future release :)

[JustSaX]

That's a missing key feature for me, too. For when is it planned? And is there a workaround currently? Without using a second keyboard shortcut for moving a windows to a different display.

[EcmaXp]

I've experimentally implemented this feature in a separate fork: https://github.com/EcmaXp/AeroSpace/tree/feature/move-with-boundaries

Please feel free to check it out and provide any feedback.

I also noticed there are some additional comments on this issue. 👀
It might take me up to a month to fully implement all the suggestions.

# aerospace.toml
ctrl-alt-left = "move left --boundaries all-monitors-outer-frame --focus-follows-window"
ctrl-alt-down = "move down --boundaries all-monitors-outer-frame --focus-follows-window"
ctrl-alt-up = "move up --boundaries all-monitors-outer-frame --focus-follows-window"
ctrl-alt-right = "move right --boundaries all-monitors-outer-frame --focus-follows-window"

[hgaogao]

This seems to be a good feature, because I migrated from glazewm, and I am used to the move command being able to switch between the Workspaces of the two monitors, because this can reduce the memory of a set of shortcut keys.

[torgeir]

Having moved over from Yabai recently, I welcome such functionality as well! As a sway user on the linux side of things, this is also how moving windows using move <direction> work by default.

If you can move the current window to the left in the current workspace, do it! Otherwise, move the window to the monitor in the left (wrapping around)

When working on something requiring multiple monitors, the ability to think "move this over there" rather than "move this to whatever workspace that monitor is currently on" reduces the mental overhead, leaving more room for the task at hand. The ability to get out of the way like this is a great feat of a window manager like Aerospace.