Launching applications with $exec, defined as set $exec exec, does not work

[dev-forty-two]

• Description:
  I have reported this previously at sway's issue tracker: Launching applications with $exec, defined as set $exec exec, does not work  swaywm/sway#7718. However, they probably are not going to fix this anytime soon. Not sure if you would be interested either, but seems like it would be a minor fix. Thanks!

  I am reposting the issue below with "sway" replaced by "scroll":

  I am trying to have a shared config file between i3 and scroll, containing most of my keybindings, list of startup applications, etc., which is added to my main i3/scroll config files via include directives. In my main i3 config file, I have shorthand variables $exec and $exec_always defined as follows:

  set $exec exec --no-startup-id
  set $exec_always exec_always --no-startup-id
  

  Then in the shared config, I call $exec instead of exec --no-startup-id. This works perfectly in i3.

  In my main scroll config file, I tried to define

  set $exec exec
  set $exec_always exec_always
  

  in order to be able to use the shared config file. It does work when used in keybindings. For example,

  bindsym $mod+Return $exec alacritty
  

  works perfectly --- if I press $mod+Return, alacritty does launch. However, for launching applications directly, it does not work. For example,

  $exec thunderbird
  

  does not work. This seems to be incompatible with i3's behavior.

[dawsers]

They only do variable substitution for things that are not commands, otherwise even set would have its variable definition replaced or raising an error. I am sure it can be fixed with some special cases and doing variable substitution in a few places, but it is not a five minute fix, and would need quite a bit of testing not to break other things, so I cannot make this a priority having other more pressing issues.

scroll doesn't strive for i3 compatibility, that is sway. I am interested in having a smooth transition from sway to scroll, and reusing all the knowledge and stability of sway, but I don't even worry too much about sway compatibility, otherwise I wouldn't be able to make any changes. sway is a support base, not a goal, otherwise there would be no need for scroll.

[dev-forty-two]

That's fair. Keeping it open though, in case you want to revisit this after other pressing issues have been ironed out.