Session managers like tmuxinator and tmuxp are unnecessarily complex and counter-intuitive. Some people may enjoy configuring tmux sessions with a verbose and structured JSON or YAML files, but I want the session configured as quickly and easily as possible so I can get back to work.
Also, tmuxomatic offers a great deal of flexibility for pane layouts that is unmatched by any other session manager.
I've got 3 hours into wrestling with Ruby versions (1.7 vs newer) and xcode (command line tools),trying to get tmuxinator to work on my Mountain Lion system.
I'm not surprised since managing ruby versions doesn't always go perfectly. I've been using tmuxinator for a while and been very happy. Didn't have any issues installing on OS X/Ubuntu.
Do mention how you like tmuxomatic vs tmuxinator once you get settled in.
I will - I really like the tmuxinator framework, and I'm determined to get it working... A lot of the use cases regarding setting up different environments in tmuxinator is exactly what I've been looking for - will probably save me 4-5 minutes two-three times a day.
This is interesting, although I'll echo the request of YAML.
A neat idea to add to this is using wildcards. For instance, rather than having to write
AAAAABBCCCCCDDDD
you could write
A*BBC*DDDD
or even
A*B2C*D4
where A and C will fill in evenly with each other with whatever room is left over. This would probably work best if you defined how many rows/columns you're using ahead of time, so that each row could take advantage of it.
Going this way, you could have a nice little Python script to check your config, and send a warning message that "this config will output 5 panes, etc etc", or "this config does not have enough sections on row 3".
As it is, some of the current sample configs look daunting. You'd have to check your text editor, or manually count each letter to get an idea for how big a particular pain will be.
Other than that, it looks like an interesting idea. But I'm guessing ease of use is a major selling feature for this. So making it even easier to use would definitely help promote it.
What you suggest will fast become confusing and difficult to follow. It's better to keep layouts in an immediately recognizable form. Also, I've built in a flexible window scaling feature to assist with fine tuning layouts. For example if you create "123", and want to change the "3" into a 2x2 grid, instead of copying lines or retyping the layout, you could just "--scale 1 2x 2x --scale-replace" (assuming window 1), then edit the session file and fill in the details. It also has the ability to down scale. Play around with it and you'll see how helpful it is. Once you get the hang of designing layouts, you may find most general use layouts can be typed up pretty fast.
As mentioned in another comment, there will be support for YAML in version 1.1. I don't know how soon that will be, since I am working on another project right now, but keep an eye on tmuxomatic, it should be soon. Thanks for the feedback!
I don't think YAML is good way to configure a tmux session. But it's popular, and simple to implement, so I may add it. I'll consider it in the next version.
Any reason why you think this? YAML seems like a more intuitive choice for describing the session/window/pane hierarchy IMO. Your "visual" notation does seem useful, but I'm not so sure if the benefits merit taking on a new configuration format in my tools layer.
I'm all for standard file formats where they serve a purpose, but they don't really fit here. The point of tmuxomatic was to completely break away from the structure imposed by tmuxinator, tmuxp, and fundamentally tmux, and deliver something so simple and automated that tmux becomes almost transparent. Where any user, expert or novice, is able to create complex arrangements of practically any conceivable layout so intuitively that documentation is unnecessary.
However, if you prefer to do your editing in an IDE or graphical editor, a known file format is easier to deal with, and syntax highlighting is nice.
I'm not sure it's possible to be more ergonomic while retaining the flexibility that tmuxomatic text-as-layout has to offer. Not with a keyboard anyway.
The next step in tmux usability may be to intercept mouse-as-cursor messages (assuming these exist) and allow a user with a touchscreen to literally draw out the windows. Or some kind of English interface where you verbally describe the window layout. Either one could leverage tmuxomatic for the pane layouts. Both of these are on the tmuxomatic todo list, but there are other projects I'd rather work on.