Add more CLI flags

[nikitabobko]

(1) Add --window-id option to all or almost all commands. This option would make the command behave like if <window-id> was focused

Motivation:

• Under the hood --window-id is already presented. That's how on-window-detected.run is implemented. We could make it more transparent by saying in the docs that --window-id is applied by default to all of the on-window-detected.run commands. #20
• It's another way to fix #173 . We could say that if no args were passed to focus command then we force focus the current window. This way focusing the window by id becomes aerospace --window-id <ID> focus

(2) Add --no-follow-focus to move and --follow-focus to move-node-to-workspace commands (btw, it's inconsistent that move follows focus by default, but move-node-to-workspace doesn't).

Motivation:

• It makes scripting easier. Yes, it's possible to write aerospace move-node-to-workspace <workspace> && aerospace workspace <workspace>, but it gets more problematic when move-node-to-workspace is invoked by xargs. "Follow focus" is quite a common use case, it would be nice to have a flag for it.
• We could lift the second limitation from #20 by saying that --follow-focus is applied by default to move-node-to-workspace

(3) Add --format window-id (or --window-id-only) to list-windows command.

Motivation: It's tedious and error-prone to write aerospace list-windows | awk '{print $1}'.

In the same way, --format monitor-id (or --monitor-id-only) can be added to list-monitors command

---

Motivation for all 3 flags:

(a) Move all windows to the current workspace #185:

focused=$(aerospace list-workspaces --focused)
aerospace list-windows --all --format window-id | xargs -n1 aerospace move-node-to-workspace $focused --follow-focus --window-id

[nikitabobko]

--follow-focus

It's more correct to name it --focus-follows-window

[nikitabobko]

I'm thinking out loud

--window-id is a bad name. Since the flag affects a lot of commands, it should have a more distinct, verbosish name; otherwise, it could "occupy" a flag name that commands might want to use for their own purposes. For example, the focus command now occupied its own --window-id flag which is not exactly the same as the proposed --window-id in this issue

Another observation is that an empty workspace might be the "subject" as well. The workspace flag needs to be named with a symmetrical name

Proposals:

• --act-on-window-id <subject-window-id>/--act-on-empty-workspace <subject-workspace-name>
• --subject-window-id <subject-window-id>/--subject-empty-workspace <subject-workspace-name>
• --src-window-id <subject-window-id>/--src-empty-workspace <subject-workspace-name>

Description proposal: Make the command acts as if the <subject-window-id> or <subject-workspace-name> was focused before the command execution

Other things that need to be thought about are:

• Feature interaction with the future swap command #8. The command has two "subjects" it acts on. Are there any other potential commands like that?
• Feature interaction with move-node-to-workspace. What window should be focused by the end of the command if the --subject-window-id flag is used?

[nick-potts]

How about --target-window and --target-workspace

[nikitabobko]

To make the flags even more useful move-node-to-workspace (and maybe move-node-to-monitor) should add support for focused argument:

USAGE: move-node-to-workspace [-h|--help] [--wrap-around] (next|prev)
   OR: move-node-to-workspace [-h|--help] focused
   OR: move-node-to-workspace [-h|--help] <workspace-name>

https://github.com/nikitabobko/AeroSpace/issues/299

[MarcinDominiak]

Thanks for pointing me here, do you have a time horizon in mind for those changes? I'm quite eagar to start using move-workspace-to-monitor --workspace <workspace> focused, and while this is outside my area of expertise I think I might be able to contribute it in a PR. Does that sound good to you @nikitabobko or do you want to flesh out the design/have an implementation planned already?

[nikitabobko]

and while this is outside my area of expertise I think I might be able to contribute it in a PR

I prefer to it implement it myself. The proper implementation requires non-trivial rewrites around CommandSubject and CommandMutableState.

Though nobody can stop you from forking and implementing your own ad-hoc solution until the proper implementation is ready.

do you have a time horizon in mind for those changes?

Everything in this project is ready when it's ready