Author of tmuxp [1], a session manager also in Python.

I like the project. I consider it more in the "different" category as opposed to "better".

> Other tmux session managers require pages of documentation for basic use,

http://tmuxp.readthedocs.org/en/latest/quickstart.html

> and define windows using a complicated nesting of pane splits.

http://tmuxp.readthedocs.org/en/latest/examples.html

The syntax for tmuxp was heavily inspired by tmuxinator and teamocil.

Normally, window layouts in tmux don't get too fancy.

> tmuxomatic is so easy that anyone could use it after just one example.

I think the idea has potential - already being used to using teamocil/tmuxinator configs, it feel its a tad unorthodox at first.

I don't see what benefit it gives over constructing the tmux via your client and saving the layout. The `tmuxp freeze` command exists for this.

> Yet tmuxomatic is more flexible and more powerful than other tmux session managers.

http://tmuxp.readthedocs.org/en/latest/quickstart_python.htm... + http://tmuxp.readthedocs.org/en/latest/api.html

You can't get more powerful and flexible than having an API that basically runs at a parity to tmux's data model and commands.

That said, anything that spreads the word about tmux and makes it easier for people to use is a good thing. I think the real pain point in CLI is even with modern (neo)vim/emacs, we don't have anything close to an Atom or Intellij suite for "just works" completion. If you've had better luck with completion - I'm happy for you.

[1] https://github.com/tony/tmuxp

Hi, author of tmuxomatic here.

My personal use of tmux includes windows with 10+ panes. It's not easy to define these layouts using other means, and often making simple modifications is a big hassle.

I didn't want to be an expert in tmux to maximize my use of it. I wanted something so simple and intuitive that documentation is virtually unnecessary.

For those who only ever use simple 1 or 2 split layouts, a traditional manager may suffice. But even in these cases, tmuxomatic is much easier to deal with. Definitions in tmuxomatic are readable at-a-glance, and the flexibility afforded by windowgrams make layouts clear and unambiguous.

As for the tedium of ASCII, there's the Flex command set that's being added to tmuxomatic 2.x. Using a handful of basic commands, virtually any layout is possible without doing any ASCII art at all.

I'd say this qualifies as better.

Of course it's different, it has to be.

I like the idea here, but I don't really see how drawing ASCII art is easier than running:

    tmux list-windows

I do agree that it's nicer to read the ASCII art version, but making edits seems like effort. The list-windows syntax isn't fun to look at, but it's simple to manually make changes to the current layout and export it in the native tmux syntax.

Further down the page is a mention of Flex, which was designed to address the concerns you mention:

    "Windowgrams are a neat way of arranging workspaces. For simpler
    layouts, a windowgram can be typed up quickly. But if you need
    detail, you may find yourself doing a lot of ASCII art.

    In tmuxomatic 2.x, flex was added to automate the construction and
    modification of the windowgram itself.

    Flex is an object-oriented windowgram editor. It is visually
    expressive, naturally worded, logically ordered, minimal, and
    powerful. Its short command set may be combined to make any
    conceivable windowgram -- likely more quickly and more easily than
    crafting by hand. Flex is intended for power users who desire
    detailed windowgrams without the tedium of manual entry."

There are some examples further on of how quick and easy it is to use flex for edits.

Looks neat.

Is there any way to load a layout from tmuxinator, modify the layout in tmux itself, and then save the modified layout back to the tmuxinator windowgram? As long as I haven't deleted/removed panes from the layout, it seems like tmuxinator could figure out the modifications I made.

You probably meant tmuxomatic, not tmuxinator.

What you describe are the "synchronization features" that are planned for a future version. I'd like this to be a real-time synchronization between the tmux session and the tmuxomatic session file, a change to one will update the other.

Development for 2.x is centered around Flex. Look for synchronization (in whatever form) in 3.x or 4.x.

Oops, yeah, I did. And glad to hear it!

Cool project but this comment seemed like a late April Fools joke. "Other tmux session managers require pages of documentation for basic use" Um... I spent all of 2 minutes reading Tmuxinator's Gtihub readme and then set it up. The same amount of time reading this readme had me scratching my head.

It's intended for non-trivial layouts.

To contrast, take a look at the configuration files for some simple layouts in another popular session manager: http://tmuxp.readthedocs.org/en/latest/examples.html

The same layouts in tmuxomatic are going to be very easy and obvious. Though the unorthodox nature of tmuxomatic may require some getting used to.