On Fri, Nov 05, 2010 at 06:38:43PM -0700, George Nachman wrote: > 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?
Yes, there is no state in the client aside from some very minor stuff like exit message. In early versions the client did much more but this is much slower and harder to maintain (dozens of messages, and serious hassle doing stuff like switching client to a new session). > 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 the biggest problem will not be making things happen in tmux but in getting information OUT of tmux - once a client is attached, all output goes directly to the tty, it doesn't go via the client. There is no mechanism for the server to asynchronously tell the client about events. 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. 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. 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. 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. 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. > > 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. Hmm, could work. Sounds awfully fiddly. If you're worried about depending on internal tmux protocol version I'd be even more worried about trying to parse what it sends to the tty... > > 2) Act as a dumb client. The server would control iTerm2, telling to > open and close windows, move the scrollbar, etc. This would go back to requiring an extended client flag and tmux to support a whole bunch of trigger commands to make stuff happen. > > 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). Server is responsible for everything. I'm abroad on holiday from about 30 minutes time so I'll reply to any further mail when I get back on Thursday. Cheers > > > 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
