BitSquare/Codeman
2
0
Fork 0
mirror of https://github.com/Ark0N/Codeman.git synced 2026-10-07 07:59:42 +02:00
Code Issues Packages Projects Releases Wiki Activity

style: drop em-dashes from the text added in c2114615

Browse Source 
House style, and these land in the changelog. Only the sentences added in the
previous commit are touched; the em-dashes in contributor text and in the
pre-existing COD-54/COD-115 comments are left alone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Codeman maintainer
2026-09-14 12:46:24 +02:00
parent c211461500
commit 48f30f3055
4 changed files with 8 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.changeset/7ab53c88.md
+1 -1
View File
@@ -14,7 +14,7 @@ check would let exactly the keystroke this exists to catch through.
This is defence in depth rather than a fix for the steady state: an agent CLI holds its tty in
raw mode with ISIG off, where ^Z is already inert. It covers the moments that are not the
steady state — the window before the CLI takes the tty at startup, and any point where it hands
steady state: the window before the CLI takes the tty at startup, and any point where it hands
the tty back. Two input paths are deliberately not covered and still reach the PTY: the mobile
keyboard accessory bar's one-shot Ctrl, and the CJK composition textarea when `cjkInputEnabled`
is on. Both are separate choke points to the PTY, and both are worth covering if this ever
.changeset/fix-claude-truecolor-in-panes.md
+5 -5
View File
@@ -13,10 +13,10 @@ already do, and the block renders in the color the theme actually names.
How bad the quantization was depends on `TERM`, which is why this looks different on different
machines. On tmux 3.2 and newer, whose `default-terminal` defaults to `tmux-256color`,
supports-color reports 256 colors and `rgb(55, 55, 55)` lands on `ESC[48;5;237m` — visible, but
not the color the theme asked for. Where `TERM` resolves to a 16-color entry instead — tmux
supports-color reports 256 colors and `rgb(55, 55, 55)` lands on `ESC[48;5;237m`: visible, but
not the color the theme asked for. Where `TERM` resolves to a 16-color entry instead (tmux
older than 3.2, or a `~/.tmux.conf` setting `default-terminal screen`, which Codeman's tmux
server does read — every dark background collapses to `ESC[40m`, the terminal's own black, and
server does read), every dark background collapses to `ESC[40m`, the terminal's own black, and
the block disappears entirely. That is the case this was reported from, and a custom Claude
theme could change the color there with nothing on screen moving.
@@ -28,8 +28,8 @@ reads it as a signal that it is running nested inside itself.
registry entry as the tmux pane and its attach client instead of deleting `COLORTERM` from a
hand-maintained list of its own. It applies that entry before assigning Codeman's own
variables, mirroring `buildEnvExports()`, so a `clis.json` override naming one of them cannot
strip it on this path while the tmux pane keeps it. A remote pane still exports nothing —
`buildRemoteLaunchCommand()` never carried these declarations — so an SSH-remote Claude
strip it on this path while the tmux pane keeps it. A remote pane still exports nothing,
because `buildRemoteLaunchCommand()` never carried these declarations, so an SSH-remote Claude
session keeps the old rendering.
PR #3 introduced the `unset COLORTERM` in February, citing xterm.js#484 for the claim that