tmux and screen have different models so there is no exact equivalent.
In screen terms, a split lets you display multiple windows at the same time. next (C-a n) rotates windows through the active part of the split; this lets you rotate “hidden” windows through the active region of the split.
In tmux terms, a split divides a window into one or more panes. Each part of a split window is an individual pane, panes are never hidden (if a window is selected (visible) all its panes are, too), and a pane can only be used in a single split of one window (a pane can not be in multiple windows, and it can not be in multiple splits of the same window). There are commands to move panes around in (or between) windows, but not in an identical way to next in screen.
You could use a binding like the following to arrange a similar effect:
bind-key C-n swap-pane -s :+.top \; rotate-window -Ut :+
You will probably want to put this in your ~/.tmux.conf file, but you can just type/paste it after Prefix : to bind it in your current server instance.
To use the binding, pick your “main window”, split it, create a “pane container” window immediately after the “main window”, then use the binding to rotate any pane in the “main window” among the group in the “pane container” window.
Here is how you might create the setup:
Pick a window to use as your “main window”. Start (e.g.) Vim in it.
Split your “main window” into two panes.
E.g. Prefix " (:split-window)
You can use this pane as your testing window (or log viewer, or whatever).
Create a new window (the “pane container”) immediately after your main window.
E.g. Prefix c (:new-window)
It is important that no other window gets between the indexes of the “main window” and the “pane container” window (+ in the window specifiers used in the bound commands means “the next higher numbered window”).
Split this window into a number of panes. To rotate through three panes, split this window into two panes (the third pane is the one in the “main window”).
Maybe you need a shell for git, and a shell for running a database interface. Put each in a separate pane in this “pane container” window.
Switch back to your “main window”. Select the pane that you want to “rotate out”.
You can use Prefix Up/Down/Left/Right to move among the panes.
Invoke the binding to swap the current pane with the first pane in “pane container” window and (“behind the scenes”) rotate the panes inside the “pane container” window (so that the next time you run the binding, the first command swaps with the “next” pane in the sequence).
Prefix Control-n (the binding use C-n, but you could change this to whatever you like).
To scroll backwards through the panes, you can use the below:
bind-key C-p swap-pane -s :+.bottom \; rotate-window -Dt :+
To understand the answer to this question, you need to have some understanding of how keyboard input is processed. I refer you to How do keyboard input and text output work? for background. In this answer, I'm going to explain the relevant part in a different way, but I'll assume some general familiarity given by my earlier answer.
My answer here concerns typical unix systems; non-unix systems may behave differently. I will make some simplifications here and there; the additional complications are not relevant to answering this question. (This answer is complicated enough as it is.)
Most communication and storage, including the communication between a terminal-based application and a terminal (hardware or software), takes the form of a stream of bytes. A byte is a unit of information that can take 256 different values; it can be subdivided in 8 bits. Bytes are represented by a number between 0 and 255.
In order to transmit information, the parties need to agree on a way to encode this information as bytes. There are multiple ways to encode streams of characters as streams of bytes, but all of them are based on ASCII in one way or another. ASCII defines a correspondence between 7-bit values ranging from 0 to 127 and a set of 128 characters; this leaves an unused bit in each byte. The 128 characters fall into two categories:
- 95 printable characters: letters (A–Z, lowercase and uppercase), digits (0–9), space, some punctuation;
- 33 control characters.
Control characters encode orders and ancillary information sent to or from a terminal such as “move the cursor to the next line”, “ring the bell”, “wait for me”, “goodbye”, etc. Historical terminals introduced a key labeled “Control” (or “Ctrl” for short), which allowed users to enter control characters. To keep the electronics of the terminal simple, pressing Ctrl together with a key would perform a simple bit mask in the byte value normally sent by the character. For example, A sends the character A represented by the byte 65 (1000001 in binary); Ctrl+A sends the character represented by the byte value 1 (0000001 in binary), which is known as the “control-A” character, often written ^A.
Most control characters correspond to an uppercase letter, with the bit pattern 10xxxxx, with bit 6 set to 0 instead of 1. That accounts for 26 of them. 6 more control characters correspond to the punctuation characters that also have a bit pattern of the form 10xxxxx: these are @[\]^_ (see the ASCII printable character chart. In addition to the range 0–31, the character 127 is also a control character; it's known as “control-?” (? is 0111111; control-? is 1111111).
Over the years, non-ASCII byte values have been assigned different meanings. The world is converging to Unicode as the set of all characters anybody might want. The Unix world (as well as the Internet) has mostly standardized on UTF-8 as a way to encode characters as byte sequences. UTF-8 maintains compatibility with ASCII by assigning the same character as ASCII to any byte in the range 0–127, and using sequences 2 to 4 bytes in the range 128–255 to represent the million or so other characters. Some other character encodings are used in the unix world; most are based on ASCII and have different meanings for bytes above 128.
I can now answer one of your follow-up questions:
how to type the (1-byte) characters in the ASCII range \0200 to \0377
That depends what character encoding you use. If you use UTF-8, the most common one, sending these individual bytes is impossible, because they're only used as part of sequences of 2 to 4 bytes that represent a single character.
As for
list A: all the possible values of the escape directive
that's just byte values. The escape directive requires a two-byte parameter. If Screen receives the first byte value from the terminal, it decides that its escape key has been pressed. If the next byte sent by the terminal is the second byte from the escape setting, then Screen decides that you wanted to send that first byte to the application running inside the Screen window after all.
The description of the bind command explains how to specify byte values in a way that Screen understands. Where the documentation reads “character”, read “byte” instead.
Before we get to list B, we need to understand keychords. A keychord is the press of a key together with modifiers such as Ctrl, Shift, etc. We saw earlier that all information transmitted by the terminal is encoded as a stream of bytes. To keep things simple, all printable characters are encoded in the standard way, as one byte in the range 32–126 if they're ASCII characters and as bytes in the range 128–255 for other characters. This leaves only control characters to encode function keys and characters with modifiers other than Shift. But there are only 33 control characters!
A few function keys send a control character. For example, the Tab key sends ^I (byte value 9), because byte 9 is the TAB control character that instructs a printer to move to the next tab column. The Return key sends ^M (byte value 13), because byte 13 is the CR control character that instructs a printer to move its head to the beginning of the line. For similar reasons, Escape sends ^[, and BackSpace sends either ^H or ^? due to some historical waffling that I won't discuss here.
Most function keys and keychords send an escape sequence: a sequence of bytes starting with byte 27, the escape character (ESC) defined by ASCII, which happens to be ^[ (control-[). Different terminals sent different escape sequences. There are standards, but they don't define encodings for all keychords, far from it, and to some extent there are competing standards.
We're now ready to understand
list B: all the possible values for the <CODE> parameter in the expression bindkey -k <CODE>
The Screen documentation explains that these codes are termcap keyboard capability names. Termcap is a programming library that applications can use to abstract themselves from the variations between terminals. (It has now been mostly supplanted by Terminfo.) The Termcap database specifically contains information about the terminal such as the number of lines and columns (back when Termcap appeared, terminals were hardware devices, for which the concept of resizing didn't apply), the byte sequences (often beginning with ESC) that an application could use to perform operations such as moving the cursor or clearing the screen, and the byte sequences send by various keys. The symbolic names given by Termcap to function keys are what you can use after bindkey -k.
The Termcap manual lists all the entries in that database. The entries all have two-character names; the FreeBSD manual also gives a slightly more expressive name for each entry. The entries where FreeBSD lists key_SOMETHING in the first columns are the ones that describe function keys; the <CODE> you need for bindkey -k is the name in the second column, such as kl for Left, k1 for F1, F1 for F11, etc.
You'll notice that this database is missing a lot of keychords. If there's no entry for a keychord in this database, then there's no name you can use for the key with bindkey -k. Note that the set of supported keys varies from unix variant to unix variant.
bindkey can also be passed an escape sequence. To use this feature, you need to know what your terminal sends for the keychord you're interested in. While different terminals send different escape sequences for the same keychord, going from escape sequence to keychord is, fortunately, rarely ambiguous: very few escape sequences correspond to different keychords on different terminals.
You can find out what escape sequence a keychord sends by pressing Ctrl+V then the keychord. In a terminal in its default mode, as well as on the command line of all common shells, Ctrl+V means “interpret the next byte literally”. If it's followed by an escape sequence, this causes the ESC byte to be inserted literally instead of initiating the parsing of an escape sequence. Since escape sequences almost always consist of printable characters after ESC, this effectively inserts the escape sequence literally. For example, press Ctrl+V then Ctrl+Left to see what escape sequence Ctrl+Left sends: you'll see something like ^[O5D where ^[ is a visual representation of the ESC control character. (Once again, your terminal may send a different escape sequence.)
As for the null setting, when Screen reads an ESC byte, it enters escape sequence parsing mode. Each new byte is added to the accumulated escape sequence. If the accumulated sequence has an associated binding, Screen exits escape sequence parsing mode and fires the binding. If the accumulated sequence is not the prefix of any sequence with an associated binding, Screen exits escape sequence parsing mode and the accumulated sequence is discarded. So the null setting here is a complicated form of “nothing happens”.
After all this work, let's turn to
list C: a mapping from any pair (a, b) (where a ∈ A, and b ∈ B) to an explicit description of how one would type the corresponding GNU-screen command character on a standard US keyboard, and assuming a specific terminal emulator
As I hinted above, specific terminal emulator is important here: different terminals encode keychords in different ways, and some terminals can be configured in different ways. The mapping doesn't correspond to a pair (a, b): A × B is not an interesting set. Most keychords are mapped to either a printable character (which, as we saw above, extends A) or an escape sequence (which, as we saw above, extends B). In other words, the mapping is to a superset of A ∪ B.
Unfortunately for you, many terminals don't fully document how to send escape sequences. Fortunately for you, this is rarely needed. Instead of working from escape sequence to keychord, work from keychord to escape sequence. This can be determined for each terminal using Ctrl+V as described above.
Some terminals, notably xterm, can be configured to encode keychords in a systematic way. See Problems with keybindings when using terminal for an Emacs-oriented discussion. Unfortunately, this does not include the vte library that many terminal emulators use, especially in the GNOME world.
Best Answer
You can do it with tmux by stringing together split-window and send-keys like this: