On Thu, Nov 11, 2010 at 04:15:29PM -0800, George Nachman wrote: > >> That would work. We could actually go all-pull on the protocol and > >> have a blocking "poll for new data" command that I send you, if that > >> makes life any easier. It's all the same from the client's end. > > > > Hmm. It all seems much the same to me, in both cases you will block in > > poll or select until tmux sends some message. Whether you explicitly > > request the message or whether it is just sent doesn't really make much > > difference. > > I take it back, a block call wouldn't work if we decide we want to > send you a message while it's blocking. You should push output to us. > Needless to say, it has to be properly interleaved with command output > so that it can be parsed unambiguously.
tmux is single threaded, it won't be interleaved. > > > > >> > >> >> >> // Returns a single line of text from the nth line of scrollback for > >> >> >> a > >> >> >> given window. A ScreenCell is a struct with a character, foreground > >> >> >> color, background color, etc., representing a single onscreen > >> >> >> character. > >> >> >> vector<ScreenCell> GetScrollbackHistoryInWindow(Window*, int > >> >> >> lineNumber); > >> >> > > >> >> > What would be most likely is that you would request a line from the > >> >> > history and tmux will give you a sequence you can feed into your > >> >> > parser > >> >> > to draw it. > >> >> > >> >> Can you define "sequence"? VT100 escape codes are fine as long as any > >> >> existing state if taken into account. So if line 0 has a code to > >> >> change the foreground color and I request line 1, it must begin with > >> >> the foreground color escape code. > >> > > >> > Probably it will assume an empty terminal of the size of the line and > >> > draw the line into it using whatever terminal description you like (so > >> > long as its on the box running tmux). Then you can render it wherever > >> > you like. > >> > >> This is slightly scary because there's no guarantee at the protocol > >> level that the cursor will only stay on one line, but I understand why > >> it makes sense; not every emulator implements the same subset of the > >> terminal protocol. > > > > Well, we can tell you the length of the line and then send sequences > > limited within that size. > > I'll have to refactor my vt100 parser, but it's certainly doable. > > >> > >> >> > >> >> >> // Notify window of a size change > >> >> >> void ResizeWindow(Window*, int width, int height); > >> >> > > >> >> > You could actually sort of do this already with force-width and > >> >> > force-height options. Basically need to feed your data into the > >> >> > existing > >> >> > maximum window size calculations (resize.c). > >> >> > >> >> This is a little messy given the window/pane feature that tmux has and > >> >> iTerm2 doesn't. For now I'd probably prefer to do something really > >> >> simple like move each pane into its own window when iTerm2 connects > >> >> and then use the existing SIGWINCH functionality, so this API would be > >> >> unnecessary. If two clients are attached to the same server, tmux does > >> >> some presentation work (drawing a "no-man's land" of periods outside > >> >> of the window in the second client). I think tmux would have to change > >> >> its behavior in this mode to not draw those UI elements and just act > >> >> like a window that refuses to resize. > >> > > >> > If you are dealing at the level of panes not windows this won't > >> > matter. Panes are never larger or smaller than the window and contain > >> > nothing except the application, so you can draw whatever you like > >> > outside them. > >> > >> If a window has exactly one pane then the pane resizes along with the > >> window, does it not? Or have I got my terminology wrong? > > > > It does, yes, but in any case you will be limited to the same area as > > the application which is the size of the pane. > > My original point was a client-initiated resize, resulting in a > SIGWINCH, will resize the window, and in turn resize the pane or panes > in that window. So we need to be able to tell you that a window > changed size. But is it possible to change the size of one window and > not another? The GUI will represent each tmux window as a separate > native window, and they can of course be resized independently. Well if each pane is separate then it'll be panes and panes are fixed size. There is no reason we couldn't have a per-window maximum size as well. > > >> > >> >> > >> >> >> > >> >> >> // Close a window > >> >> >> void CloseWindow(Window*); > >> >> >> > >> >> >> > >> >> >> Does this help clear up what I had in mind? > >> >> > > >> >> > I'm thinking the right way to do this would be to decouple the display > >> >> > side of the client stuff a bit (where the client is the client object > >> >> > in > >> >> > the server not the client process). At the moment there are basically > >> >> > a > >> >> > few operations: > >> >> > > >> >> > - Exit (also detach). > >> >> > - Lock. > >> >> > - Here's an input command (draw line, etc etc). > >> >> > - Get the tty size. > >> >> > - Redraw everything including the status line. > >> >> > - Redraw just the status line. > >> >> > - Redraw a single pane. > >> >> > - Redraw just the pane borders. > >> >> > - Show pane identifiers for N time. > >> >> > - Show message (on the status line) for N time. > >> >> > - Clear message. > >> >> > - Start prompt (on the status line). > >> >> > - Clear prompt. > >> >> > > >> >> > So instead of this, we would start saying "the window has been split" > >> >> > or > >> >> > "a window has been closed" or "this window has been resized" and it > >> >> > could decide what it needed to redraw or whatever itself. > >> >> > > >> >> > >> >> Once iTerm2 is attached, it wouldn't receive instructions to "redraw > >> >> the screen" from tmux. You'd send us new output (whatever output you > >> > > >> > Which new output? The raw output from the application or tmux's > >> > translated output? > >> > >> I don't think there's ever a case where you'd perform any > >> transformations on a program's output in this system. It should just > >> pass it clean through, no? > > > > If we pass it through unchanged, you will have to write your parser to > > understand the tmux terminal description (that is, TERM=screen). > > Oh, didn't know about TERM=screen. I'd strongly prefer not to write a > new terminal parser. Let's stick with re-encoding the output. > > >> Or do you need to decode it, update your internal state, and re-encode it? > > > > We'll need to update the internal state so the decode step will not be > > optional. > > > > At the moment there are basically two outputs from this step: > > > > 1 A set of calls to screen-write.c which update the internal copy for > > each pane (its "screen"). > > > > 2 These pass through to call a set of functions tty_cmd_* which update > > the real terminal for all attached clients using the appropriate > > terminfo entry. > > > > There is no reason with a few tweaks the second output can't be > > redirected over the wire rather than sent directly to the tty. > > > > If this isn't necessary we can just tap directly into the read event and > > queue up the raw data from the application. > > > > Whichever we do you will need to provide key input in the same > > way. > > > > Perfectly reasonable. > > >> > >> >> > When you want to manipulate or query tmux state I think you could use > >> >> > existing tmux commands. It might be nicer to have a set of underlying > >> >> > primitives that the commands were based on and that you could invoke > >> >> > but > >> >> > that is probably quite a big job. > >> >> > >> >> The existing set of commands covers some nontrivial portion of what I > >> >> need, so it seems obvious to me that the protocol we develop should be > >> >> based on your existing commands and their syntax. > >> >> > >> >> I think it would be great if this became an established protocol that > >> >> other terminal emulators coded to. If this works like I think it will, > >> >> it could really change the way people interact with their terminals. > >> > > >> > So what I'm leaning to at the moment is you basically have an > >> > interaction like this, where => is stuff you send: > >> > > >> > $ ssh -e none host tmux -C > >> > => list-sessions > >> > 0: 19 windows (created Fri Oct 29 19:54:56 2010) [170x43] > >> > 1: 11 windows (created Fri Oct 29 19:54:56 2010) [80x23] > >> > 2: 11 windows (created Fri Oct 29 19:54:56 2010) [80x23] > >> > 3: 1 windows (created Thu Nov 11 21:35:22 2010) [170x43] (attached) > >> > ^D > >> > => list-windows -t 0 > >> > 0: ksh [170x43] > >> > layout: dfde,170x43,0,0 > >> > ^D > >> > => list-panes -t 0:0 > >> > 0: [170x43] [history 0/2000, 0 bytes] (active) > >> > ^D > >> > => monitor-pane -t 0:0.0 [new, start sending me events for this pane] > >> > ^D > >> > => send-keys -t 0:0.0 -p 12 [where "-p size" is new and means read from > >> > stream] > >> > => xyz abc blah > >> > * 0:0.0 data 1000 > >> > \033[Hblah blah whatever....... > >> > * 0:0.0 move 0:1.0 > >> > * 0:1.0 resize 20 30 > >> > * 0:1.0 close > >> > > >> > Not sure about the separator. A preannounced size would be better but > >> > that is harder to implement with the existing code. > >> > >> I agree that specifying the size first makes more sense. Once you have > >> to deal with separators, things get complicated with escaping and so > >> on. I would prefer to have tmux's output be formatted for easy > >> parsing. For instance, instead of: > >> > >> => list-sessions > >> 0: 19 windows (created Fri Oct 29 19:54:56 2010) [170x43] > >> 1: 11 windows (created Fri Oct 29 19:54:56 2010) [80x23] > >> 2: 11 windows (created Fri Oct 29 19:54:56 2010) [80x23] > >> 3: 1 windows (created Thu Nov 11 21:35:22 2010) [170x43] (attached) > >> > >> say: > >> > >> => list-sessions > >> 0 19 1288407296 170 43 u > >> 1 11 1288407296 80 23 u > >> 2 11 1288407296 80 23 u > >> 3 1 1289540122 170 43 a > >> > >> This is more to avoid bugs than anything else. Cross-platform date > >> parsing, for example, makes me feel a bit uneasy. > > > > I think two formats seems like an unnecessary maintenance burden but > > I'll think about it. May be possible to do it in a way that isn't a mess > > of conditionals everywhere there is output. > > > > We can tweak the output to make it easier to parse if necessary so long > > as it remains human readable. > > > > The asctime() format is mandated by POSIX, it isn't going to change. I'd > > prefer something more compact anyway so we can probably use a different > > format. > > I can live with that. > > >> > >> Also, I think we do need to do some escaping, at least in the > >> direction of client to server communication. In ssh, for instance, ~ > >> has special meaning unless the user turns it off. Many users don't > >> know that this exists, and even fewer know they can change the escape > >> character. > > > > Typically you would get the user to tell your program the host and port > > and have it run the command, your default command can be something like > > "ssh -p $port -e none $host tmux -C". > > > > It worries me that this will cause mysterious breakage and people will > regard the feature as unreliable. Or users may decide to start tmux on > a host that they're already connected to and don't want to reconnect > with -e none. Or more likely, they don't read the documentation and > are unaware of passing -e none. An example of where this could go > horribly wrong is where a user ssh's to a remote host from within a > tmux session and types ~., expecting it to disconnect the "inner" > session, but the ~. leaks into the iterm->tmux connection. Inband > signaling is evil. Well, I'll think about it but escaping is a huge amount of hassle and there is no reason someone couldn't come up with a new protocol that requires different escapes. If you set a sensible default for ssh connections you create then in the rare cases where users hit it they can find out what the problem is from the documentation. I'm away again w/o email until Sunday. ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
