You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some domains (config, space, and window) it makes sense to allow combining multiple commands for ease of use (within the respective domain --- cross-domain is not allowed).
yabai -m space --toggle padding
yabai -m space --toggle gap
->
yabai -m space --toggle padding --toggle gap
The way this works is by literally just looping through multiple commands if present, and performing them in order, so there is no functional difference between the two scenarios. Because of this, all commands are running with the same context (ie. they all operate on the selected entity if present or the focused entity if none is specified, as usual). Commands are processed even if the previous one may have failed (due to an error -- invalid argument, etc.) as long as there are no syntactical errors.
The main benefit is mainly that there is only a single sub-process spawned to send the message, instead of having to spawn x amounts of sub-processes -- this is likely most noticeable in the initial config statements during launch.
If you need to check the result (exit code) of a command to decide whether the next one should run, you should use two separate commands as before.
--
Just experimenting at the moment; might remove or tweak this.
The text was updated successfully, but these errors were encountered:
For some domains (config, space, and window) it makes sense to allow combining multiple commands for ease of use (within the respective domain --- cross-domain is not allowed).
config:
->
window:
space:
The way this works is by literally just looping through multiple commands if present, and performing them in order, so there is no functional difference between the two scenarios. Because of this, all commands are running with the same context (ie. they all operate on the selected entity if present or the focused entity if none is specified, as usual). Commands are processed even if the previous one may have failed (due to an error -- invalid argument, etc.) as long as there are no syntactical errors.
The main benefit is mainly that there is only a single sub-process spawned to send the message, instead of having to spawn x amounts of sub-processes -- this is likely most noticeable in the initial config statements during launch.
If you need to check the result (exit code) of a command to decide whether the next one should run, you should use two separate commands as before.
--
Just experimenting at the moment; might remove or tweak this.
The text was updated successfully, but these errors were encountered: