Skip to content
C.W.K.
Stream
Lesson 01 of 05 · published

One PTY per Pane

~11 min · pty, pane, swiftterm, tmux, embed

Level 0Spark
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

The Local Pane Model Has No Wrap

Once the daemon owns the process, the Mac app still has to be a terminal you can live in. That starts with a rule that looks small and is not: one PTY stream per pane. The local pane model has no "wrap in tmux" option. An external multiplexer composing local panes into one screen is the seam this quest opened with — two programs you do not own, a serialized rectangle, selection as a parser, restore as a guess. Owning the pane means that multiplexer is not in the path from process to pixel.

SwiftTerm draws that one stream: one terminal view per pane, configured, never patched. The emulator is embedded. The pixels are yours. Nested splits, drag, maximize, a tab that moves as a tree — those are native objects sitting on top of that one-to-one mapping. If a multiplexer sat between, every one of those objects would be a screenshot of someone else's grid.

Remote tmux Is a Different Sentence

A far host you do not sit in front of may still run tmux. Until the family owns daemons on those hosts too, that is an honest multiplexer for a machine that has no Smolder owner. You SSH there, you attach, you live in their screen protocol because that host has no pane objects to give you. That sentence does not license wrapping the local window. Local panes are never a tmux client of themselves.

The failure mode is a setting that says "use tmux for local splits, it is fine, we already speak it for remote." Same English word, two owners. Locally, Smolder is the multiplexer. Remotely, someone else's tmux is a guest inside one pane's stream. Keep those in different mouths. A guest inside a pane is content. A wrapper around local panes is a relapse.

One View, One Stream, One Owner

The daemon holds the PTY. The app holds a SwiftTerm view that reads that PTY's output and writes that PTY's input, under lease. There is no second grid. There is no local session server composing panes out of cells. Split is a native split of views, each view bound to its own PTY. That is why a sibling can ask for a folder in a new pane without pretending to type, and why a tab can move as a tree without starting placeholder shells.

This lesson is the desktop craft's floor. The rest of the track — tree, moveable tab, arrangements, chrome — assumes the mapping. Break the mapping to "get tmux features back" and you have not added features. You have sold the pane back to a stream.

One PTY stream per pane. Local panes are never wrapped. Remote tmux on a far host is a later, different sentence — a guest inside one stream, not a license to put a multiplexer between the pane and its pixels.

Code

Local mapping versus the relapse·text
# OWNED (local)
  pane A  <->  PTY A  <->  SwiftTerm view A
  pane B  <->  PTY B  <->  SwiftTerm view B
  split is a native view split, not a multiplexer grid

# RELAPSE (local wrap)
  pane A \                    /  SwiftTerm view (one rectangle)
  pane B  +-- tmux server --+
  pane C /                    \  selection, restore, sibling-open fight the stream

# HONEST (remote, until that host has a daemon)
  pane R  <->  PTY R  <->  ssh  <->  far tmux  <->  far shells
  far tmux is CONTENT inside pane R
  it is not composing pane A and pane B on this Mac

# Forbidden setting
  "use tmux for local splits because we already speak it for remote"

External links

Exercise

Draw two diagrams: (1) two local shells side by side in Smolder, (2) one local pane SSHed into a far host that runs tmux with two windows. Mark every multiplexer. Circle the one that is allowed. Cross out any multiplexer that is composing local panes. If you cannot tell them apart in the drawing, the sentences have already collapsed.
Hint
Allowed multiplexer sits on a far host, inside one stream. Forbidden multiplexer sits between a local PTY and a local pixel.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.