I guess I'm unclear on where the line is drawn between the tmux client and server. Is all state stored in the server, such as the scrollback buffer?
It may be the case that I have to write my own client, or extend the existing client, which I'm OK with doing. I'd like my terminal emulator to attach to a tmux server and show each session as a tab and generally make the entire session look as much like a non-multiplexed session as possible. I think there are two routes my app could take: 1) iTerm2 would copy the server's state into its memory (but probably not all at once since scrollback buffers can be huge) and do a best effort to keep them in sync. For example, when output is received, we would update our local scrollback buffer, and the server would update its scrollback buffer. There are possible problems here if tmux handles rewrapping of long lines on window resize differently than iTerm2 does. The server would not be responsible for any ongoing rendering, but would just keep its state up-to-date and pass I/O through so that if we detach and reattach later on we can pick up where we left off. 2) Act as a dumb client. The server would control iTerm2, telling to open and close windows, move the scrollbar, etc. For me, option #1 is easier to implement but will probably suffer from falling out of sync in small ways. I can probably live with that. Option #2 would be a big change for me, but perhaps less work on the server side (if I read you correctly, the server is already responsible for rendering). On Fri, Nov 5, 2010 at 6:20 PM, Nicholas Marriott <nicholas.marri...@gmail.com> wrote: > On Fri, Nov 05, 2010 at 05:53:08PM -0700, George Nachman wrote: >> Hi tmux-users, >> >> I'm the maintainer for a terminal emulator on MacOS >> (http://iterm2.googlecode.com) and I am assessing the feasibility of >> adding support for acting as a tmux client to my program. I'm >> intrigued by your client-server interface, which seems to make this >> much more doable than in other terminal multiplexers. As far as I can >> tell this has not been done before and the protocol between the client >> and server is not documented. I'm concerned that the protocol may >> change, breaking backward compatibility, and leaving me playing >> catch-up. Is this a use case the tmux developers would consider >> supporting? > > What kind of thing do you see your terminal emulator doing? > > Basically the tmux client just passes the file descriptors and > environment and a few other bits and pieces to the server and after that > doesn't do much else. The interface for triggering a command just sends > a packed argv and argc. > > If you want to do anything beyond displaying the output it'll probably > need protocol changes. > > The protocol is pretty stable and changes very rarely, and it is > versioned. I do my best to avoid spurious changes and I can't think of > anything upcoming that would need a protocol change. > >> >> Thanks, >> George >> >> ------------------------------------------------------------------------------ >> 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 > ------------------------------------------------------------------------------ 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
