CHT — 光标正向制表（CSI I）

在哪里用到

实际会发出该序列的工具——把抽象字节锚定到你已经用过的命令上。

• vim / neovim `<C-i>` jump-list-forward—vim 的 `<C-i>` 跳转列表前进绑定（`<C-o>` 的逆操作）在多数终端上与 Tab 共享键码但语义不同 —— vim 在 `<C-i>` 后的终端模式重绘对显示缓冲的光标定位可能发 CHT 而非 HT。`:set verbose=15` 显示参数化形式
• less / more horizontal scroll (`<Right>` in `-#` chop mode)—less ≥ 633 在 `--chop-long-lines` 下用 `\x1b[<N>I` 把可见窗口按 N 个 tab 停位向右滚动，而非发 N 个空格填充重绘 —— 保持已有屏幕内容稳定，仅平移视口
• GNU indent / clang-format tab-aware reformat—`indent --tab-size=4` 与 `clang-format --style='{IndentWidth: 4, UseTab: ForIndentation}'` 在终端预览输出（`-d`/`--diff` 模式）中，当 diff 块跨越通过 TBC + HTS 设定的自定义 tab 网格时发 CHT —— 避免彩色 diff 输出中 N 个字面 tab 字符的视觉噪音
• ncurses `wtab()` / column-aligned table widgets—ncurses 的 `wtab()`（窗口 tab 推进）映射到终端 `cht` 能力 —— `infocmp xterm-256color | grep cht`（= `\E[%p1%dI`）可见。`nmtui`、`dialog`、`alsamixer` 用它对齐多列字段标签，避免发可变长 HT 串
• GNU pr column layout (`pr -t -m -w 80`)—GNU `pr -t -m -w 80`（多列合并模式）在 stdout 为终端且 `LC_ALL` 设置使 tab 网格非默认 8 时，在列间发 CHT —— 保持列边界整齐，不依赖接收终端对 HT 的解释

相关误区

该序列在实践中常见的踩坑——每条链接到完整的症状、成因与修复。

• ⚠CHT \x1b[I（Cursor Horizontal Tab forward）省略 Pn 按 ECMA-48 §8.3.10 默认为 1 —— 显式 \x1b[0I 同样为 1；最终字节 I（CHT）与 G（CHA）笔误是完全不同的操作（列 9 vs 列 1）·#csi-default-params
• ⚠CHT 在右边距钳制 —— 超出最后制表位的 Pn 被静默消耗，光标落在边距内最终制表位，*不*行换；让期待错误或像可打印字符在 ?7h 下溢出换行的程序员意外·#autowrap-cursor-end-row

常见问题

针对这条序列，开发者真正会去搜索的问题的简短回答。

什么时候发 CHT（\x1b[I）而不是字面 \t？

三种场景。(1) 未走 ONLCR / OPOST 烹饪的 raw 模式 —— \t 仍能通过，但若 TTY 处于完全 raw 且按字节维护列模型，带显式计数的 CHT 给你一次确定性发射，而非 N 个独立 HT 单元。(2) 一次跨越多个停位 —— \x1b[5I 一个 CSI vs. 五个 \t 字节，慢速串口下延迟更低，日志也更易读。(3) 在 DCS / OSC 载荷内部，\t 会被解析器视为数据而非控制。多数 TUI 用 \t 输出散文，因为它通过 terminfo ht 可移植；CHT（cht）是上述场景的参数化形式。CBT（\x1b[Z，见 csi-cbt）是对称反向。

CHT 会数被 \x1b[3g 清掉的 tab 停位吗？

不会 —— CHT 只数*当前设置的* tab 停位，所以一旦发了 TBC 清全部（\x1b[3g，见 csi-tbc）且未通过 HTS（\x1bH，见 esc-hts）重设，\x1b[NI 无论 N 多大都是空操作。光标不动，因为计数指的是光标会*落到*的停位，而非会*跨过*的列。这与清全部后 \t 失活属同族状态泄漏：任何为排版发 CHT 的代码必须在进入时重建 tab 停位，或在移动后用 DSR \x1b[6n 检测是否真的发生了变化。防御写法相同 —— 把 \x1b[3g 与新鲜 HTS 布局配对，再交还控制权。