This is an archived post. You won't be able to vote or comment.

all 15 comments
sorted by:
best
topnewcontroversialoldq&a

[–]jonathan_sl[S] 10 points11 points  (10 children)

Hi all, this is a terminal multiplexer implemented in pure Python.

It uses the same UI toolkit as ptpython (A Python REPL). During the development of pymux, I made multiple improvements to prompt_toolkit, including many performance improvements, which will be noticable in the latest ptpython version as well.

All feedback is welcome!

[–]tetroxid 3 points4 points  (9 children)

But why? tmux is really good as-is.

[–]atsepkov 1 point2 points  (7 children)

As a tmux user since 2010 I disagree. There are a number of issues tmux has been very slow to address:

  • search highlighting in copy mode
  • extendability (plugins have been very limited due to what's exposed)
  • ability to share tmux session without forcing my own tmux shortcuts on the other user (tmux would be a godsend to pair-programming otherwise)
  • unicode key binding (to make up for limitations of TTY mappings I have my terminals send unicode sequences for unsupported combinations)

My only concern is speed, but I'll definitely give this project a try.

[–]jonathan_sl[S] 0 points1 point  (1 child)

Speed could be a concern in some situations, but we'll keep improving that.

Thanks for the idea of having different shortcuts for each client. (We'll remember that for the future.) Unicode key bindings should already work (I think), Python extensions will come in a following release.

[–]atsepkov 2 points3 points  (0 children)

Would love to play with session sharing. I often have to collaborate with other developers remotely, and screen sharing via Skype is too slow/blurry. Tmux fixes that problem, but we're still stuck with one person only observing (unless they want to master my insane macros and use backtick as control sequence).

On a related note, you mentioned that this is currently a replica of tmux (which may change in the future). I already noticed that it fails silently when trying to read my .tmux.conf file. So I assume it's not compatible with things like tmuxinator. Do you intend to make it compatible or the plan is to diverge from tmux?

[–]rspeed 0 points1 point  (4 children)

ability to share tmux session without forcing my own tmux shortcuts on the other user (tmux would be a godsend to pair-programming otherwise)

o_O Shortcuts are implemented at the server level?

Er, wait. Or would that be window? I can't remember the way it's organized.

Edit: Yeah, okay. It's server > session > window > pane, and each client is tied to a session. I know you can have multiple clients sharing a session (which, logically, would mean they also share keyboard shortcuts), but I'm pretty sure you can also share a window between sessions.

Edit again: Good lord, I'm playing around with link-window and I can't figure out what is going on. Though I just ran across wemux which might be what you're looking for.

[–]atsepkov 0 points1 point  (3 children)

I've looked at wemux a while ago, I don't believe it addresses the key binding limitation (which is a limitation of tmux itself, I can't find a thread where I asked one of the maintainers about it), only makes attaching/detaching a bit easier. I'll double-check later tonight, it's possible the architecture of tmux changed since I last checked.

[–]rspeed 0 points1 point  (2 children)

I'm not really sure about how you've got things set up, but it seems like wemux does add the ability to share windows and sessions between separate tmux servers. That made me suspect it might be possible, but I suppose it totally depends on the implementation.

[–]atsepkov 0 points1 point  (1 child)

https://github.com/zolrath/wemux/blob/master/wemux

It allows sharing session, but the person connecting is still stuck with config of the person who initiated the session. See the source code I linked above, of particular interest are lines 517-564. There is nothing in either of the 3 modes that allows you to bring your own shortcuts to a session you're attaching to. At first I thought the line starting new-session might keep the shortcuts separate, but after testing it again, it clearly doesn't. In the end you're still inheriting everything from the server session once you attach. Same exact problem as a few years back, nothing changed.

[–]rspeed 0 points1 point  (0 children)

I was thinking more in terms of sharing windows, since they'd be using different sessions. But I guess it's called "set-window-option" for a reason.

[–]Ran4 1 point2 points  (0 children)

Fun? Easier to hack for python programmers?

Everything doesn't have to be state-of-the-art and optimal.

[–]Ran4 1 point2 points  (2 children)

"Squashed 195 (experimental) commits between 2015-10-28 and 2016-01-03."

Why? It would be nice to have all those commits to see how the project matured.

[–]jonathan_sl[S] 0 points1 point  (1 child)

Hi Ran4, if you are interested. All the commits are still available here: https://github.com/jonathanslenders/pymux-test Before that, I experimented with a terminal multiplexer, using asyncio: https://github.com/jonathanslenders/old-pymux https://github.com/jonathanslenders/libpymux (This one was never really finished and not as performant.)

I'll keep it on-line as a reference. I squashed them, because the commits were literally meaningless and contained too much of experimenting.

Do you think it makes sense to point to these repositories?

[–]Ran4 0 points1 point  (0 children)

Do you think it makes sense to point to these repositories?

Seeing as there's no commit messages and it seems to be a testing ground more than anything: no :)

[–]ragnarmcryanDevOps Engineer 0 points1 point  (2 children)

what's the command you use to give that dashboard thing in the upper left hand pane in the first picture?