> There are three approaches I can see: > > 1) Protocol changes. This could work, could have a flag to mark this as > an "extended" client that gets additional update messages in various > places. I'd be concerned how invasive this would be though.
Now that I understand your architecture better, it's pretty clear to me that we don't want to write our own client. I want to support the use case of ssh'ing to a remote host and running the tmux client there. > 2) Call tmux commands through the existing client. There is at least one > project I know of that does this already to provide a Ruby API to > tmux. I found the project (tmux-ruby) but not any documentation for it, so it's hard to tell at a glance if it's the right direction. I suspect we want more semantic understanding of the responses than they do, though. > You'd have to poll if you wanted to update your state, and probably > would need some additional commands (eg there is no way to grab the > history at the moment), but those would be easy to add and would have > the side-effect of improving the client interface for everyone. It seems like we would need a framing protocol on top of TCP to talk to each other so we could receive new data from the tty while making and responding to RPCs asynchronously. I think we could live with polling but it's not ideal, as we'd have to poll pretty frequently to appear interactive and people would complain about the bandwidth usage. > At the moment a lot of the output from tmux is a bit ad hoc and would > benefit from a close look for completeness and how easy it is to parse > and once it is done it isn't likely to change much. > > It would be trivial to add simple things (menus of sessions/windows, > option to copy tmux paste buffer to your own etc) with this but for > complex things I don't know. Does tmux keep its own concept of the screen contents, with metadata for each character about color, blink, etc.? I have a feeling managing the scrollback buffer will be the biggest challenge here. > 3) Act as a client and call tmux commands with MSG_COMMAND. Once > attached, responses go to the terminal not back to the client so back to > option (1)... You could maybe open two clients, one to attach and one to > send commands/get responses but that seems like a hack. > This won't work for the same reason I gave for #1. ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
