Support multiple windows

[vaygr]

Thank you for this nice project!

I'm looking for a lightweight tmuxomatic replacement, however what's keeping me there might be a good feature for tmex -- multi-window support.

Is it something you could consider within tmex? Maybe running tmex with the same session name but with additional flag could create next window instead of detaching from the old one and re-attaching?

Another thing could be a focused pane for every separate window. Maybe with an -f P1,P2 flag.

[evnp]

Hey @vaygr, those both seem like great ideas, thanks. I'd be very interested in adding these features to tmex. I've been thinking about possible interface changes to accommodate this, curious what you think.

Maybe running tmex with the same session name but with additional flag could create next window instead of detaching from the old one and re-attaching?

100% on board with this as a way of composing a session from multiple commands. I'd also love to support the option of doing it all in one command – thinking something like this (using a -w/--window flag):

tmex mysession 12 "cmd 1" "cmd 2" "cmd 3" -w 21 "cmd 4" "cmd 5" "cmd 6" -w "cmd 7" "cmd 8"

This would spawn a session with window 1 running commands 1,2,3, window 2 running commands 4,5,6, and window 3 running 7,8. Each window can optionally have a layout specified. Each set of args following -w is treated as a full independent set of tmex args (with session name optional after the first), which I think would make implementation more straightforward.

The above would be equivalent to:

tmex mysession --window --detached 12 "cmd 1" "cmd 2" "cmd 3"
tmex mysession -wd 21 "cmd 4" "cmd 5" "cmd 6"  # same flags, but shorthand
tmex mysession -w "cmd 7" "cmd 8"  # finally attach to mysession which will now have 3 windows

Or instead of using --detached, you could run tmex from within the session to accomplish the same thing:

$ tmex mysession 12 "cmd 1" "cmd 2" "cmd 3"
  # now we're in mysession
[mysession:window1] $ tmex -w "cmd 4" "cmd 5" "cmd 6"
  # a window is added to mysession, and we're taken to that window
  # sessionname arg can be inferred from this context so you don't need to provide it
[mysession:window2] $ tmex -w "cmd 7" "cmd 8"
  # a third window is added, and we're taken to that window (or use --detached to create in background)
[mysession:window3] $

All this seems to make pane focus pretty natural to incorporate as well – -f/--focus could always accept a single integer (and error if anything else is passed, or if the int is out of range of the pane count). Each of the variations can accept focus for each window:

tmex mysession -l 12 -f 2 "cmd 1" "cmd 2" "cmd 3" -w -l 21 -f 1 "cmd 4" "cmd 5" "cmd 6" -w -f 1 "cmd 7" "cmd 8"

tmex mysession --window --detached --layout 12 --focus 2 "cmd 1" "cmd 2" "cmd 3"
tmex mysession -wd -l 21 -f 1 "cmd 4" "cmd 5" "cmd 6"
tmex mysession -w -f1 "cmd 7" "cmd 8"

or even this shorthand would be valid:

tmex mysession -wdf2 12 "cmd 1" "cmd 2" "cmd 3"
tmex mysession -wdf1 21 "cmd 4" "cmd 5" "cmd 6"
tmex mysession -wf1 "cmd 7" "cmd 8"

Does this design seem like it would support your use cases well?

[vaygr]

Yes, this looks exactly what I envisioned.

However, does it mean that commands only in 1 pane (the focused one) would be executed? I'd prefer to be able to choose what commands in what panes in what windows to execute.

[evnp]

Sorry about the delay here, been quite a week.

I may have limited understanding here due to the ways I use tmux, but my expectation would be that command execution behavior would remain the same as it is now – if you specify a command for a pane (instead of specifying an empty pane via the layout), the command is executed as soon as the pane is spawned, regardless of whether it's focused or not.

This means I can run tmex parallelsession "sleep 10" "sleep 10" "sleep 10" and all sleeps immediately start running in parallel, whether pane 1, 2, or 3 (default) is focused.

Is the ability to delay execution of commands in some panes, perhaps until they're focused, something that you're looking for?

[vaygr]

Sorry, yeah, I got confused by one of the long lines in the example. Everything is clear now. Nothing extra besides what you initially proposed is needed.

[evnp]

Great to hear! I'll be working on this very soon (along with a few other minor improvements). Thanks again for the feedback and ideas.

[movy]

Hello, Any progress on this? The tool is amazing btw!

[evnp]

Hey @movy, thanks! Sorry about the long delay in response, have been sidetracked from this project by some other life events this year. I'm in the midst of an implementation on this, and should have something soon.

[movy]

Thanks for the uodate, this is great

On Sun, 14 May 2023 at 02:02, Evan Purcer @.***> wrote:

Hey @movy https://github.com/movy, thanks! Sorry about the long delay in response, have been sidetracked from this project by some other life events this year. I'm in the midst of an implementation on this, and should have something soon.

— Reply to this email directly, view it on GitHub https://github.com/evnp/tmex/issues/5#issuecomment-1546731687, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBCXMBL4CJ3V2KBNRZLD23XF7LGDANCNFSM6AAAAAARGF6CPU . You are receiving this because you were mentioned.Message ID: @.***>

[evnp]

Hello @vaygr @movy, I've just published https://github.com/evnp/tmex/releases/tag/v2.0.0-rc.1 which implements the features described in this thread, along with some other things. I decided to make this the 2.0.0 release to reflect the fact that it includes significant changes to the tmex code, and thus comes with some risk of regression. The test suite has been expanded from 60 to around 250 test cases at present, to help mitigate this risk.

I'll be working on edge-case hunting and testing even further over the next two weeks, at which point I'd like to move from v2.0.0-rc.1 to a full v2.0.0 release (if no issues are discovered, and if so that timeline will be adjusted to fix them). Any bandwidth you have to try out the new version / report any issues is greatly appreciated!

[vaygr]

This is awesome @evnp! Excellent work on tests too. I'll start experimenting with the new version ASAP.

[evnp]

Thanks @vaygr! Let me know how it goes. Definitely open to refining behavior of the new features as well, if you have any thoughts/feedback on the design.

[vaygr]

One thing I noticed that focused pane arg doesn't work if:

1. layout is specified via a shorthand
2. it's put after the layout spec

i.e.:

• tmex win -w abc -f4 -l 123 works
• tmex win -w abc -l 123 -f4 works
• tmex win -w abc -f4 123 works
• tmex win -w abc 123 -f4 doesn't

maybe that should be clarified in the manual.

[evnp]

Great point. The "shorthand" syntax has been this way from the start, and has always been troublesome. Currently args+values are processed and treated as flag args until the first one that doesn't match

(-[dhknprstv]|--(detached|help|kill|npm|print|reattach|shellless|transpose|version))

(or one of their values) is encountered. At that point, tmex checks whether that first non-matching arg is a valid layout, uses it as layout if so, and the rest of the args are treated as shell commands to execute.

There seemed to be some ambiguity with a shorthand layout mixed in with other flag args – is it a shorthand layout, or an arg value? But looking at your cases above, I think it could be made to work. I'll take a look at updating the script to handle all of those. Thanks!

[evnp]

Hey @vaygr, I've made this update in https://github.com/evnp/tmex/commit/c402fbc7e226e8c2bafa8fde5ed347d301549fb9, released at v2.0.0-rc.2. Let me know if that seems to work as expected.

Disregard this part if you're not installing via npm – the v2.0.0-rc.2 version seemed to break rendering of the readme at https://www.npmjs.com/package/tmex 🤔 I published v1.0.11 instead and tagged v2.0.0-rc.2 as "next" which fixed it, and feels more correct anyway. If you're installing that way, please use npm install -g tmex@next and you should get the latest.

[movy]

@evnp , I tested new window feature, and it seems to fail creating windows when using iTerm tmux integration.

Below is the result of running the following command from README: tmex your-session-name --window abc 123 -w efg 44

As you can see, tmex/tmux/iterm packed all panes into the same window/tab. Do you have MacOS to test this scenario?

Thanks heaps for your support.

[evnp]

Hi @movy, sorry about the delay getting back, been in the middle of some travel.

Thanks for the report, that's very odd. I get the correct behavior when running

tmex your-session-name --window abc 123 -w efg 44

on my OSX laptop, with 2 tmux windows produced.

Can you try running the command with the --print option and let me know what it outputs? Here's mine for reference:

$ tmex your-session-name --print --window abc 123 -w efg 44
new-session -s your-session-name ; rename-window abc ; split-window -h -l67% ; split-window -h -l50% ; select-pane -L ; select-pane -L ; select-pane -R ; split-window -v -l50% ; select-pane -R ; split-window -v -l67% ; split-window -v -l50% ; new-window -n efg ; split-window -h -l50% ; select-pane -L ; split-window -v -l50% ; select-pane -U ; split-window -v -l50% ; select-pane -D ; split-window -v -l50% ; select-pane -R ; split-window -v -l50% ; select-pane -U ; split-window -v -l50% ; select-pane -D ; split-window -v -l50%

It would also be useful to know if you get the same behavior when running the command produced by the above with "tmux" pre-pended, eg.

$ tmux new-session -s your-session-name ; rename-window abc ; split-window -h -l67% ; split-window -h -l50% ; select-pane -L ; select-pane -L ; select-pane -R ; split-window -v -l50% ; select-pane -R ; split-window -v -l67% ; split-window -v -l50% ; new-window -n efg ; split-window -h -l50% ; select-pane -L ; split-window -v -l50% ; select-pane -U ; split-window -v -l50% ; select-pane -D ; split-window -v -l50% ; select-pane -R ; split-window -v -l50% ; select-pane -U ; split-window -v -l50% ; select-pane -D ; split-window -v -l50%

(this should have the same behavior as tmex your-session-name --window abc 123 -w efg 44)

Finally, it would be good to know these versions, I'm wondering if an earlier version of tmux behaves differently.

$ tmux -V
tmux 3.3a
$ tmex -v
tmex 2.0.0-rc.4

[movy]

Thanks for your response. I've got the same versions installed: $ tmux -V tmux 3.3a $ tmex -v tmex 2.0.0-rc.4

But I guess I begin to understand the problem: I use iTerm with tmux integration, i.e. new tmux tab = iterm window split and new tmux window = new iTerm tab (i.e. native MacOS tab within iTerm window). In addition, I work mostly remotely, and iTerm tmux integration is pure magic for remote work.

Now, whenever I run tmex your-session-name --window abc 123 -w efg 44 locally I do get two tmux windows (not native windows or tabs), but whenever I run tmex remotely, it always spawns all tabs within the same tmux window (i.e. within the same iTerm tab). I'm not certain whether this can be solved, as this rabbit hole seems a little too deep already.

Nevertheless, I'm very happy with existing tmex functionality where I can split a window into number of tmux tabs with a single command, and the lack of window spawning from within iTerm is just a minor nuisance.

[evnp]

Appreciate the details @movy. It's taken me a while to find the bandwidth to properly understand iterm2's tmux integration, but I have a decent repro now. Will be poking at this and hopefully have some improvements to the behavior soon.

Glad to hear the tool is still useful despite this! but definitely a use-case I'd like to work well if possible.

[evnp]

Hey @movy, I've published https://github.com/evnp/tmex/releases/tag/v2.0.0-rc.5 which attempts to fix this set of issues. Curious to hear whether it does the job in your workflows.

I'll be working on updating the tests, docs, and fixing one issue between this and the --npm set of functionality. But wanted to get this in front of you without too much delay to make sure the direction seems right. Thanks for your feedback!

[movy]

This is great! Just tested with basic tmex --window abc 123 -w efg 44 and seems to be working fine! Will update my npm scripts and test in production later today. Thanks heaps for the prompt update!

[evnp]

(at long last) I've released v2.0.0-rc.8 which intends to cover this functionality. This will become a 2.0.0 release in around a week. Please let me know if you come across any issues or changes needed in the meantime. Thanks!