15 ms·

Pymux: a tmux clone in pure Python

157 points by amjith 11y ago

melted 11y ago
What for? What benefits does the use of Python confer in this case?
- bagrow 11y ago
  This is discussed in the readme. One point: > The big advantage of using Python and prompt_toolkit is that the implementation of new features becomes very easy.
  - gkya 11y ago
    What new features are necessary in tmux? Isn't it enough to be able to split, and connect/disconnect to a session?
- paulddraper 11y ago
  README.md is a good place to check: Compared to tmux To some extend, pymux is a clone of tmux. This means that all the default shortcuts are the same; the commands are the same or very similar, and even a simple configuration file could be the same. (There are some small incompatibilities.) However, we definitely don't intend to create a fully compatible clone. Right now, only a subset of the command options that tmux provides are supported. Pymux implements a few improvements over tmux: There is a completion menu for the command line. (At the bottom of the screen.) The command line has fish-style suggestions. Both Emacs and Vi key bindings for the command line and copy buffer are well developed, thanks to all the effort we have put earlier in prompt_toolkit. Search in the copy buffer is highlighted while searching. Every pane has its own titlebar. When several clients are attached to the same session, each client can watch a different window. When clients are watching different windows, every client uses the full terminal size. Support for 24bit true color. (Disabled by default: not all terminals support it. Use the --truecolor option at startup or during attach in order to enable it.) About the performance: Tmux is written in C, which is obviously faster than Python. This is noticeable when applications generate a lot of output. Where tmux is able to give fast real-time output for, for instance find / or yes, pymux will process the output slightly slower, and in this case render the output only a few times per second to the terminal. Usually, this should not be an issue. If it is, Pypy should provide a significant speedup. The big advantage of using Python and prompt_toolkit is that the implementation of new features becomes very easy.
  - melted 11y ago
    That doesn't answer the question though. Why not just add all (or some) of the aforementioned stuff to tmux? Tmux is an established, widely used piece of software. Any improvements would be much more appreciated there.
    - ymse 11y ago
      You could say the same about screen vs tmux (or endless other software clones). Projects like these help drive innovation on both sides. Competition, if you like. Besides, Pymux is Python while tmux is C. I'm sure you can appreciate that adding a Python API to tmux would be non-trivial, both code-wise and politically.
      - JustSomeNobody 11y ago
        But what's the innovation? Adding the python API?
        toolz 11y ago
        Not everything has to innovate. I understand it would be more useful to you and I if it did innovate, but there isn't some prereq for posting to hacker news that your project has to be innovative. I personally find this project interesting to see, although I won't be using it.
        JustSomeNobody 11y ago
        The comment I was replying to specifically mentioned it.
        hueving 11y ago
        Spend the 30 seconds required to read the ancestor comment explaining what it has enabled WRT prompt toolkit.
        11y ago
- _pmf_ 11y ago
  Extensibility via Python scripts instead of custom config syntax maybe?
  - melted 11y ago
    Well that seems to be of very marginal utility to me, but I concede that it might be a much bigger deal for others.
    - emidln 11y ago
      It's probably not even that hard to embed the CPython interpreter into tmux and allow extensions written in python. If you just wanted to write python extension modules, embedding Python and then wrapping the tmux api with Python using cffi is likely a winner.
- JulianWasTaken 11y ago
  This is a frequent and IMHO mostly weird question. I understand the "why reimplement XYZ in $YOURFAVORITELANGUAGE just to have XYZ in $YOURFAVORITELANGUAGE" sentiment but there is an equally valid benefit in using uniform tool stacks. I am a Python developer. I am comfortable working in other languages, and contributing patches to tools written in other languages, but there is a real benefit to having a full toolset written in a single language even if some of those tools are less developed than their counterparts. This is besides the benefit that even though you might not need tmux in Python, having tmux in Python might have created tmux-the-library which someone might later need. (I haven't yet tried this but I plan on doing so. On an unrelated note, thanks to the author for making this pure Python, and for caveatting "it's not as fast as C" with "but try PyPy").
  - JustSomeNobody 11y ago
    Not sure I quite get what the benefit is in having all my tools in one language.
    - JulianWasTaken 11y ago
      Here's a decent start of a more elaborated explanation: http://pyvideo.org/video/83/djangocon-2011--keynote---glyph-lefkowitz http://pyvideo.org/video/83/djangocon-2011--keynote---glyph-...
- jodrellblank 11y ago
  From the link: Just like pyvim (A Vi clone in Python.), this is another experiment. A hobby project
jonathan_s 11y ago
(author). This is the first release of Pymux. It should be stable and usable for daily work. However, don't hesitate to create a GitHub issue in case you feel that it lacks some features/responsitivity or when you'd like to see something different. Expect to see more progress in the coming months. Jonathan
- ihsw 11y ago
  I'm not at all familiar with Python enough to know the answer to this question -- why are there no unit tests for Pymux?
- rogerbinns 11y ago
  Three things I care about are byobu, mouse support and tabs. Being able to make byobu use this instead would make adoption really easy. Hopefully just documentation and changing one byobu setting for a different binary name somewhere. Tmux has mouse support but it seems to require config settings (ie doesn't happen by default). I'd rather mouse stuff just works out of the box with no configuration and does the right thing. I like tabs in the terminal (eg Gnome-Terminal on Linux). I believe there is a Mac term emulator that can map the different screens to tabs. Byobu does help a lot with this, but it would be nice if the terminal can do so too. Thanks for allowing different viewers to see different screens at the same time. tmux's behaviour of making every viewer see the same one at the same time is highly annoying. (Yes I know there are ponderous workarounds, but seriously?)
  - avn2109 11y ago
    +1 for out-of-box mouse event support. This would be the killer feature for me. Right now, configuring pass-through mouse events in Tmux on a Mac is a huge production. StackOverflow has conflicting advice for each permutation of OSX version + Tmux version, and a lot of stuff changed in the last couple versions of each, such that old advice is entirely useless.
- rlpb 11y ago
  I'd love to see the ability to attach a GUI terminal with tighter integration. I use GNOME Terminal, for example, and when connecting to a multiplexer I'd like every screen to appear as a tab, with the ability to detach again later. I believe iterm2 does this, but it is OS X only. This is the only thing I currently miss with screen/tmux/byobu.
otiger 11y ago
Does it or will it support 24bit / True Color terminals? This is the only feature I miss with Tmux since I've been using Neovim with 24bit colors for a while.
- ossreality 11y ago
  There are multiple patches for tmux floating around. One of them is even correct, if you want 24bit tmux. My arch and nix machines are both running it.
  - otiger 11y ago
    I saw this patch but was a bit reluctant to use it. Was it easy to patch and what if Tmux is updated to a newer version?
    - xvilka 11y ago
      You can see the progress of pull request here https://github.com/tmux/tmux/pull/112 https://github.com/tmux/tmux/pull/112
- jonathan_s 11y ago
  Yes, it does support true color. It's disabled by default, because not all terminals support it, but if you want 24bit, do: pymux --truecolor
  - xvilka 11y ago
    Thanks, added in my summary gist https://gist.github.com/XVilka/8346728#terminal-multiplexers https://gist.github.com/XVilka/8346728#terminal-multiplexers
martanne 11y ago
I'm all for experimenting with new ideas, however this seems to duplicate all the conceptual shortcomings I see in tmux. First of all, session support and terminal multiplexing are two distinct features which shouldn't be intermingled. What ever happened to the Unix principle of doing one thing and doing it well? My take on this problem is a combination of abduco[1] and dvtm[2]. Next a built in copy mode seems wrong, there is no need to implement vi(m) or emacs key bindings when you can make use of the complete editor. That is why dvtm uses my vim clone vis[3] as a filter: the terminal (scroll back) content is piped to $EDITOR and whatever the editor writes to stdout is kept in a register to be pasted in other terminal windows. Furthermore I think the completion menu should also be implemented as a standalone tool (using e.g. dmenu or slmenu) as is done for the vis file open dialog. As a last point I consider Pyhton not really suitable for core system tools, if you want something more expressible than C then something like Rust would probably have been a better choice. [1] https://github.com/martanne/abduco https://github.com/martanne/abduco [2] https://github.com/martanne/dvtm https://github.com/martanne/dvtm [3] https://github.com/martanne/vis https://github.com/martanne/vis
- winestock 11y ago
  >What ever happened to the Unix principle of doing one thing and doing it well? Rob Pike has the answer for you. http://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds http://interviews.slashdot.org/story/04/10/18/1153211/rob-pi... A Slashdot user named sczimme asked Pike this question: Given the nature of current operating systems and applications, do you think the idea of "one tool doing one job well" has been abandoned? If so, do you think a return to this model would help bring some innovation back to software development? Rob Pike's reply was: Those days are dead and gone and the eulogy was delivered by Perl.
  - dwc 11y ago
    The ideas are still useful today, surprisingly often, despite Pike's quote.
  - jeff_marshall 11y ago
    I think there is still some nuance available. Perl is great for succinct syntax, which is something I admire (who doesn't appreciate backtick for invoking another program?) This same brevity is valuable in other contexts, but the challenge is in doing it and understanding the implications. So long as such mechanisms don't introduce hidden complexity (e.g. ';' in bash or it's equivalent), succint syntax has my vote. Working in C at a low level and still having to deal with integer overflow shows me that there is definately a middle ground w.r.t. expressivity and details. I'd be happy to see progress in this area.
mitchtbaum 11y ago
Can you save an environment like with https://github.com/tmux-plugins/tmux-resurrect https://github.com/tmux-plugins/tmux-resurrect ?
effenponderousa 11y ago
There are way too many negative remarks about this project. It took a lot of effort to share this project with the world. Presenting alternatives projects and arguments against pymux is a direct assault on everything good about open source, python, and our hacker news community.
- wrenky 11y ago
  Presenting alternatives is a pretty open source idea, no? Thats exactly what this project is doing for tmux! Its not an attack but a discussion point.

157 points by amjith 11y ago

melted 11y ago

What for? What benefits does the use of Python confer in this case?

bagrow 11y ago
This is discussed in the readme. One point: > The big advantage of using Python and prompt_toolkit is that the implementation of new features becomes very easy.
- gkya 11y ago
  What new features are necessary in tmux? Isn't it enough to be able to split, and connect/disconnect to a session?
paulddraper 11y ago
README.md is a good place to check: Compared to tmux To some extend, pymux is a clone of tmux. This means that all the default shortcuts are the same; the commands are the same or very similar, and even a simple configuration file could be the same. (There are some small incompatibilities.) However, we definitely don't intend to create a fully compatible clone. Right now, only a subset of the command options that tmux provides are supported. Pymux implements a few improvements over tmux: There is a completion menu for the command line. (At the bottom of the screen.) The command line has fish-style suggestions. Both Emacs and Vi key bindings for the command line and copy buffer are well developed, thanks to all the effort we have put earlier in prompt_toolkit. Search in the copy buffer is highlighted while searching. Every pane has its own titlebar. When several clients are attached to the same session, each client can watch a different window. When clients are watching different windows, every client uses the full terminal size. Support for 24bit true color. (Disabled by default: not all terminals support it. Use the --truecolor option at startup or during attach in order to enable it.) About the performance: Tmux is written in C, which is obviously faster than Python. This is noticeable when applications generate a lot of output. Where tmux is able to give fast real-time output for, for instance find / or yes, pymux will process the output slightly slower, and in this case render the output only a few times per second to the terminal. Usually, this should not be an issue. If it is, Pypy should provide a significant speedup. The big advantage of using Python and prompt_toolkit is that the implementation of new features becomes very easy.
- melted 11y ago
  That doesn't answer the question though. Why not just add all (or some) of the aforementioned stuff to tmux? Tmux is an established, widely used piece of software. Any improvements would be much more appreciated there.
  - ymse 11y ago
    You could say the same about screen vs tmux (or endless other software clones). Projects like these help drive innovation on both sides. Competition, if you like. Besides, Pymux is Python while tmux is C. I'm sure you can appreciate that adding a Python API to tmux would be non-trivial, both code-wise and politically.
    - JustSomeNobody 11y ago
      But what's the innovation? Adding the python API?
      - toolz 11y ago
        Not everything has to innovate. I understand it would be more useful to you and I if it did innovate, but there isn't some prereq for posting to hacker news that your project has to be innovative. I personally find this project interesting to see, although I won't be using it.
        JustSomeNobody 11y ago
        The comment I was replying to specifically mentioned it.
        hueving 11y ago
        Spend the 30 seconds required to read the ancestor comment explaining what it has enabled WRT prompt toolkit.
      - 11y ago
_pmf_ 11y ago
Extensibility via Python scripts instead of custom config syntax maybe?
- melted 11y ago
  Well that seems to be of very marginal utility to me, but I concede that it might be a much bigger deal for others.
  - emidln 11y ago
    It's probably not even that hard to embed the CPython interpreter into tmux and allow extensions written in python. If you just wanted to write python extension modules, embedding Python and then wrapping the tmux api with Python using cffi is likely a winner.
JulianWasTaken 11y ago
This is a frequent and IMHO mostly weird question. I understand the "why reimplement XYZ in $YOURFAVORITELANGUAGE just to have XYZ in $YOURFAVORITELANGUAGE" sentiment but there is an equally valid benefit in using uniform tool stacks. I am a Python developer. I am comfortable working in other languages, and contributing patches to tools written in other languages, but there is a real benefit to having a full toolset written in a single language even if some of those tools are less developed than their counterparts. This is besides the benefit that even though you might not need tmux in Python, having tmux in Python might have created tmux-the-library which someone might later need. (I haven't yet tried this but I plan on doing so. On an unrelated note, thanks to the author for making this pure Python, and for caveatting "it's not as fast as C" with "but try PyPy").
- JustSomeNobody 11y ago
  Not sure I quite get what the benefit is in having all my tools in one language.
  - JulianWasTaken 11y ago
    Here's a decent start of a more elaborated explanation: http://pyvideo.org/video/83/djangocon-2011--keynote---glyph-lefkowitz http://pyvideo.org/video/83/djangocon-2011--keynote---glyph-...
jodrellblank 11y ago
From the link: Just like pyvim (A Vi clone in Python.), this is another experiment. A hobby project

jonathan_s 11y ago

(author). This is the first release of Pymux. It should be stable and usable for daily work. However, don't hesitate to create a GitHub issue in case you feel that it lacks some features/responsitivity or when you'd like to see something different. Expect to see more progress in the coming months. Jonathan

ihsw 11y ago
I'm not at all familiar with Python enough to know the answer to this question -- why are there no unit tests for Pymux?
rogerbinns 11y ago
Three things I care about are byobu, mouse support and tabs. Being able to make byobu use this instead would make adoption really easy. Hopefully just documentation and changing one byobu setting for a different binary name somewhere. Tmux has mouse support but it seems to require config settings (ie doesn't happen by default). I'd rather mouse stuff just works out of the box with no configuration and does the right thing. I like tabs in the terminal (eg Gnome-Terminal on Linux). I believe there is a Mac term emulator that can map the different screens to tabs. Byobu does help a lot with this, but it would be nice if the terminal can do so too. Thanks for allowing different viewers to see different screens at the same time. tmux's behaviour of making every viewer see the same one at the same time is highly annoying. (Yes I know there are ponderous workarounds, but seriously?)
- avn2109 11y ago
  +1 for out-of-box mouse event support. This would be the killer feature for me. Right now, configuring pass-through mouse events in Tmux on a Mac is a huge production. StackOverflow has conflicting advice for each permutation of OSX version + Tmux version, and a lot of stuff changed in the last couple versions of each, such that old advice is entirely useless.
rlpb 11y ago
I'd love to see the ability to attach a GUI terminal with tighter integration. I use GNOME Terminal, for example, and when connecting to a multiplexer I'd like every screen to appear as a tab, with the ability to detach again later. I believe iterm2 does this, but it is OS X only. This is the only thing I currently miss with screen/tmux/byobu.

otiger 11y ago

Does it or will it support 24bit / True Color terminals? This is the only feature I miss with Tmux since I've been using Neovim with 24bit colors for a while.

ossreality 11y ago
There are multiple patches for tmux floating around. One of them is even correct, if you want 24bit tmux. My arch and nix machines are both running it.
- otiger 11y ago
  I saw this patch but was a bit reluctant to use it. Was it easy to patch and what if Tmux is updated to a newer version?
  - xvilka 11y ago
    You can see the progress of pull request here https://github.com/tmux/tmux/pull/112 https://github.com/tmux/tmux/pull/112
jonathan_s 11y ago
Yes, it does support true color. It's disabled by default, because not all terminals support it, but if you want 24bit, do: pymux --truecolor
- xvilka 11y ago
  Thanks, added in my summary gist https://gist.github.com/XVilka/8346728#terminal-multiplexers https://gist.github.com/XVilka/8346728#terminal-multiplexers

martanne 11y ago

I'm all for experimenting with new ideas, however this seems to duplicate all the conceptual shortcomings I see in tmux. First of all, session support and terminal multiplexing are two distinct features which shouldn't be intermingled. What ever happened to the Unix principle of doing one thing and doing it well? My take on this problem is a combination of abduco[1] and dvtm[2]. Next a built in copy mode seems wrong, there is no need to implement vi(m) or emacs key bindings when you can make use of the complete editor. That is why dvtm uses my vim clone vis[3] as a filter: the terminal (scroll back) content is piped to $EDITOR and whatever the editor writes to stdout is kept in a register to be pasted in other terminal windows. Furthermore I think the completion menu should also be implemented as a standalone tool (using e.g. dmenu or slmenu) as is done for the vis file open dialog. As a last point I consider Pyhton not really suitable for core system tools, if you want something more expressible than C then something like Rust would probably have been a better choice. [1] https://github.com/martanne/abduco https://github.com/martanne/abduco [2] https://github.com/martanne/dvtm https://github.com/martanne/dvtm [3] https://github.com/martanne/vis https://github.com/martanne/vis

winestock 11y ago
>What ever happened to the Unix principle of doing one thing and doing it well? Rob Pike has the answer for you. http://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds http://interviews.slashdot.org/story/04/10/18/1153211/rob-pi... A Slashdot user named sczimme asked Pike this question: Given the nature of current operating systems and applications, do you think the idea of "one tool doing one job well" has been abandoned? If so, do you think a return to this model would help bring some innovation back to software development? Rob Pike's reply was: Those days are dead and gone and the eulogy was delivered by Perl.
- dwc 11y ago
  The ideas are still useful today, surprisingly often, despite Pike's quote.
- jeff_marshall 11y ago
  I think there is still some nuance available. Perl is great for succinct syntax, which is something I admire (who doesn't appreciate backtick for invoking another program?) This same brevity is valuable in other contexts, but the challenge is in doing it and understanding the implications. So long as such mechanisms don't introduce hidden complexity (e.g. ';' in bash or it's equivalent), succint syntax has my vote. Working in C at a low level and still having to deal with integer overflow shows me that there is definately a middle ground w.r.t. expressivity and details. I'd be happy to see progress in this area.

mitchtbaum 11y ago

Can you save an environment like with https://github.com/tmux-plugins/tmux-resurrect https://github.com/tmux-plugins/tmux-resurrect ?

effenponderousa 11y ago

There are way too many negative remarks about this project. It took a lot of effort to share this project with the world. Presenting alternatives projects and arguments against pymux is a direct assault on everything good about open source, python, and our hacker news community.

wrenky 11y ago
Presenting alternatives is a pretty open source idea, no? Thats exactly what this project is doing for tmux! Its not an attack but a discussion point.