As far as history goes it would be possible for tmux to draw the entire history to a file (or more accurately to a tmux buffer which could then be saved to a file) as escape sequences for one terminal or another (we already need an extension of capture-pane to save the history and there is no reason it couldn't produce escape sequences).
On Sat, Nov 06, 2010 at 05:05:31PM -0700, George Nachman wrote: > > 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
