Very cool project! When I was regularly using a multiplexer on my personal machines, I did something similar with `abduco` [0] for session management and `dvtm` [1] for the actual multiplexing.
This is awesome! I was thinking it would be neat to have something like abduco but on a more reliable foundation, like libghostty-vt.
For my agent management scripts I use zellij since it is more ergonomic than tmux. Abduco sounded good in principle, but implementation is too limited. However, zellij is quite huge in the order of tens of thousands LOC and I am using only small part of it. It looks like zmx might implement just the right amount of features for this use case, I am going to try it. It is always nice to achieve same functionality with leaner tools.
Do you also think about dvtm part alternative? I wonder if once libghostty proper gets finished it would open possibility to level up textual multiplexing and unlock some cool features with graphical UIs.
I was just wondering what is the additional value over just using, tmux and pre-stored pane configurations. From the screenshot in the GitHub repository, I don't see any additional value for me. Will this allow, like, floating panes?
I'm just using tmux with some custom key configurations and with what tmux offers out of the box I'm pretty happy.
For me, personally, the value was in have something similar to a window manager for the terminal. As I was constantly spawning, killing, and reorganizing panes, a tiling-based approach gave me more control over my terminal and allowed me to perform complex operations without having to memorize or execute multiple commands. My use of a terminal is not static and therefore having a more dynamic option made my life easier.
This is really just a personal project that I wanted to share in case others might like to try it.
I will add that, especially at the time of creation, I was heavily in the 'unix is my IDE' camp. A terminal window manager was a logical next step to that notion. As someone called out below, I even used `ed` as my main editor for a while (which was as bad as it sounds).
I'm intrigued - as tmux has been my window manager for my desktop for 10+ years now ( I typically have 80-100 different windows/panes in play by the end of any given week, where I take time to close down all sessions that aren't still in progress).
I'm wondering what the difference is between this and just tmux basic environment - which already has a lot of pane / window management. What's the key distinction between using tmux and dwm.tmux?
<5 minutes later> - Ah - this is just tmux with some custom config. The window manager is tmux - I would suggest changing the title a bit - maybe something like, "DWM.TMUX - dwm inspired tmux configs. "
<Further review - note the "10 years ago" timestamp - ahh.. This has been gestating for a while>
I think the key distinction is the consistent layout (main pane + stack) along with keyboard shortcuts to manage. To me it's similar to running vanilla X{11,org} vs using a window manager (hence the name). A vanilla configuration will work just fine but sometimes a constrained or opinionated environment gets more out of your way and better fits your preferred workflow.
If you already have a robust tmux workflow with a desired layout (or lack of layout) and custom keyboard shortcuts then this may not work for you. It's just one way to manage panes/windows in tmux that I hadn't seen before and different from the usual ad hoc methods.
Like most window managers, I think it's all preference. What're your current preferences for pane layout, window management, etc? Do you always create/layout panes in the same way or is it situationally dependent?
It's not just configs though, as there is some logic implemented via shell that could not be handled entirely in configs. "Window Manager" was chosen as it the logic imposes a specific layout without necessarily preventing you from using other configuration options. It's almost solely layout management and keyboard shortcuts to assist.
This looks intriguing and I'm definitely going to try it out. The clincher? Seeing the possibly gratuitous but ultimately wonderful use of ed in pane 0 in the screenshot.
Interessting.
When I read the title first I was like: "What?"
Well, checking out the code, it seems to be tmux functions. Well, some of them are quite intriguing! I never bothered to figure out how to spawn a new pane in the same dir. Consider that fuction stolen ;)
I would have advertised it diffetently though. Something like "DWM inspired tmux config".
As other have mentioned, I don't sse why I should use "dwm.tmux" over just the tmux defaults, or my own home grown (stolen) config.
Through this project I realized that there's just some limitations to a plain tmux config. I eventually had to switch over to calling out to shell in order to get around those issues.
[0] https://www.brain-dump.org/projects/abduco/
[1] https://github.com/martanne/dvtm
Works pretty well if you don’t need a window manager in your terminal
For my agent management scripts I use zellij since it is more ergonomic than tmux. Abduco sounded good in principle, but implementation is too limited. However, zellij is quite huge in the order of tens of thousands LOC and I am using only small part of it. It looks like zmx might implement just the right amount of features for this use case, I am going to try it. It is always nice to achieve same functionality with leaner tools.
Do you also think about dvtm part alternative? I wonder if once libghostty proper gets finished it would open possibility to level up textual multiplexing and unlock some cool features with graphical UIs.
I was just wondering what is the additional value over just using, tmux and pre-stored pane configurations. From the screenshot in the GitHub repository, I don't see any additional value for me. Will this allow, like, floating panes?
I'm just using tmux with some custom key configurations and with what tmux offers out of the box I'm pretty happy.
This is really just a personal project that I wanted to share in case others might like to try it.
I will add that, especially at the time of creation, I was heavily in the 'unix is my IDE' camp. A terminal window manager was a logical next step to that notion. As someone called out below, I even used `ed` as my main editor for a while (which was as bad as it sounds).
I'm wondering what the difference is between this and just tmux basic environment - which already has a lot of pane / window management. What's the key distinction between using tmux and dwm.tmux?
<5 minutes later> - Ah - this is just tmux with some custom config. The window manager is tmux - I would suggest changing the title a bit - maybe something like, "DWM.TMUX - dwm inspired tmux configs. "
<Further review - note the "10 years ago" timestamp - ahh.. This has been gestating for a while>
If you already have a robust tmux workflow with a desired layout (or lack of layout) and custom keyboard shortcuts then this may not work for you. It's just one way to manage panes/windows in tmux that I hadn't seen before and different from the usual ad hoc methods.
Like most window managers, I think it's all preference. What're your current preferences for pane layout, window management, etc? Do you always create/layout panes in the same way or is it situationally dependent?
Love Floating Panes in Tmux - and best part - all the other plugins - resurrect, continuum, etc..) all support floating panes out of the box.
Do I regret using `ed` as my primary editor? No.
Do I still use `ed` as my primary editor? Absolutely not.
Well, checking out the code, it seems to be tmux functions. Well, some of them are quite intriguing! I never bothered to figure out how to spawn a new pane in the same dir. Consider that fuction stolen ;)
I would have advertised it diffetently though. Something like "DWM inspired tmux config".
As other have mentioned, I don't sse why I should use "dwm.tmux" over just the tmux defaults, or my own home grown (stolen) config.
Non the less, quite interesting code!
Commit with the switch to shell here: https://github.com/saysjonathan/dwm.tmux/commit/c8752b978390...
I think there's a lot of potential to scripting terminal multiplexers in various ways and I would love to see more work exploring what's possible!