Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

github.com

Post reply on HN
Print view View original

81–90 of 111 posts

Re: Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

#81

Post by shadowfax92 »

shadowfax92 wrote: post #80

this might fit very nicely with gascity/gastown which orchestrates other coding agent over tmux. currently, i finds it's tmux orchestration code is too complex. will check it out

> got tired of scraping output with grep and sleeps to automate anything.

curious, what was the usecase here?

Re: Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

#82

Post by gobdovan »

SwellJoe wrote: post #78

It's not clear to me what this does that tmux doesn't? Agents can already interact with tmux, so what does this provide?

  I think it's trying to be like a code-first/API alternative to Tmux. So instead of:
``` tmux new-session -d -s a

tmux send-keys -t a 'npm test' Enter

sleep 2

tmux capture-pane -p -t a ```

  you'd do something like:
``` pane.send_text("npm test\n").await?;

pane.wait_for_text("Tests passed").await?;

let snapshot = pane.snapshot().await?; ```

  I don't know why it would be better for agents, maybe the author also works on an LLM agent harness.

Re: Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

#84

Post by smaudet »

scottyeager wrote: post #68
sroerick wrote: post #60

Earlier quoted context omitted.

I didn't know you could do this with Emacs

It's just too bad Emacs doesn't also include a decent text editor, right?

Eh? Not sure what you mean by that...

Re: Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

#86

Post by pama »

evanjrowley wrote: post #72
pama wrote: post #49

Congrats on the launch. If emacs was unavailable and I needed tmux, I would try it. I am old school, and use emacs daemons for all shell multiplexing. The agents dont need explanations and know how to use emacsclient to create, read, or send inputs to named buffers that run the shells. Elisp is powerful, so manipulating windows is a breeze. Lots of people on tmux would benefit from this design though.

Are there any guides on accomplishing this with Emacs? Perhaps something that might be useful for someone coming from Tmux?

Not sure, tbh. I use emacs -daemon to start a server; emacsclient -nw to connect. I use ssh and start a server on the remote. I spawn multiple shells with infinte buffer size and dumb terminals (M-x shell) so I can seamlessly edit. (These are based on comint, a neat command interpreter.) I use my own hacks for named shells (https://github.com/pjj/Emacs-nsh) and for rearranging/splitting windows, but any of the latest powerful LLMs can help with ergonomic modifications to M-x shell or the various improved terminal emulators (vterm, eat, ansi-term) or with renaming and moving/splitting windows. The Emacs manual is excellent but long; worth it IMHO, but focus on things you use. The tutorial is quick; worth it. I avoid curses programs (fancy TUI) or write wrappers around some of them. I love the -p option in codex/claude/copilot.

Re: Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

#87

Post by shideneyu »

SwellJoe wrote: post #78

It's not clear to me what this does that tmux doesn't? Agents can already interact with tmux, so what does this provide?

gobdovan nailed it. The CLI is a drop-in for existing tmux workflows; the SDK eases your flow when you'd otherwise be writing brittle send-keys + sleep + capture loop. But that's just one one of the use cases. rmux should be used to make beautiful TUI, something very dirty to do with tmux. Especially the day you want to do integration testing (playwright style)

Re: Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

#88

Post by shideneyu »

shadowfax92 wrote: post #81
shadowfax92 wrote: post #80

this might fit very nicely with gascity/gastown which orchestrates other coding agent over tmux. currently, i finds it's tmux orchestration code is too complex. will check it out

> got tired of scraping output with grep and sleeps to automate anything. curious, what was the usecase here?

Hehe. I am building a multi agent orchestration system of course ;) I believe this is the future, agents speaking to one each other. It's very dirty with tmux

Re: Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

#89

Post by shideneyu »

qudat wrote: post #47
cultofmetatron wrote: post #10

a week ago I was using cmux but its osx only and doen't work on remote terminals. then I switched to herdr which is great so far except its not s great at managing panes. I can't move them around or change ordering. now another terminal multiplexer. I'm getting whiplash. all that said, none of the existing solutions are perfect and rust codebases are nice. how easy is it to reorder panes? is there a cli that lets me…

I built https://zmx.sh to make it easier to interact with your terminal sessions programmatically. 1 window = 1 session which might feel like a negative but it makes programmatic access easy and agents can use it just by pointing it at the zmx help command. Basically, an agent just needs 2 commands (run and write) for full control and the commands are synchronous so you don’t need to do any polling.

nice, zmx is a very nice approach. I did not want to take risks and change the expected behavior of the renown tmux. My main goal was 1) to rewrite tmux the modern way more elegantly (async, rust) and give it windows support 2) to give it a SDK. I think 1 window = 1 session is the right way, but it's a risky market move I didn't want to tackle for adoption. Maybe on a breaking v2 !

Re: Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK

#90

Post by shideneyu »

kloud wrote: post #56
shideneyu wrote: post #53

Earlier quoted context omitted.

I thought I was too zealous because I created 11 crates respecting single responsibility principles.. I would have been all in to risk it further and separating responsibilities for session and window management but it would have diverged too much from tmux. I wanted a 1-1 port for now

Fair point, given it is more unconventional design, it is a riskier way in order to get something that works.

correct... it's sad but recognition is a lot. After putting months of efforts, it's a risk I didn't want to take. And following tmux was like a red thread of life to code. Maybe in the future !
Post reply on HN