4 ms·

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 lik

by 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.
- gnuvince 11y ago
  Look at the list of features that pymux has that tmux doesn't.
  - JustSomeNobody 11y ago
    That's innovative? Ok, for some loose def of innovation.
    - ta0967 11y ago
      you seem to have confused innovation with invention. but that's beside the point. you seem to think that software needs to be either to deserve existance. looks like you're in the minority with that opinion, the rest of us is quite happy with iterative, gradual improvement. we consider it better than sticking with whatever the first shot at an implementation managed to hit.
DannoHung 11y ago
In my experience, Screen is a crashy piece of garbage. tmux is comparatively rock solid.
git-pull 11y ago
Author of tmuxp here, a python API and config manager on top of tmux(1). You can see the quickstart at https://tmuxp.readthedocs.org/en/latest/quickstart_python.html https://tmuxp.readthedocs.org/en/latest/quickstart_python.ht... and the API documentation at https://tmuxp.readthedocs.org/en/latest/api.html https://tmuxp.readthedocs.org/en/latest/api.html. You can see the testcases we cover use real tmux sessions and monitor the state of the session / window / panes to assert the API functions correctly. https://github.com/tony/tmuxp/tree/master/tmuxp/testsuite https://github.com/tony/tmuxp/tree/master/tmuxp/testsuite As for pymux, Jonathan Slenders' work on ptpython [1] and prompt_toolkit have been quite nice when working with shell_plus in django or debugging python projects. He's good in this area. Agreed that it's a nice thing to have pymux there. And agreed that adding native language extensions (python, ruby, etc.) to tmux would be complicated code-wise and perhaps not in the spirit of what it aspires to be. That said, on the tmuxp side of things, a lot could be improved. For example, switching tmuxp to use control mode (-C) and filing smaller patches to expand control mode's events in tmux(1). [1] https://github.com/jonathanslenders/ptpython https://github.com/jonathanslenders/ptpython

by ymse 11y ago

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.
gnuvince 11y ago
Look at the list of features that pymux has that tmux doesn't.
- JustSomeNobody 11y ago
  That's innovative? Ok, for some loose def of innovation.
  - ta0967 11y ago
    you seem to have confused innovation with invention. but that's beside the point. you seem to think that software needs to be either to deserve existance. looks like you're in the minority with that opinion, the rest of us is quite happy with iterative, gradual improvement. we consider it better than sticking with whatever the first shot at an implementation managed to hit.

DannoHung 11y ago

In my experience, Screen is a crashy piece of garbage. tmux is comparatively rock solid.

git-pull 11y ago

Author of tmuxp here, a python API and config manager on top of tmux(1). You can see the quickstart at https://tmuxp.readthedocs.org/en/latest/quickstart_python.html https://tmuxp.readthedocs.org/en/latest/quickstart_python.ht... and the API documentation at https://tmuxp.readthedocs.org/en/latest/api.html https://tmuxp.readthedocs.org/en/latest/api.html. You can see the testcases we cover use real tmux sessions and monitor the state of the session / window / panes to assert the API functions correctly. https://github.com/tony/tmuxp/tree/master/tmuxp/testsuite https://github.com/tony/tmuxp/tree/master/tmuxp/testsuite As for pymux, Jonathan Slenders' work on ptpython [1] and prompt_toolkit have been quite nice when working with shell_plus in django or debugging python projects. He's good in this area. Agreed that it's a nice thing to have pymux there. And agreed that adding native language extensions (python, ruby, etc.) to tmux would be complicated code-wise and perhaps not in the spirit of what it aspires to be. That said, on the tmuxp side of things, a lot could be improved. For example, switching tmuxp to use control mode (-C) and filing smaller patches to expand control mode's events in tmux(1). [1] https://github.com/jonathanslenders/ptpython https://github.com/jonathanslenders/ptpython