Re: Try the iTerm2/tmux integration
Hi
On Sun, Jan 22, 2012 at 12:13:20PM -0800, George Nachman wrote:
> This document describes in text the changes made and their
> motivations. At the end, I make recommendations on how to split this
> up into multiple smaller commits.
>
> New Files
> --
> There are four new files:
> 1. control.c
> ? Handles basic I/O with control clients, including:
> ? - Queuing spontaneous message notifications
> ? - Sending spontaneous messages
> Spontaneous messages are tmux-originated messages that tell the client
> that something changed: the number of sessions changed, the number of
> windows changed, a window's layout changed, a pty produced output,
> etc. Because notifications may arrive while a command is being
> executed, notifications are queued and then processed when no command
> is running.
> ? - Managing the key-value store
> The key-value store is a client-owned dictionary. It's used to
> remember window coordinates and which tmux windows appear as tabs in
> the same native window, for example.
>
> 2. cmd-control.c
> ? The one command used by control clients for all nonstandard functions.
> ? - control -e -t pane-id
> ? ?Prints a list of key-value pairs describing the internal state of
> tmux's vt100 emulator so that the client can sync up.
> ? - control -h -t pane-id -l num-lines [-a]
> ? Outputs up to "num-lines" lines of history including the current
> screen contents. If -a is given then the alternate screen is output.
> See below for a description of the encoding of history output.
> ? - control -k key
> ? Returns the value associated with "key" in the key-value store, or
> empty string.
> ? - control -s width,height
> ? Sets the size of the client. Windows cannot exceed this size.
> ? - control -s ready
> ? Marks the client as ready to receive spontaneous messages.
> ? - control -s set key=value
> ? Set the key "key" equal to the value "value" in the key-value store.
I'll have a closer look at these, not sure about the API. Might be nicer
to have subcommands rather than flags.
>
> 3. cmd-move-pane.c
> ? Like join-pane but doesn't mandate that the panes be in separate
> windows. Necessary to support dragging and dropping of panes.
This could go in separately but can it be a flag to join-pane instead?
>
> 4. dstring.c
> ? Dynamic-length strings. This simplifies various other bits of code.
I looked at this before, not sure I'm wild about it but let's worry
about it the first diff that needs it.
>
> History
> --
> The control -h command outputs a pane's history. The goals here were
> compactness, 7-bit cleanliness, and simplicity. The encoding is:
>
> HISTORY ::= CONTEXT REPEATED_LINES
> REPEATED_LINES ::= HISTORY_LINE "\n" | HISTORY_LINE "\n" REPEATED_LINES
> HISTORY_LINE ::= CELLS | CELLS CONTEXT HISTORY_LINE
> CONTEXT ::= ":" HEX "," HEX "," HEX "," HEX
> CELLS ::= CELLVALUE | CELLVALUE CELLS
> CELLVALUE ::= HEX | "[" REPEATED_HEX "]"
> REPEATED_HEX ::= HEX | HEX REPEATED_HEX
> HEX := [0-9A-F]{2}
>
> The CONTEXT's values are cell attributes, a subset of cell flags
> (FG256, BG256, and PADDING), foreground color, and background color.
>
> The idea is to output the cell's attributes (color, etc.) once and
> then as many character values as possible. Character values are either
> ASCII, held in one byte represented as a 2-digit hex value, or a UTF-8
> char which is a string of 2-digit hex values inside square brackets.
>
>
> Changes to Existing Files
> -
>
> client.c
>
> Ensures that a TTY is attached and turns off echo. If echo can't be
> disabled then the protocol won't work because the client's echo will
> be intermingled with server output.
>
> Sends MSG_IDENTIFY after STDOUT and STDERR so that it can send the escape
> code.
>
> Outputs %exit instead of the standard exit messages for control clients.
>
> When a control client quits not by issuing the detach command (e.g.,
> the server dies or the last pty dies), sleep for a bit and read all
> available input. The client may have sent some not-yet-received
> commands before getting the %exit message, and we don't want those to
> go to the shell--who knows what they would do!--so read and discard
> all available input for a few seconds. The side effect of this is that
> a short delay is introduced to try to wait for the input to arrive,
> but it doesn't happen in the common case of detaching cleanly.
>
> I'd prefer for tmux to wait for acknowledgment of %exit, but because
> the server may or may not be dead, it's very hard to do this cleanly
> (it might still be reading the file descriptor).
>
> cmd-attach-session
> ---
> Performs handshake and sends session-change notifications. Various
> tweaks to terminal usage to avoid stepping on control clients.
>
> cmd-break-pane
> --
> Change assignments to window->name to window_set_name().
This can probably go in separately.
>
> cmd-join-pane
>
> Gains
Re: Try the iTerm2/tmux integration
Actually, move-pane is fine as a new command, forget about making it a
flag to join-pane.
The join-pane changes and move-pane command can go in together as one
diff.
On Mon, Jan 23, 2012 at 01:53:09PM +, Nicholas Marriott wrote:
> Hi
>
> On Sun, Jan 22, 2012 at 12:13:20PM -0800, George Nachman wrote:
> > This document describes in text the changes made and their
> > motivations. At the end, I make recommendations on how to split this
> > up into multiple smaller commits.
> >
> > New Files
> > --
> > There are four new files:
> > 1. control.c
> > ? Handles basic I/O with control clients, including:
> > ? - Queuing spontaneous message notifications
> > ? - Sending spontaneous messages
> > Spontaneous messages are tmux-originated messages that tell the client
> > that something changed: the number of sessions changed, the number of
> > windows changed, a window's layout changed, a pty produced output,
> > etc. Because notifications may arrive while a command is being
> > executed, notifications are queued and then processed when no command
> > is running.
> > ? - Managing the key-value store
> > The key-value store is a client-owned dictionary. It's used to
> > remember window coordinates and which tmux windows appear as tabs in
> > the same native window, for example.
> >
> > 2. cmd-control.c
> > ? The one command used by control clients for all nonstandard functions.
> > ? - control -e -t pane-id
> > ? ?Prints a list of key-value pairs describing the internal state of
> > tmux's vt100 emulator so that the client can sync up.
> > ? - control -h -t pane-id -l num-lines [-a]
> > ? Outputs up to "num-lines" lines of history including the current
> > screen contents. If -a is given then the alternate screen is output.
> > See below for a description of the encoding of history output.
> > ? - control -k key
> > ? Returns the value associated with "key" in the key-value store, or
> > empty string.
> > ? - control -s width,height
> > ? Sets the size of the client. Windows cannot exceed this size.
> > ? - control -s ready
> > ? Marks the client as ready to receive spontaneous messages.
> > ? - control -s set key=value
> > ? Set the key "key" equal to the value "value" in the key-value store.
>
> I'll have a closer look at these, not sure about the API. Might be nicer
> to have subcommands rather than flags.
>
> >
> > 3. cmd-move-pane.c
> > ? Like join-pane but doesn't mandate that the panes be in separate
> > windows. Necessary to support dragging and dropping of panes.
>
> This could go in separately but can it be a flag to join-pane instead?
>
> >
> > 4. dstring.c
> > ? Dynamic-length strings. This simplifies various other bits of code.
>
> I looked at this before, not sure I'm wild about it but let's worry
> about it the first diff that needs it.
>
> >
> > History
> > --
> > The control -h command outputs a pane's history. The goals here were
> > compactness, 7-bit cleanliness, and simplicity. The encoding is:
> >
> > HISTORY ::= CONTEXT REPEATED_LINES
> > REPEATED_LINES ::= HISTORY_LINE "\n" | HISTORY_LINE "\n" REPEATED_LINES
> > HISTORY_LINE ::= CELLS | CELLS CONTEXT HISTORY_LINE
> > CONTEXT ::= ":" HEX "," HEX "," HEX "," HEX
> > CELLS ::= CELLVALUE | CELLVALUE CELLS
> > CELLVALUE ::= HEX | "[" REPEATED_HEX "]"
> > REPEATED_HEX ::= HEX | HEX REPEATED_HEX
> > HEX := [0-9A-F]{2}
> >
> > The CONTEXT's values are cell attributes, a subset of cell flags
> > (FG256, BG256, and PADDING), foreground color, and background color.
> >
> > The idea is to output the cell's attributes (color, etc.) once and
> > then as many character values as possible. Character values are either
> > ASCII, held in one byte represented as a 2-digit hex value, or a UTF-8
> > char which is a string of 2-digit hex values inside square brackets.
> >
> >
> > Changes to Existing Files
> > -
> >
> > client.c
> >
> > Ensures that a TTY is attached and turns off echo. If echo can't be
> > disabled then the protocol won't work because the client's echo will
> > be intermingled with server output.
> >
> > Sends MSG_IDENTIFY after STDOUT and STDERR so that it can send the escape
> > code.
> >
> > Outputs %exit instead of the standard exit messages for control clients.
> >
> > When a control client quits not by issuing the detach command (e.g.,
> > the server dies or the last pty dies), sleep for a bit and read all
> > available input. The client may have sent some not-yet-received
> > commands before getting the %exit message, and we don't want those to
> > go to the shell--who knows what they would do!--so read and discard
> > all available input for a few seconds. The side effect of this is that
> > a short delay is introduced to try to wait for the input to arrive,
> > but it doesn't happen in the common case of detaching cleanly.
> >
> > I'd prefer for tmux to wait for acknowledgment of %exit, but because
> > the server may or may not be dead, it's very
Re: Try the iTerm2/tmux integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, Jan 22, 2012 at 20:13:20 GMT, George Nachman wrote: > IDs > > Windows had no race-free identifier. I defined window IDs as a > monotonically increasing integer assigned at window creation time, and > referenced with an @ sign. For instance "unlink window -t @1". +1 > Sessions had no unique identifier. Add a monotonically increasing > session ID assigned at creation time. +1. What is the symbol for this? Not much is left that doesn't clash with common shell things. One of '!', '&', or '#' maybe? > Window panes had no race-free identifier. I defined pane IDs as a > monotonically increasing integer assigned at creation time, and > referenced with a % sign. For instance "break-pane -t %1". This is in trunk already. Is this duplicating that functionality? - --Ben (I have a nearly-complete zsh completion module for tmux and like to keep it up to date with patches.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCgAGBQJPHhESAAoJEKaxavVX4C1XkvwQAOFNiTCLBE7wBj4Ixhq84BkG 7UUeDaUOqaj+8A48fVY7K314CHETSsiE2ELhT/4+uHh1Qeq+QDafmVZoRkeAyv5V UAWR9m0C+svYYWaa3E6YIthTI6C8rgHxqGuv8vvuyVKhIsNhB+/IimxY86cHyJUl 4UudnmOmPPmMzrswub22s2EvFFp9ZCbIKUEOtzatVMuWo6qYW9Gm7g3Lwo80BWHN 5K4gw4/YJiydpfCLB1r2iMFez85j0E2JLxLSlRBys3Hb5DjhtlquiW/MX6CAMAI1 f+fBVOWpsen0IYMpJmBKi+zu93z2EMbVAMRjjhK8y36pMlqUo2KBII1s9tfUccBj e+W1yAfe5EgL6HgqtT/g4cdqT71rB5HZkd0qLyMvseHpPwLh8SHL1uG8P7yXNPqu GVoVv/ARuhEzXogUoIrbXqXBDAklpe7kXzRLNUi7rMq9ddloUj0ZeNPx3PnYSebP H02fplTYMenapjgQketOeb6BZhIkbZUJtT+deigtqaHxgGGxfmPPKI3UnbBKqt3m Gnx2n797HUnUD7DZA4NIr9c1VOL6M5QjAF3tkfvosbNlmyLdNyeS2Ul1XYnDq9Sh BWVppJEadOpuTZUYpH3m9d1T5uMHC29NJl/XE4yMwgL9aF66bT1NcaKsc/zJ9aLz oQsPVMJdU4JtuykFxsKR =ZNO8 -END PGP SIGNATURE- -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
