Order of option matters?! Shouldn't, imo.

[Ganneff]

Hi,

with the following code snippet:

let foo = TmuxCommand::new()
             .select_layout()
             .target_pane("vm_dmz:1")
             .layout_name("tiled")
             .output()?;
println!("{foo:#?}");

If one puts the .layout_name before the .target_pane, foo will contain a tmux error like stderr: "usage: select-layout [-Enop] [-t target-pane] [layout-name]\n",

The above order (first target_pane, then layout_name) works nicely.

Appears that the order of them function calls translates directly into the order things take on commandline for tmux.

I think that shouldn't be the case, unless the options really interact with each other. A user of this interface usually shouldn't need to care of the order tmux expects things in, that IMO would be the interfaces job to handle.

Greetings, Ganneff

[AntonGepting]

Hi,

thank you for your improvement idea. I agree, for an end user it would be better to have suggested abstraction and safety.

Most likely it can be changed right along with planned direct/control mode, single/multiple commands features. They imply some rework of basic instances. Anyway unfortunately I can't promise any dates.

[AntonGepting]

fixed in v0.3.0

thank you for the suggestion, I apologize for the very long waiting time for implementing this feature

Example

    let cmd1 = Tmux::with_command(
        SelectLayout::new()
            .target_pane("vm_dmz:1")
            .layout_name("tiled"),
    );

    let cmd2 = Tmux::with_command(
        SelectLayout::new()
            .layout_name("tiled")
            .target_pane("vm_dmz:1"),
    );

    assert_eq!(cmd1, cmd2);