New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Add --boundaries options to move command #183
Comments
I agree that a workflow like this should be supported. Right now, it's, unfortunately, not supported
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
I need more time to think about it, but right now I agree. The synopsis could look like:
then your desired workflow could be achieved in the following way: One more alternative could be to introduce |
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
then executing
I agree that this case shouldn't fail, because it changes the way windows are being displayed. I think it should fail when executing
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 I think this is a simpler workaround for the problem. What do you think? |
It shouldn't fail because there other valid workflows Workflow 1. Suppose that
Workflow 2. Even if Given
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 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 |
Got it. It makes sense to me now. So the feature requested could be:
OPTIONS -h, --help --boundaries <boundary> --boundaries-action <action> The tree cli command sounds like a really cool feature. I'd love to see it in a future release :) |
Motivation
I'm currently trying to do something like:
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).The text was updated successfully, but these errors were encountered: