`open_config_file` has been `#[allow(dead_code)]` since
22e1ab16 — the initial commit — with nothing to say why. It is not
staged for anything: it was dead when it arrived.
It also hand-rolls a platform opener, picking between `open`, `explorer`
and `xdg-open` itself, while this file already reaches for
`cx.open_with_system` two thousand lines up and `terminal::view::
open_file_path` exists for the same job. Whoever wires an "open
config.json" affordance will write one line, not these twenty, and will
get the error reporting the file-link opener already has.
The other `allow(dead_code)` nearby is the counter-example and stays:
`palette::CheckoutBranch` says in its doc what it is waiting for —
"nothing emits it until the picker can list refs" — which is a parked
feature rather than a forgotten one. An allow that explains itself is
worth keeping; this one never did.
`every_dispatchable_action_has_a_slot_to_bind_it_in` states its invariant
exactly — an action `make_binding` answers to but `default_bindings` does
not list "cannot be bound at all: not from config.json, which drops it
silently, and not from the Keybindings page, which reads the second" —
and then checked three names against it. Two hand-maintained lists, 106
entries each, and a sample of three.
The set only exists as a `match` in this file, so there is nothing to ask
at runtime. Reading the arms out of the source is the same move `aumid`'s
test makes against `windows-installer.iss`, and it covers both directions
now: dispatchable with no slot, and a slot that dispatches nothing —
which binds a key to silence.
Confirmed against both. Deleting `NewTab` from either list fails the test
naming it; the lists agree at 106 today, so neither failure was waiting.
A guard on the parse too: fewer than 100 arms found means the scan has
stopped reading what it thinks it is, and would otherwise pass by
checking almost nothing.
`index_titles_match_rendered_row_labels` walks eleven titles and asserts
each one is in the index. It never touches a rendered row, so it says
nothing about whether every row has an entry — which is the question its
name answers, and the one worth asking: a setting added without an index
entry cannot be found by search, and nothing fails.
Renamed to what it does, with the gap written down rather than implied.
Walking the rows would mean rendering the page — they are built inline
rather than from a table, so there is no list to compare the index
against — and that is worth knowing before someone reaches for this test
expecting coverage it does not have.
No claim here that an entry is actually missing today: 69 are indexed and
I did not enumerate the rows to check.
`assets/icons/chevrons-up-down.svg` is drawn to the weight every other
glyph in that directory uses — `stroke-width="2.1"`, all twenty of them —
but it was the one path missing from `agent_icon`, so it fell through to
`gpui_component_assets` and the tab strip drew the stock 2.0 chevron
beside neighbours a hair heavier. Nothing failed, which is why nothing
said so.
`every_git_icon_resolves` could not catch it: it walks three paths
written out by hand, and its own comment names this exact risk — "an SVG
on disk that nobody added to the match above silently renders as
nothing". A list cannot notice the file it was never told about.
So the new test reads `assets/icons` instead and requires every `.svg` in
it to come back from `agent_icon`. Confirmed it fails without the arm
this commit adds, naming the file.
Found by checking shipped data rather than code — the same pass that
turned up the newline descriptions in `assets/completions`.
`elide` exists to make a completion description fit one row, and it only
ever bounded the length. A newline defeats the row at any length: gpui
breaks on it whatever the row says, so the description grows a second
line and its tail paints over whatever the menu is floating above.
This is shipped data, not a hypothetical. 122 of the specs in
`assets/completions` carry a newline in a description, and the break is
early enough to land inside the budget the menu hands out: ten of them
break before column 30. `go build -race` opens "Enable data race
detection." and breaks at column 27.
Folding in `elide` rather than at the call site, because every caller of
it wants one line by definition — and because the early return for text
already under budget was the path that handed a newline straight back
untouched, which a fix at the call site would have had to remember.
One cluster in, one cluster out, so the budget still measures what is
drawn.
Found by finishing the enumeration 1c203cc started, this time by asking
which *data source* a drawn string comes from rather than which module
draws it. Completion descriptions come from spec files, and 97 of those
ship in this repo.
The file tree stopped drawing raw filenames in 25d1f06, on the reasoning
that it was the one place a name arrives from a filesystem nobody here
chose. That was wrong by one: the SFTP panel draws names from a listing
on *another machine*, which is the same hazard with more claim to it —
gpui breaks a row on a newline whatever the row says, and the bytes are
picked somewhere this window has no say over.
Both sites the panel draws a name at: the entry row, and the transfer
row's `remote_basename`.
Display-only, as before. `entry.name` is what `remote_join` builds every
download, delete and rename path from, at five call sites, and a `↵`
spliced into one of those names nothing on the server. Checked after the
fact that every `one_line` in the file sits in a label.
Found by re-reading the scoping note from that commit while auditing
something else. It said only the file tree took names from an arbitrary
filesystem, and listed where not to bother. A remote listing is more
arbitrary than a local one, not less.
`confirm_question` answers `Destructive::RewritesHistory` and sends
everything else to the discard wording — "Discard all unstaged and
untracked changes? Staged changes are kept." That sentence is about
files, and it describes nothing that happens when commits go.
`LosesCommits` reaches it. Today that is harmless by accident:
`Reset { Hard }` is answered above by its own question, and the only
other producer is `GitOp::DeleteBranch`, which is fully built in
`ops.rs` — label, argv, validation, tests — and constructed by nothing
in the UI. Every destructive op goes through this one gate, so the day
branch deletion is wired up it inherits a dialog about the working tree,
reassures the reader that "staged changes are kept", and offers Discard
as the button to confirm it with.
A `debug_assert_ne!` on the loss kind rather than on the op, so it also
catches the next op that loses commits, and it names the op in the
message. Nothing changes in release, and nothing changes today in debug
either — verified by driving a `DeleteBranch` through the function, which
trips it with that message.
Left as an assertion rather than new dialog copy: writing a branch-delete
question, in three languages, for an operation that has no UI, is a
feature waiting for its caller to decide what it should say.
Measuring first changed what was worth doing. Of the fixtures left after
the previous commit, six prefixes turned out to create no directory at
all, while two accounted for 6,676 of them: `completion` (14 fixtures,
4,219 directories) and `file_copy` (15, 2,457). Both build every fixture
through one helper, so both are one edit.
A `cargo test` run of the bin crate now adds 3 directories where it added
37 before this pair of commits, and both converted prefixes hold at
exactly the count they started at.
The three that remain are deliberate. `pin_test_config_dir` and the
`set_config_dir` fixtures in `session`, `tree_sync`, `windows` and
`main` all point *process-global* state at their directory: no scope owns
it, tests in the same binary run in parallel against it, and a guard that
freed it at the end of one test would pull it out from under another.
`file_copy` compared paths it got back from the system against its
fixture, so it canonicalized — macOS answers `/private/var` for a temp
dir under `/var`. `TempRoot::canonicalized` resolves in place so the
removal stays attached, rather than handing back a bare path again.
The completion fixtures said `dir.as_path()`, which was inherent on
`PathBuf` and is not on the guard; they take a `&Path` by deref now.
`env::temp_dir().join(format!("tty7-x-{pid}"))`, wiped on the way in and
left behind on the way out, reads as self-cleaning and is not. The pid is
in the name so two concurrent `cargo test` runs cannot share a fixture —
which also means a run never finds the previous run's directory to wipe.
One directory per fixture per run, kept forever: this working copy had
25,639 of them, and `cargo test` added about 37 more each time.
Two modules account for 10,904 of those, and both build every fixture
through one helper, so both are one edit: `ssh_config` (18 fixtures) and
`cli_install` (19). They now go through `testutil::temp_root`, which
hands back a guard that removes the tree when it drops — the pattern
`core::git::log` already uses, rather than a fourth copy of it.
Measured rather than assumed: a full bin-test run leaves both prefixes at
exactly the count they started at (5217 and 5687), where they used to
grow every run. The remaining 29 per run are the fixtures in modules not
converted here.
The guard is deliberately not `Clone` — copying something that deletes a
directory on drop is not a copy — so three sites that wanted a plain path
say `to_path_buf()`. Eight more chained `tmpdir(..).join(..)`, where the
guard is a temporary that drops at the end of the statement and takes the
directory with it before the test looks at it; the test suite caught that
as a failure and they now bind the guard first.
`pin_test_config_dir` keeps its uncleaned directory on purpose: it sets a
process-global config dir, so no scope owns it. `view.rs` was spelling
that function out by hand and now calls it.
#550 settled the rule: one range, defined where the value is validated,
so a config-legal number cannot be turned around by a widget's narrower
clamp. `sanitize_clamps_to_the_same_bounds_the_gui_steps_within` states
it and pins the font pair. The two side panels broke it.
`sanitize` clamped both widths to 100–2000, and
`docs/reference/configuration.mdx` published that range, while the
sidebar floored itself at 180 and the right panel at 216. So a
documented `sidebar_width: 120` was accepted by sanitize, kept in the
file, and drawn at 180 — the file said one thing and the window showed
another, with nothing to explain the difference.
The floors move to `core::config` beside the font bounds, and the two
widget constants are defined from them, which is the direction that
cannot drift: the widget cannot be narrowed without moving the floor
the file is validated against. Docs updated to the real numbers.
The *ceiling* is deliberately not shared. Both panels also cap against
the viewport, but a panel wider than its window is a different question
from a panel wider than the setting allows, and only the second belongs
in `sanitize`.
`file_command_template_keeps_path_only_token_and_unknown_placeholder`
asserts that `code --goto {path}:{line}` with no line number produces
`["code", "--goto"]` — the path token is dropped, not kept. The name said
the opposite of the assertion, which is worse than no name: it describes
the behaviour someone would reasonably expect, so a reader skimming for
whether this edge is covered would conclude it is covered the other way.
The behaviour itself is deliberate and documented in the settings hint
("a flag whose value is absent is dropped"), and dropping the whole token
is right for the `--line={line}` case that hint is written around. Left
as it is; the comment now states the edge instead of hiding it, since a
`code --goto file:line` config opens no file at all on a link without a
line number and the caller only errors when every token has gone.
`explain_io` exists because "Permission denied (os error 13)" answers a
developer's question and not the reader's — its own doc says so. Every
failure routed through `HostOps::notify_err` gets it. Four that build
their notification string by hand did not, and printed the raw error.
The clearest symptom was inside one file: saving a file in the editor
went through `notify_err` and explained itself, while opening the same
file, denied for the same reason, said `os error 13`. Both file-link
openers are changed together — the file tree's opener deliberately shares
its wording with the terminal's (#542), so explaining one and not the
other would have split a pairing that was on purpose.
The `log::warn!` next to each call keeps the exact error. A developer
reading a log and a person who just lost a save want different things,
so both are written rather than one chosen — noted on `explain_io` along
with the rule, since it was the absence of a stated rule that let four
callers drift.
`tab_strip::clusters` already writes down why a label may only be cut on
grapheme boundaries: `👨👩👧` loses the joiner holding it together, `❤️`
loses the variation selector that makes it an emoji, and `🇨🇳` leaves a
lone regional indicator that renders as a bare letter. Three other
functions cut display text by `char` and so do exactly that.
`elide_middle` is the one that shows the gap most clearly. It documents
its cuts as safe because "everything here walks `chars()`, never bytes" —
true, and it guards the hazard that produces invalid UTF-8, which is not
the hazard that reaches the screen. Its sibling test is named
`never_cuts_a_multibyte_char_in_half`; the cluster is the unit above that
one, and nothing was holding it.
Each function keeps its own algorithm — head cut, middle cut, ellipsis
budget — and only the unit it counts in changes. That also makes the
budgets more honest than they were: a budget in clusters is a budget in
what actually gets drawn, where a budget in `char`s let one flag spend
two of it.
Callers pass ASCII in every existing test, so no rendered string that was
already correct changes.
`path_display` opens by calling itself the one place a path is measured
against `~`, because three rows spelling that check their own way is what
#544 was. Three sites in src/ui had since gone back to reading the
environment directly, and two of them read only `HOME` — the variable
#544 recorded as "often unset" on Windows:
- the file tree's fallback root, so a Windows window with no resolved
root drew an empty tree instead of the home directory;
- `expand_path`, so a `~/`-prefixed theme in config fell through to
`themes_dir().join("~/theme.json")` — a path that cannot exist, and no
error to say why.
The third (the SFTP download directory) already checked `USERPROFILE`,
but as a second copy of the canonical lookup under the same name, minus
its empty-string filter: `HOME=` set-but-empty resolved downloads to a
relative `Downloads`. It keeps its `.` last resort, which is a real
difference worth stating rather than deleting — a download has to be
offered somewhere, while every other caller wants the `None`.
No behaviour change on Unix, where `HOME` was already the answer.
A filename is bytes to the kernel, so `touch $'a\nb'` makes a file the
tree has to draw, and gpui breaks text on `\n` whatever the row says.
The row grows to two lines, its `text_ellipsis` contract stops holding,
and the rows below it slide down — one odd file misaligns the column.
The terminal's history rows already met this and already carry the fold
(`one_line`), so reuse it rather than spell a second one. What differs
here is where it may be applied: a history entry is only ever drawn, but
a filename is also handed to `join`, `rename` and `remove`. Folding at
ingestion would splice a `↵` into a name that has to match what is on
disk, so the fold sits at the two `.child(...)` sites and nothing on the
operations path sees it.
`f32::clamp` returns NaN for a NaN input rather than rejecting it, so the
clamp guarding a stored split ratio is weaker than it reads: a NaN would be
kept and then multiplied through every size beneath it.
Nothing can supply one today, but establishing that meant reading three
files -- the machine tree refuses a non-finite ratio (`clamp_ratio`), a
session file cannot carry a NaN because JSON has no such literal and an
out-of-range number arrives as an infinity that clamps like any other large
value, and both places that compute a ratio are guarded (`set_run_shares`
divides only `if total > 0.`, which is false for NaN too; `resize_focused`
adds a caller's constant).
Written down at the line that would have to change, because the thing that
makes it safe is somewhere else entirely, and the daemon already spells the
same rule out with an explicit `is_finite`. No behaviour change: adding a
branch for an input that cannot arrive would be the other mistake.
Ending a pane was one function: work out which parked panes nothing holds,
then hang them up. Only the second half needs a running daemon, and mixing
them meant the rule could only be checked by watching a fuzz run -- which
swings from fifty operations to five between runs on the same seed. That is
how a change of mine looked effective for five iterations while doing
nothing at all.
`stranded_of` is now the rule on its own, and a test states it directly: a
pane on screen is never ended whatever the tree says, a pane the tree still
names is never ended whatever the window shows, and only one held by neither
goes. Each of those three has been the difference between a leaked shell and
a killed one at some point in this file's history.
No behaviour change -- same filter, same order, called from the same place.
Verified the test earns its keep: dropping the `showing` check from the
filter fails it with `left: [1, 4], right: [4]`.
Both hang-up paths guarded on "the window that raised this is not showing
the pane". The answer they are guarding is the daemon's, and the daemon's is
machine-wide: `collect_orphan_panes` names any registered pane no workspace
holds, whichever window spawned it.
So with two windows on one machine, the second could spawn a pane, have it
registered, and still have its TabCreate queued -- and a close raised by the
first would see it named as detached, find the *first* window is not showing
it, and end it. A pane the other window is about to draw.
The same mistake as judging a pane against a tree that has not caught up,
one window over. Now the guard is the union over every open window, and a
window that will not answer abandons the sweep rather than shrinking it: one
that cannot be read might be showing anything.
Found by re-reading my own two commits rather than by a failure -- the fuzz
that verified them drives a single window, so it could not have caught this.
Sixteen `#[allow(clippy::…)]` in the tree; thirteen carry a comment saying
why. These were the three that did not, and the reason turned out to differ
for each.
`spawn_once` takes eight arguments against a threshold of nine, so its
`too_many_arguments` allowed nothing at all -- removed. `render_ssh_row` does
trip it, at ten with `self`, and `LocalHost::new` really does hand back a
`SharedHost` rather than a `Self`; both now say so.
Removing all three first and reading what came back is what separated them,
and it needed two passes: clippy stops at the first crate that fails, so
tty7-core's error hid settings.rs's until it was fixed. A single clean run is
not evidence about anything downstream of the first failure.
The window drops a view whenever its layout is rewritten -- a delta arriving
for a tab it had built differently, a rebuild from the tree -- and dropping a
view does not end the shell behind it, because that is also what detaching
is. So every reshape left panes running that nothing could reach again. This
is where most of them came from: a 150-op fuzz against an open window shows
31 layout rewrites to 2 rebuilds and 12 refused ops.
Panes put down this way are *parked*, not ended, and judged later. At the
moment of the drop neither mirror can say whether a pane is still somebody's:
the machine copy is missing whatever this window has just done, since a
client is left out of the deltas its own ops raise (#612), and this
workspace's copy runs ahead of or behind ops still in flight. Judging there
does end live panes -- both a machine-mirror check and a two-mirror check
were tried, and the fuzz caught each of them killing panes the tree still
named. The parked set is swept only against a tree the window has just
pulled, which is the one account of the machine here not assembled from
deltas, and only for panes the window is also not showing. Anything that
came back into the tree or onto the screen meanwhile is forgotten rather
than ended, because that is exactly what the mirrors were wrong about.
Over six fuzz seeds: no run ends a pane the tree still names, and where a
pull lands during the run the stranded shells go from 15-26 to 0-2. A run
with no pull sweeps nothing and leaks as before -- the parking is correct,
the coverage is only as good as how often the window pulls -- and
`tty7 pane close --orphans` still reclaims whatever is left.
TabClose and PaneClose answer with the panes the tree let go of, and the
shells behind them keep running until somebody hangs them up. The daemon
will not: the same removal is how a pane crosses to another tab, so it
cannot tell an ending from a move, and whoever sent the op has to say.
`tty7 pane close` always has -- hang_up_removed_panes exists for exactly
this. The window did it only where a *person* closed something, and never
for the identical ops its own reconciliation raises, because `pump` sent the
batch with `if let Err(e) = client.call(op)` and dropped the Ok on the
floor. Every pane the window put down while squaring its layout with the
tree left a live shell nothing could reach.
Measured with a 150-op tree fuzz driving the CLI against an open window:
5-6 shells per run were being stranded this way, and are not any more.
It is not the whole leak -- around 14 orphans per run survive, from the
paths ITER 13 named (a superseded hydration, a delta that would not apply),
which strand panes without sending an op at all.
A pane the window is showing is never hung up, whatever the tree says. The
daemon computes its answer with collect_orphan_panes across the whole
machine *after* the change, so a pane that merely moved is never named --
but a pane this window has spawned and registered and not yet placed in the
tree is, because at that instant nothing in the tree holds it, and its
TabCreate may still be queued behind the op that produced the answer.
Ending that one takes down a pane the user is looking at (#628). If the
window cannot be read at all, nothing is hung up: a leaked shell is
recoverable with `tty7 pane close --orphans`, a shell ended under a live
window is not.
The check runs on the main thread after the batch returns rather than
beside the calls, because `pump` may be running inside an App that already
holds the window entity, and gpui answers that by silently dropping the
update -- which stops the window syncing at all.
gpui picks a prompt button's role by matching the English word -- "cancel"
becomes a cancel answer, anything else becomes a plain Other that answers
neither Escape nor Return. `confirm_answers` exists to say which is which
instead, and sixteen of the app's dialogs use it.
The two SCM confirmations built their answers by hand from localized
strings, so `t(Cancel)` came out as a real cancel answer in English and as
an Other in Chinese and Japanese: discard, reset and amend -- the dialogs
guarding the operations that lose work -- had nothing on Escape for those
users. They also passed Cancel as answer 0, which gpui draws rightmost and
gives Return, so the position that means "do it" everywhere else in the app
meant "don't" here.
Both now go through the helper, with the index check flipped to Ok(0) to
match. The single-button restart-failed dialog had the same problem from the
other side: t(Ok) is "确定" in Chinese, so its only button was not an Ok
button either.
Add a test for the underlying rule rather than the three call sites: it
pins that a localized cancel label does not become a cancel answer on its
own, and says so in the failure message if gpui ever starts reading roles
another way.
app.rs's server-mismatch prompt still builds its answers by hand, and stays
that way -- it is documented as having no safe answer to give Escape to.
confirm_question returned the hard-reset question for GitOp::Reset in any
mode, and that text ends "and uncommitted changes are discarded" -- true of
--hard, untrue of --soft and --mixed, which both keep the worktree.
It is right today only because GitOp::destructive classifies soft and mixed
as harmless, so they never reach a confirmation at all. That invariant lives
in another crate and nothing here said so, leaving a reader to go and check
before they could tell whether a mixed reset shows a warning about losing
work it does not lose.
No behaviour change -- the arm is unreachable for the other two modes either
way. It now states its own precondition instead of borrowing one.
confirm_verb keeps matching every mode on purpose, with a note saying why:
"Reset" is the honest button label whichever mode it is.
The codebase already decided a secret must not reach a formatter --
NativeSshSpec spells its Debug out by hand, AuthResponse prints
Secret(<redacted>), and secrets_are_redacted_in_debug_output pins both.
Three types carrying secrets were missed and still derived Debug.
- KeychainWrite::SetPassword/SetKeyPassphrase hold the plaintext the user
just typed. password_submit returns one of these *beside* an
AuthResponse built from the same String, so the identical secret was
redacted in one return value and printable in the other.
- Attachment::token is the proof a connection holds a workspace. Its own
doc says it "goes over no wire and onto no disk" and #[serde(skip)]
enforces that -- but the log file is disk too, and the token is reached
by the derived Debug of Workspace, Machine, and the whole tree.
- ControlHello::client_token is the same kind of proof, in the one module
that already logs protocol values with {event:?}.
None of the three is formatted anywhere today, so nothing was leaking; this
closes the gap while that is still true, since a single {:?} added later
would have written a password or a capability token to the log.
Each gets a test in the shape of the existing one. Verified non-vacuous:
putting the derive back on Attachment fails with
token leaked: Attachment { token: "s3cr3t-capability", ... }
Five modules carried #[allow(dead_code)] on the `mod` line itself, which
silences the lint for everything inside them -- for good. host_ops and
host_registry are live infrastructure (73 and 22 references between them);
one unused item each had switched the lint off for the whole file, so
anything that died there later would never be reported.
Two of the five were covering nothing at all: tty7-core's core::keychain
and core::ssh_profile have no dead items.
What the allows were actually hiding, and what happened to it:
- HostOps::run_or_notify, HostRegistry::local and HostRegistry::len are
unused everywhere, tests included -- deleted. run_or_notify was only
run_in composed with notify_err, both of which stay.
- InFlight::len and ByHost::len are used, but only by tests, so they take
the house #[cfg_attr(not(test), allow(dead_code))].
- status_rank is used only by the test that guards it against DecoStatus's
Ord, which its doc comment already explains. Same treatment.
The two `len`s are why this is worth doing carefully: --all-targets still
reports them as never used, because the warning comes from the non-test
build of the binary. Deleting on that evidence broke the test build. The
compiler, not the lint, settled which ones were really dead.
Each of these sits on an item the code does use: ssh_config's
import_profiles, merge_imported and jump_alias, SshConnection's key field
and key(), NativeSshSpec::without_secrets, CmdEditor::cursor, and
Pane::ssh_connection. Verified by removing every dead_code allow in the
workspace and reading back what the compiler then reported -- none of
these appeared, in either a production-only or an all-targets build.
A stale allow is worse than no allow. It reads as "this is dead, on
purpose", so the next person leaves it alone, and it goes on covering the
item after the code around it changes -- at which point the item really can
die without anyone hearing about it.
cursor_byte is the one that is genuinely unused outside tests, so it moves
to the house idiom #[cfg_attr(not(test), allow(dead_code))], which still
reports it if the tests stop using it too.
"the server answered a machine tree with {reply}" reads as though a machine
tree was the thing answered. It is the request that was for the machine
tree, and the reply is whatever came back instead.
The Chinese translator had already worked this out and supplied the missing
word -- "回复了机器树请求" says "replied to the machine-tree request" -- so
zh needed no change. English and Japanese carried the ambiguity.
"daemon" is the code's word for it -- the --daemon flag, daemon/server.rs,
the RemoteDaemon* keys -- and the UI deliberately uses "server": the
dialogs say "Restart Server?" and "Quit and Stop Server?", the settings
section is headed "Server", and the errors either side of the one fixed
here say "tty7's local server".
RemoteDaemonTooOld broke that in all three languages. It called the local
process a daemon while naming the far-end one a server in the same
sentence, so the two read as different components and the instruction
"Quit tty7 (which stops the daemon)" sent the user looking for something
the rest of the app never names. It now says "tty7's local server",
matching the two keys directly above it.
The ja settings heading said "デーモンサーバー" where en and zh both say
just "Server" -- mod.rs already documents that this heading is meant to be
that word on its own.
Add a test: no user-facing string may call it a daemon in any of the three
languages. The search-keyword lists are skipped, since they carry the word
on purpose to match what a user might type.
tty7 calls the split regions inside a tab panes and the docked regions
around them panels, and Chinese has a separate word for each -- 窗格 and
面板. Eleven strings across four keys used 面板 for a pane, so they named
a different part of the window rather than reading as a loose synonym.
The settings page showed both senses a few rows apart: "text size ...
tabs, panels and settings" is genuinely 面板, while "give each pane its
own shell history" right below it claimed panels have their own shell
history -- they have no shell at all. The proxy description, the stale
daemon notice and the restart-server body had the same swap.
Japanese was already consistent (ペイン / パネル), and the English is the
source, so only zh.rs changes.
Add a test over every key: when the English names one sense and not the
other, the translation may not carry the wrong word. It matches whole
words, since "panel" contains "pane".
The note said refused tree operations are how this window strands a shell.
They are one way, and the minority one — which matters, because it is the way
that would attract a fix.
Measured with a randomized tree fuzz over the CLI (70 operations: tab new,
split, pane close, tab close, tab move, invariants checked after each):
daemon only, no GUI 0 orphaned shells
same run, window open 16 orphaned shells, 12 panes actually held either way
A second run of 70 left 10 orphans, and the warning this note sits on fired for
3 of them. The other 7 were spawned for a layout the window then threw away
without sending an operation at all — the log shows "dropping a superseded
hydration" and a delta that "did not apply cleanly" forcing a re-pull. Nothing
is refused on those paths, so nothing reaches this arm.
They are live `zsh` processes, not bookkeeping: each orphan answers
`tty7 procs` with a pid.
So the note now says which share this path accounts for, and that the sweep has
to be phrased against the end state — a pane this window spawned that neither
the machine tree nor any live view holds is stranded however it got there —
rather than against any single failure, which would fix a third of it.
Still diagnosis only, for the reason already recorded: the sweep belongs after
a hydration settles, and verifying it needs a GUI this environment cannot
watch.
2949 tests pass.
tty7 has a `ClipboardLoad` arm that reads the system clipboard and writes it
back down the PTY, and nothing in this crate says that must not happen. It does
not happen — `alacritty_terminal` refuses a paste request before it becomes an
event, because `Config::osc52` defaults to `OnlyCopy` — but that is the VT
crate's decision, taken by a field tty7 never sets, protecting a handler tty7
has already written.
So the exposure is one upstream default away: a release that moved `osc52` to
`CopyPaste` would hand any program able to write to a pane whatever is on the
clipboard, with no prompt and nothing in the sequence identifying who asked.
The program can be on the far end of an SSH connection, and a clipboard
routinely holds a password, a token or a private key. Terminals that offer the
read at all put it behind a prompt or an explicit opt-in.
`osc52: Osc52::OnlyCopy` is now stated where the rest of the terminal config
is, so writes still work and reads stay refused by tty7's own decision. No
behaviour change today. Same shape as `conpty_resize` two lines up, and it gets
the same kind of test, for the reason that one documents: a field whose default
already matches is a field whose line can vanish unnoticed.
The `ClipboardLoad` arm keeps a note saying what makes it unreachable and that
unlocking it needs a consent step first.
2937 tests pass.
A kitty graphics escape is untrusted input — any program running in a pane can
print one — and every bound on that path is deliberate and spelled out, except
this one. `to_rgba8` clamps an inflate to `min(declared, MAX_IMAGE_BYTES)` and
says why the declared size cannot be trusted on its own; the PNG branch called
`image::load_from_memory`, which leaves the ceiling to `Limits::default()`.
That default is 512 MiB — a real bound, eight times `MAX_IMAGE_BYTES`, and
somebody else's number. A patch release that relaxed it would silently widen
what a hostile escape sequence can allocate, and this runs in the GUI process,
so an OOM here takes every pane down rather than the pane that asked for the
image. The limit is now stated locally at the value the default has today, so
behaviour is unchanged and the invariant stops depending on a dependency's
opinion.
Why the number is not simply `MAX_IMAGE_BYTES`: that bound comes from what a
wire frame carries, and a PNG crosses the frame still compressed, so its
decoded size is the one thing on this path not already settled. Lowering it
would bound this properly but decides how large an image tty7 means to display,
which is a product call and not a cleanup — noted in the comment.
The PNG branch had no test at all, so the change is covered both ways: a real
2x1 PNG decodes at its own dimensions rather than the escape's `s=`/`v=`, and
a 1x1 PNG whose IHDR is rewritten to 0xffff x 0xffff (~17 GB, CRC repaired so
the decoder parses it) is refused. Checked out of band that the refusal really
is "Memory limit exceeded" and not a malformed-file rejection, so the test
cannot pass for the wrong reason.
2936 tests pass.
`TabCreate`, `PaneSplit` and `PaneReplace` each carry a pane the window has
already spawned — the shell is running on the machine before the tree is told
about it. When the tree refuses one of those, nothing ever takes the pane and
the re-pull leaves the window without the tab it was for, so the shell goes on
running with nothing referencing it. The log said only that an operation was
refused, which is the one thing that does not point at the leak.
Reproducible against a running instance: with a window open on a workspace,
`tty7 tab new` and `tty7 tab close` back to back. The GUI restores the new tab,
finds its pane already hung up, spawns a replacement, and `PaneReplace` is
refused because the tab is gone. Four cycles in five leak a shell; leave half a
second between the two and none do. Killing the GUI and repeating the loop
leaks nothing — the CLI half is correct throughout.
Not swept here, and the comment says why: at the point of the refusal the
window still holds a view for the pane and only drops it once the re-pull
lands, so hanging it up here would kill a pane that is still on screen. The
sweep belongs after the pull settles and has to test the whole machine tree
rather than this workspace's mirror, since a pane belonging to another
workspace on the same host is not this window's to end. That change wants a
GUI it can be watched in; this one only makes the leak say its own name, and
`tty7 pane ls --all` already points at the recovery.
`seeded_pane` is pinned by a test, because the set of requests that name a pane
into existence is exactly the set a refusal can strand one from — a new one
added without it would leak silently.
2933 tests pass.
Nothing had ever run `cargo doc`, so 16 warnings had collected. Four were
links to items that do not exist, and two of those were worse than a dead
link: `git_badge` and `info_chip` documented their sizes in terms of
`PANEL_TEXT` and `PANEL_TEXT_META`, px constants deleted when the interface
font scale landed. The module comment twenty lines up already says they went;
the prose downstream still derived pixel arithmetic from them, so a reader was
being told the pill is 20px tall against a 19px neighbour when both are now
rems that move with `ui_font_size`.
Rewritten against the ladder that exists (`META_MONO` beside `TEXT_MONO`), and
`info_chip`'s comment now records what its own numbers imply: its padding and
radius are pixels wrapped around rem-sized text, so the two stop agreeing once
the interface scale leaves 100% — the same trap `PIP_SIZE` right below it is
written in rems to avoid. Left as a note rather than changed, because that is a
visual decision and this cannot see the result.
The other ten are `private_intra_doc_links`, and that lint does not apply here:
it exists so a *published* crate does not ship docs whose links dead-end, and
all four crates are `publish = false`. Allowed at the crate root with that
reason, because a public item explaining how it relates to a private one is the
useful half of these comments.
The `clippy` job becomes `lint` and runs rustdoc too, on the same warm cache.
Still non-required.
2932 tests pass.
`closing_the_pool_drops_queued_work` never tested a queued job. `submit`
grows the pool whenever `jobs.len() > idle`, so blocking one worker and
submitting a second job spawns a second worker and runs it immediately —
the assertion only held when `close()` beat a brand-new thread to the state
lock. On a loaded machine it lost that race about one run in six.
A job only stays queued when the pool is saturated, so the test now fills it
to MAX_WORKERS first, asserts the job is on the queue before closing, and
waits for the workers to drain afterwards. 14 consecutive `-p tty7-core --lib`
runs green, against 2 failures in 16 before.
Placeholders in a translation were checked by nobody: `apply_template`
substitutes by name and leaves anything it was not given alone, so a `{name}`
dropped from the zh string reaches the user as a sentence that has simply
stopped naming the host, and an invented one draws braces on screen. Neither
is a missing or empty translation, which is all the parity test could see.
Both are now checked, for the plural and select branches too. Nothing was
wrong today.
The `KEPT_IN_ENGLISH` staleness check printed rather than asserted, and cargo
swallows a passing test's stdout, so the list could only ever grow.
The Linux build dependencies existed in four copies across three workflows;
release and nightly had the AppImage packaging tools (libfuse2, file,
imagemagick) mixed into the same list, which reads as if they were needed to
build. One script now, with the packaging extras installed separately, and the
ci.yml comment points at the docs page that actually documents the list rather
than at the README, which never did.
2931 tests pass.
CI checked `cargo fmt --check` and the build, so nothing ever read the
content of the code — ~200 clippy findings had accumulated, a third of them
in `#[cfg(test)]` modules.
Two of them were real:
- `resolved_background_appearance` took `backdrop`, and only the
`#[cfg(windows)]` arm used it. Renaming it to `_backdrop` is what clippy
asks for and compiles cleanly on macOS; on Windows it is an undefined
name. Kept the parameter and discharged it in the non-Windows arm the way
`package_for_current_install` already does.
- `SettingsSearchBackdropKeywords` and seven other `L10nKey` variants were
carrying translations in three languages for strings nothing reads.
The rest is mechanical: let-chains for collapsible `if let`s, struct-update
syntax for `Default::default()` reassignment, `sort_by_key` where a manual
reversed comparator was doing the same job the same file already did with
`Reverse` two functions later.
Where clippy was wrong, the reason is now in the tree rather than rediscovered:
per-platform `#[cfg]` blocks each keep their `return` (dropping it only
compiles on whichever target's block lands last), the loopback parser keeps
three parallel arms instead of folding one into a `?`, and the four wide enums
are all built on the stack and consumed immediately, so boxing them would add
an allocation rather than save one.
`L10nKey` cannot be clean under `dead_code` on any single platform, so the
allow there records how to audit it instead — which is how the eight dead keys
were found.
`english()` gained the cross-platform test its doc comment already claimed;
only the Windows hint had been pinned.
The clippy job is non-required until it has green history, for the same
branch-protection reason `host-boundary` documents.
2930 tests pass.
* feat(tabs): drag a tab in as a pane, and a pane out as a tab
A tab dragged by its chip or its sidebar row can be dropped over the
panes to become one of them, and a pane dragged by its grip can be
dropped on the strip or the sidebar to become a tab of its own. Both
carry the panes across as they are: nothing is spawned and nothing is
killed, so a shell mid-command, an SSH session or an agent mid-turn
keeps running.
The landing is read the way a pane drag's already is, minus the middle:
an arriving tab has nothing here to trade places with, so a pane's core
means "split it the way it is longest". A tab that was itself split
arrives with its own shape intact and takes one share of the row or
column it joined. A pane on its way out is offered a caret between two
tabs, and the last pane in a tab is offered nothing, being a tab of its
own already.
Picking a tab up no longer switches to it: the strip and the sidebar
now activate on the click rather than on the press. Without that the
merge cannot be expressed at all — pressing the tab to drag it would
put it on screen, leaving no other tab to drop it into.
Two things in the machine tree had to follow:
* Panes that change tabs are told as PaneMove, one at a time, rather
than as a tab closing and another being rebuilt around them.
* The tabs the machine already has are reconciled before new ones are
created, so a pane leaving for a tab of its own is given up by the
old tab before the new one asks to register it. The machine refuses a
pane that is in two tabs at once, and the refusal desynced the window.
Closes#621
* test(tree-sync): a tab grafted above a whole layout still converges
* fix(tabs): keep a click on the close button from switching tabs
Switching on the release rather than the press means every click inside
a chip or a sidebar row now reaches the row itself, and gpui-component's
`Button` does not stop propagation on a click it handled. So one click on
a tab's close button ran `close_tab(i)` and then `activate(i)` — with `i`
by then naming whichever tab had slid into that slot, which moved the
active tab somewhere nobody asked for. A click into the rename field did
the same: it switched away from the tab whose name was being typed, and
took the focus out of the field with it.
Both now hold the click where they handled it, the way they already held
the press.
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
* fix(scm): keep the sync tile on the branch row at any panel width
The branch row's flex constraints were set on the Button, but
`dropdown_menu_with_anchor` hands that Button to a `Popover`, which wraps
it in a plain div and never applies the trigger style it was given
(`trigger_style` is stored and never read). The constraints landed inside
a box that still measured its own content, so at the panel's 216px floor
a 24-character branch name overflowed the row and pushed the sync tile
out of the panel entirely, with no way to reach it.
Carry `flex_1` on a wrapper instead, and truncate the name against the
width it is actually given rather than against a character budget that
was guessing at that width. The `elide_middle` ceiling is gone: stacked
on top of a real truncation it produced two ellipses in a row
(`fix/new-tab-……`) and threw away the tail it existed to keep.
Notes and chips move into one `overflow_hidden` group that is allowed to
shrink, so the order of who gives way is explicit: branch name first,
badges second, the tile never.
Also stop offering "Publish Branch" from a HEAD that cannot publish. A
detached or unborn HEAD has no upstream by definition, so the token fired
there unconditionally — the widest thing on the row, naming the one
operation the tile beside it already refuses (#545), and on its own
enough to push that tile off a 216px panel.
* fix(scm): drop the branch row's note box when it holds nothing
The row lays the notes and chips out in one shrinkable box so the sync
tile keeps its place. An empty box is still a flex item, so the row's
6px gap was spent on either side of nothing: on the quiet branch that
is most of what anyone looks at, the caret sat 12px off the tile
instead of 6px. Build the notes first and only add the box when there
is something in it.
Also drop two comment citations of #549, which is about palette
commands that no-op silently and has nothing to do with this row.
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
* fix(new-tab): keep the SSH menu inside a menu's shape
The saved-host rows carried names and endpoints long enough to drag the panel
out to the 500px ceiling PopupMenu falls back to, and the row that meant to
elide was clipped mid glyph instead. The menu now stops at 360px, and a row
that runs out of room cuts the endpoint first — the name is what the reader is
picking by, so it keeps whatever is left rather than being squeezed to "..".
The height ceiling moves up to fit the shape everyone actually sees — nine
shells, both headings, six hosts and the two closing rows — so the default menu
arrives whole instead of scrolled with "Local" cut off above, and is capped
again against the window so a short one never gets a menu taller than itself.
The rule above the split hint goes: a separator divides two lists of things to
pick, and the hint is a footnote about the list it follows.
Bumps gpui-component, where a scrollable PopupMenu painted a scrollbar whether
or not it overflowed, custom rows could not elide, and labels had no padding of
their own.
* fix(new-tab): measure the menu ceiling off the viewport, and elide nameless hosts
`window_bounds()` answers how a window should be reopened after it is
closed, so a fullscreen macOS window reports the bounds it would restore
to rather than the screen it currently fills. A terminal spends much of
its life fullscreen, where that reading capped the menu at 80% of a
window nobody is looking at — putting back the scrollbar and the
cut-off `Local` this branch is here to remove. `viewport_size()` is what
every other window-relative size in the app already measures against.
A host saved on its address alone is *named* `user@host:port` and carries
no note, so it took the plain-item path — bare text with nothing to elide
against, on the longest string in the menu and the row least able to cut
it. Every host row is a custom element now, and `menu_row` drops its
right half when the note is empty rather than holding the gap open with
a zero-width child.
Also drops 17 unrelated dependency downgrades that rode along with the
`gpui-component` bump. The lockfile moves only the three `source` lines
it meant to; `cargo check --locked` accepts it.
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
Adds a saved-SSH-hosts section to the New Tab menu on both the tab strip and the sidebar, ordered by frecency, with a row that opens the full host palette. Holding the modifier opens the host in a split instead of a tab.
The menu scrolls once the rows outgrow the popup, long host names and their endpoints truncate rather than overflow, a host with no name of its own draws its endpoint once instead of twice, and the rows are built when the menu opens rather than on every painted frame.
Hoists the SSH password prompt's overlay from the body area to the window root so its scrim covers the title bar, tab strip and side panels, and aligns its top offset with the switcher card.
Replaces the raw target string with the resolved machine label on the reconnect banner and on the connecting pane, so a profile-backed machine no longer shows a bare config UUID in "Connecting to …" or "Could not reach …".
* feat(ui,daemon): retire to the tray on window close and make cold start immune to stale daemon files
Two problems shared a root: the daemon outlived every window, and
nothing could stop it gracefully.
Window lifecycle:
- Closing the last window retires the app to the tray instead of
quitting (QuitMode::Explicit), so the daemon stays reachable. The
tray restores the most recent workspace, and Quit — after the
confirmation that protects running shells — stops the daemon. Every
explicit exit path (tray, palette, keybinding) now stops the server;
no exit leaves an orphaned daemon behind a dead icon.
- A pathless launch (double-click) hands off to the registered GUI via
GuiOpen(None) and exits, instead of starting a second process with a
second tray icon.
- The tray subsystem initializes once per process; reopening a window
no longer creates a duplicate icon.
Cold-start robustness:
- Liveness connects are bounded to 500 ms, the version handshake times
out in 1 s, and an unresponsive daemon is reaped by its recorded pid
instead of polled for a 6 s graceful stop.
- A dead recorded pid skips the TCP probes entirely — the GUI's
ensure_running, the new daemon's endpoint check, and the
control-listener occupancy check (which could also misread a reused
port as a live control server and refuse to boot). Stale cleanup now
also removes the leftover control.port.
* fix(daemon,gui): skip the GuiOpen handoff probe when the recorded daemon is dead
* fix(lifecycle): keep the stale-endpoint cleanup, and do not retire into a tray that is not there
Three gaps in the tray-persist and cold-start work.
`ensure_running` moved the refused-connect branch under the new liveness
check, so a connect that fails while `recorded_daemon_is_dead` says "not
dead" now skips the reap and the stale-endpoint removal entirely. The
pidfile answers "not dead" to two cases it has no evidence about: it is
missing (the daemon died between `transport::bind`, which writes
daemon.port, and `pidfile::write_current`), or it records a pid the OS has
since reused. Both then leave daemon.port on disk and the spawn poll pays
the OS's refusal delay on it — the cost this path was rewritten to avoid.
Restore the branch, and split the rule into `recorded_daemon_is_dead_with`
so a test can state that a missing pidfile is not evidence of death,
without an env var every parallel test would inherit.
The tray's windowless Quit stopped the server without a prompt, reasoning
that the confirmation is about the panes behind a window. It is not: it
says "anything still running in your shells is terminated", and retiring to
the tray is precisely what leaves those shells running with no window. Bring
the window back and deliver the action to it, so the confirmation appears;
only when no window can be opened does the bare stop remain, with a warning.
`show_tray_icon` is a request, not an outcome. `Backend::create` can fail
for a whole run — a Linux session with no StatusNotifier host is the
ordinary case — and after MAX_ATTEMPTS the loop gives up and logs. Retiring
on the config alone then leaves a process with no window and no icon: not
reachable, and still holding the daemon. Gate the retirement on an icon
actually being up.
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
The tab title follows the terminal's OSC title, and nearly every prompt
framework sets that to the command it is about to run and puts the old
title back at the next prompt. For anything that finishes in a blink both
edges arrive within a few frames, so the label showed the command and
snapped straight back — a flicker that reads as a rendering glitch rather
than as information.
Hold a new title for 400ms before the tab adopts it. A title that reverts
inside the wait matches what the tab already shows and drops the pending
one, so a short command never reaches the label at all; one still running
when the wait elapses names the tab as before, 400ms later.
A second title arriving mid-wait rides the wait already in flight instead
of restarting it. Restarting is what would let a program that rewrites
its own title faster than the wait — a download reporting progress —
put the tab's next update off for as long as it ran.
Child exit clears the pending title and writes its own immediately: a
title still waiting its turn would otherwise land on top of "(process
exited)" a moment later.
The centring added in #631 turned the settings content box into a flex
column, and that cost the page most of its scroll range: the box is an
item of the scroll pane, which is itself a flex column, so its height
came out of a negotiation with the pane rather than from the rows it
stacks. `content_size` is just that box's laid-out bounds, so the range
ended a screen short of the last row — dragging to the bottom still left
content cut off. `flex_shrink_0` does not help; the height is agreed,
not squeezed. Centre with `mx_auto` on the column instead and leave the
box a block, which reports the full height it stacks.
While there, hold the content scrollbar 12px clear of the top and
bottom. Every other list this bar serves sits in a bordered panel where
running the full height is right; this pane is the window, and a bar
drawn to the last pixel lands on the rounded corner. New
`with_inset_vertical_scrollbar` takes the inset, and the existing
`with_vertical_scrollbar` keeps its behaviour for the other twelve
call sites.
* fix(remote): stop the server on machines that have no /proc, and show the install on the strip
Restarting the remote server timed out after ten seconds on every Mac and
BSD, with the old daemon still running and the new binary already sitting
next to it, unlaunched.
Both the probe that finds the running `tty7-server-*` and the command that
terminates it walked `/proc/[0-9]*` and read each `exe` symlink. There is no
`/proc` there. Two things then went wrong at once. zsh is the login shell on
macOS, and it aborts the whole command line when a glob matches nothing, so
even the trailing `true` never ran; and `cycle_daemon` discards the result of
the terminate, so a command that killed nothing was indistinguishable from
one that worked. `daemon_is_serving` then answered yes until the deadline.
Guard the glob behind `[ -d /proc ]` — unreached, it is never expanded, so
zsh has nothing to abort on — and fall back to `ps`, whose `comm` is the full
path on the BSDs. It cannot be the only branch: Linux truncates `comm` to 15
characters, one short of `tty7-server-c7p5`, which is why `/proc` stays the
first choice where it exists. `check_running_build` reads the same probe and
was equally blind on those machines; it can see now.
Separately, the install progress bar only ever existed inside the switcher.
Pressing Update Server from a parked workspace with no switcher open froze
the window for the length of the download and then produced a modal, with
nothing in between. The strip draws it too now — caption and bar from the
same source the switcher uses, and no button while an install is in flight,
since pressing it again would start a second one on top of the first.
* fix(remote): say why a stop failed, and stop a leaked install from eating the strip's button
Three things the no-/proc fix left standing.
`cycle_daemon` still discarded the terminate's result, which is the other half
of why a Mac cost a bug report: the command ends in `true`, so anything short
of success means the far end never reached the kill at all, and that is exactly
what a zsh abort looks like. It is now logged, and named in the timeout error —
"the running remote daemon did not stop within 10s" on its own blames a daemon
for ignoring a request nobody managed to send it.
The strip hides its Update Server button whenever an install is in flight,
which is right, but it reads the progress registry with no link state to temper
it — unlike the switcher. `finish_connect` bows out before clearing that entry
whenever `connect` has moved on in the meantime, and a switcher disconnect or a
move to another workspace both do that mid-install. The leftover froze a
progress bar on every window pointed at the machine and took away the one
button that could have fixed it. Cleared where the attempt actually ends
instead, however it ended.
The switcher kept its own copy of the progress bar after the caption was
shared; it draws the shared one now.
Tests: the probe runs for real in every shell on the machine rather than only
parsing under `sh -n` — the glob that started this was valid syntax and only
fell over when zsh ran it, which no `-n` can see. `ps` is checked on its own
where the fallback would actually be taken, since that arm eats its own stderr
and a rejected flag would otherwise cost nothing visible. And a stop that fails
is asserted to reach the error.
`with_shutdown_timeout` exists so that last test does not sit out ten seconds.
---------
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
A pane that never armed shell integration blamed a PTY wrapper or an unsupported shell setup. Since #629 a zsh or fish the user gave arguments to is deliberately left alone, so the notice now names that first — it is the one cause the user can undo. All three locales.
The release notes gained the matching entry: the change turns integration off for an existing config that sets `shell` or a `custom_shells` entry with `args`, which is worth stating outright.
Co-authored-by: l0ng-ai <24760907+l0ng-ai@users.noreply.github.com>
A window's mirror of its machine held no `PaneRecord` for a pane the window itself created. Records ride inside layout deltas and a client is left out of the deltas its own ops raise, so the record the daemon mints when it registers a seed reached every window but the one showing the pane; `PaneFacts` closed the gap only when a fact changed, and a pane spawned into its directory and left at its prompt never changes one. The workspace answered no subject path, an unnamed one read "Untitled", and `record_geometry` stamped a null subject over the path views.json remembered.
The window knows what it seeded, so it now puts those records into its own mirror through the same `PaneSeed::into_record` the daemon mints with — opened up rather than duplicated, so ssh-secret stripping stays shared — with the window's own Ready terminals standing in for the daemon's liveness probe. The write is insert-only: a record the mirror already holds came from the machine and outranks what a seed knows.
Also closes the race that reopened the same symptom by another route: a `MachineGet` already in flight installed its tree whole and took the client's not-yet-acknowledged writes with it, and nothing re-inserted them until the next non-empty op. All four optimistic writers now go through one path that keeps each write for the life of a pull in flight and replays it over the tree that lands. The tree stays authoritative for everything it speaks about — only the ops it was built too early to know are put back on top, and the journal is drained once it has landed, so nothing a later tree dropped is resurrected. This covers #604's pushed tabs and workspace ops, not only the seeded records.
Fixes#612.
Since #415 the daemon echoes a `Size` frame at the stream position where the pty changes geometry and the client defers its grid reflow to that marker — but only on local routes, so a remote pane resized mid-flood still parsed queued old-width bytes into the new-width grid, which network transport makes worse.
Rather than probing `Version` per pane (a whole routed connection, and for ssh/WSL a whole bridge process, on every spawn and attach), the server advertises the pane protocol's features on its control hello. The answer is cached on the link and read off the host when a pane's route is built, and the route carries it to the terminal at spawn, attach and relink. This is additive within `CONTROL_VERSION` 7: no new field, just extra names in the existing `ControlHelloOk.features`, so an older client cannot choke and an older server that names no echo makes the client reflow at request time as before. A route built while the link is down answers false.
Known limitation, inherited from #415's design and not introduced here: there is no timeout if a promised echo never arrives — once deferred, a later identical resize neither re-sends nor reflows, so a wrongly-set bit would freeze the grid at the old geometry. Every traced path makes the control hello and the pane daemon the same build, normally the same process.
Closes#416.
`sidebar_grouping` gains a third, opt-in mode, `repo-or-directory`: group by repository home as before, and when the repo probe has landed and answered "not a repo", group under the cwd itself instead of filing every such tab under Scratch. A probe that has not run yet resolves to no decision, so a tab keeps the group it already has rather than bouncing through Scratch mid-probe. The decision lives in one `resolved_group` free function shared by the per-frame key derivation and spawn-time seeding.
The default (`repo`) and flat modes behave exactly as before, and an unknown value in an existing config still degrades to `repo`.
Knock-on: `machine_mirror::subject_path_of` names a window after its most common group, so in the new mode a window of plain shells takes its name from the most common directory rather than from the first pane's cwd.
Closes#620.
l0ng-ai
l0ng-aiandl0ng-ai
ARNOandl0ng-ai
webdev