[feature] Accept user input for additional launch arguments when switching jobs

[pyrrho]

Hey all, thanks for the awesome tool!

I'm currently working in monorepo-style repository that has a, uhh... non-trivial number of packages under a root workspace. One of the downsides to this repository model is that running build-all or test-all style commands tends to be a little slow (I'm looking at you, rust-analyzer). My workflow generally revolves around moving between cargo check --package A, cargo test --package B, cargo watch --package C, etc., and keeping a bacon check -- --package SomeProcMacroNonsense off to the side has really helped speed up some of my iteration times.

Unfortunately, I'm pretty much unable to use the job switching keybinds because I consistently need to re-target packages. Exiting the bacon process and relaunching with different cli arguments is obviously a functional answer, but it makes me feel like I'm... missing out(?) for lack of a better phrase.

I feel that adding some kind of (optional!) user-input injection when switching to or starting up a job would fill a gap. The default bacon ex command actually makes for a pretty good example;

# This parameterized job runs the example of your choice, as soon as the code compiles.
# Call it as
#    bacon ex -- my-example
[jobs.ex]
command = ["cargo", "run", "--example"]
need_stdout = true
allow_warnings = true

Imagine dropping some kind of placeholder into that command, command = ["cargo", "run", "--example", "{Example name}"]. It would require more complex argument parsing and some TUI magic, but if a user started a bacon check job (without additional launch args), made changes to one of their examples, then used the jobs menu to launch the ex job, bacon could open an Example name: ____ dialog/prompt that would let the user input the name of the example they want to launch.

As far as I can tell, this wouldn't need to change the semantics of additional launch arguments as they stand today -- those could still be passed into every job switched to during an execution of bacon. The exact semantics and syntax of this kind of dialog injection probably needs some thought, though, as my proposal is very much proof-of-concept level and doesn't consider the actual implementation in the TUI, the current command parsing logic, what happens if there are multiple placeholders, default argument, etc., etc..

[Canop]

This looks reasonable and very feasible.

I already have the bricks for the dialog prompt (see safecloset which is technically similar).

I just need to find some time...

[Canop]

Some ergonomics details might need some additional thought and work. Like, do we keep values on rerun ? What if there are several parameters: put the cursor in which one at opening ?

[Canop]

Side note: when there are a little too many jobs for keybindings, using ctrl-j then select a job in the menu can help.