Mhmd7-7/dsh-rtl-chat-box

dsh-rtl-chat-box

用于 dsh 网页 GUI 的从右到左聊天框——用于在编辑器中书写阿拉伯语（或任何 RTL 文字），并可切换回英语。

它只改变聊天文本框，从不改变页面根元素：侧边栏、分栏以及所有其他界面都保持其正常的从左到右布局。

控件

设置 → 通用 → 聊天框方向

| 控件 | 效果 |
| --- | --- |
| RTL | 聊天框变为从右到左：光标、对齐方式和阅读顺序。 |
| LTR | 聊天框恢复为从左到右。 |
| Auto | 一切都跟随你输入的内容——阿拉伯语按 RTL 阅读，英语保持 LTR。每个列表项、段落和输入的每一行都遵循其自身的语言，在输入框中以及消息文本中都是如此。 |
| Smart bidi | 同一条消息中混合的阿拉伯语/英语保持正确的顺序（在输入框上使用 unicode-bidi: plaintext）。在 Auto 下强制开启。 |
| Also message text | 关闭（默认）= 仅聊天框。开启 = 已发送的消息和对话记录段落也遵循该方向。在 Auto 下强制开启，因为若 Auto 仅作用于输入框，则每条已发送的阿拉伯语消息都会按从左到右阅读。 |

在 RTL 模式下，pre / code / kbd / samp 被固定为 LTR，因此代码永远不会错乱。

编辑器是富文本编辑器，而不是 textarea

该 GUI 并未将编辑器放入 textarea 中。它将 Lexical 绑定到一个 contenteditable 宿主上，Lexical 会为该宿主的每个子元素按行写入一个块级元素（，以及列表内的 ）。

unicode-bidi 不会继承，而且该属性自身的定义明确指出，块级盒子上的 plaintext“不会影响任何后代块”。因此，作用于宿主的规则永远无法触及任何被输入的字符——实测表明：仅有宿主规则时，宿主内的一个段落保持左对齐，而同一个段落若由 p 规则匹配则会变为从右到左。

因此，Auto（以及 smart）样式表也指定了宿主的块级后代：

[contenteditable]:not([contenteditable="false"]) :where(p, div, li, …) { unicode-bidi: plaintext; }

这也使该模式独立于编辑器：Lexical 目前恰好会在其顶层块上写入 dir="auto"，而该插件绝不能依赖这一点。在 Auto 下仍然从不强制 direction，因此英语阅读顺序永远不会被改动。

Auto 中的列表标记

Auto 会按每一项根据该项自身的语言来决定标记：

| 项 | 标记 |
| --- | --- |
| 阿拉伯语（نستكشف المشروع） | 右边缘，紧挨文本 |
| 英语（Explore the project） | 左边缘，紧挨文本 |

这需要 list-style-position: inside，其原因很微妙。

li 上的 unicode-bidi: plaintext 只改变该项内容的排序方式——它根据第一个强字符推导段落方向。它不会改变元素的 direction 属性。

使用 list-style-position: outside 的 ::marker 位于该项旁边自己的盒子中，而它所处的一侧由该项的 direction 属性决定。
因为 plaintext 从不触及该属性，外部标记就被固定在一侧——这就是为什么无论尝试其他什么方法，阿拉伯语条目的编号始终停留在左侧。

使用 inside 时，标记会成为条目自身内容的第一个行内盒，因此它会按照与文本相同的、由明文推导出的段落方向进行排序。这是从 CSS 获得逐条目标记侧的唯一方法。inside 带来的两个后果必须处理，而且两者都是在 Chromium 中实测的，而非推理得出的。

块级子元素会使标记搁浅

每当列表是宽松的——条目之间有空白行，这在回复中很常见——Markdown 都会输出 …。标记是条目的第一个行内盒，因此块级子元素会把它单独留在一行上：该条目实测高 56px，其段落从下方 32px 处开始，也就是说编号绘制在文本上方。

GUI 自身的样式表已经为嵌套在列表中的 ol 处理了这一点（:where(ul,ol) ol li p { display: inline }）。Auto 会为每个列表这样做：

li > p:first-child { display: inline; unicode-bidi: normal !important }

unicode-bidi: normal 是关键所在，省略它会是一个真正的陷阱：共享规则会给每个 p 赋予 plaintext，而在行内盒上这会变成一个 FSI … PDI 隔离符。UAX9 规则 P2 在寻找段落第一个强字符时会忽略隔离符内部的字符，因此该条目找不到强字符，回退到 LTR，并把阿拉伯语标记放回左侧。使其对双向算法透明后，内联段落的文本就是条目自身 plaintext 段落所读取的内容。后续段落仍保持块级，因此多段落条目会保留其换行。

该 unicode-bidi 上的 !important 正是将其带入编辑器的原因。其上为宿主块级后代赋予 plaintext 的规则作用域限定为 [contenteditable]，因此其特异性为 (0,2,0)——[contenteditable] 加上 :not() 参数——而 li > p:first-child 仅达到 (0,1,2)。没有该标志，编辑器自身的 plaintext 会胜出，隔离符又回来了，阿拉伯语条目的编号也回到左侧。在 Chromium 中实测，一个位于 contenteditable 宿主内的阿拉伯语 ：

| 样式表 | 左侧间隙 | 右侧间隙 | 标记 |
| --- | --- | --- | --- |
| 不带 !important | 20px | 319px | 左侧 |
| 带 !important | 319px | 20px | 右侧 |

转录文本从未受到影响——那里没有任何东西的优先级高于该规则——这正是使该故障看起来像标记 bug 而非级联 bug 的原因。该标志是对同一份样式表中兄弟规则的声明级胜利，而不是对 GUI 样式表的又一次覆盖。

嵌套列表需要自己的缩进

当所有装订线归零（padding-inline-: 0）时，嵌套列表完全失去了缩进——子条目的文本落在了父条目的边缘上。标记也无法提供缩进：内部标记没有装订线列。因此缩进来自嵌套块本身：

li > ul, li > ol { padding-inline: 0.9em !important }

这是有意设计成对称的。一个列表会并排容纳阿拉伯语和英语条目，而只有显式的 direction 才能选定一侧——这正是 Auto 所不具备的。

在 RTL 和 LTR 模式下，整个列表只设置一个方向，因此它们保留 outside 标记和悬挂缩进——并且上面两种变通方案都不会被输出。

引用块竖条与任务列表方框

有两样东西依赖于条目的 direction 属性，而纯文本从不会改变它，且一个列表无法逐条目变化，因此 Auto 让它们保持各自的物理默认值：

- blockquote 即使其阿拉伯语文本右对齐，竖条仍保持在左侧（GUI 的 markdown 样式表以物理方式设置 border-left / padding-left）；
- 任务列表的 input[type=checkbox] 保持 GUI 的 margin: 0 8px 0 0，因此对于阿拉伯语条目，间隙位于复选框的外侧，而不是在方框与其文本之间。

RTL 为整个表面设置一个方向，因此它能够——也确实——镜像了这两者：竖条移到右侧（border-right + padding-right），复选框间隙翻转到左侧（margin: 0 0 0 8px）。LTR 两者都不需要，因为 GUI 本身已经是从左到右的。

为什么必须覆盖 GUI 自身的列表 CSS

dsh-web-frontend 中的 markdown 样式表是这样做的：

._markdown_ :where(ul,ol)    { padding-left: 18px }
._markdown_ :where(ul,ol) ol { list-style-position: inside; padding-left: 0 }

padding-left 是物理属性。在从右到左的列表中，标记需要其装订线位于右侧*，因此仅左侧的内边距会让编号无处可去。

那个选择器——一个类加上 :where()——具有特异性 (0,1,0)，因此普通的 ul, ol 规则会输给它。因此，插件用于修正列表布局的每条规则都标记了 !important。

该选择存储在 localStorage 中的 dsh-rtl-chat-box 下，因此它在页面重新加载后仍然保留。

布局

| 路径 | 作用 |
| --- | --- |
| package.json | 打包清单——dsh.bundle.patch 以及 dsh.client 入口（platform: web）。 |
| cordis.patch.yml | 将 ui-rtl-chat-box 行插入到 web 插件名册中。 |
| lib/index.js | 宿主加载器入口。有意为空操作：宿主侧没有任何内容。 |
| lib/client.js | 浏览器部分——方向样式表以及“常规”设置行。 |
| CHANGELOG.md | 发布历史，从 0.1.0 开始。 |
| LICENSE | MIT。 |
| .gitignore | Node/JS 忽略项，以及测量布局时使用的本地 probe/ 暂存空间。 |

要求

| 要求 | 版本 | 备注 |
| --- | --- | --- |
| dsh | 0.1.5-rc.2 | 本插件唯一经过检查的版本。按版本在 dsh.compatibility.dshReleases 中声明；其他版本未经验证。 |
| @deepseek-ai/cordis | ^4.0.1 | 对等依赖，从配置文件自身的安装中解析。 |
| 配置文件 | web | 该插件有一个浏览器部分，并注册一个 settings.general.item 槽位。 |
| Node.js | 已安装的 dsh 本身支持的任何版本 | 该包是纯 ESM，无需构建步骤，因此它本身不增加任何 Node 版本要求。 |

dsh-rtl-chat-box 没有运行时 npm 依赖。
lib/index.js 和 lib/client.js 已预构建并随仓库提供，因此
pnpm 无需批准任何 prepare/build 步骤：直接从 GitHub 安装
不需要在配置文件的 pnpm-workspace.yaml 中添加 allowBuilds 条目。

安装

dsh plugin --profile web add "github:Mhmd7-7/dsh-rtl-chat-box"

若要安装本地检出而非 GitHub 源，请将其路径传入以替代该 spec：

dsh plugin --profile web add "C:\path\to\dsh-rtl-chat-box"

然后重启 web 配置文件 —— 客户端 bundle 在服务器启动时构建，因此正在运行的 GUI 在重启之前不会加载此更改。

确实需要重启，仅刷新页面是不够的：宿主会以不可变缓存头缓存每个 /plugins//client.js 响应，缓存键为写入 window.__DSH_BOOT__ 的内容修订号 —— 而该修订号是在插件图组合时计算的，这发生在服务器启动时。本应在更改时重新组合的 client-hmr 行会处于空闲状态，直到重建监视器（从源码检出运行 pnpm run dev:web）重写 bundle，因此编辑过的 lib/client.js 对在编辑之前启动的服务器仍然不可见。

卸载

dsh plugin --profile web remove dsh-rtl-chat-box

检查更改

样式表由 cssFor() 生成，因此无需 GUI 即可渲染和测量。
本文件中每个数字所依据的探针会在 Node 中加载插件自身的 lib/client.js（带有 window/document 桩），为每种偏好状态在 GUI 的 markdown 样式表副本旁写一个页面，并从无头 Chromium 读回几何信息：

chrome --headless=new --dump-dom --virtual-time-budget=3000 file:///…/page.html

对每个元素，它会报告文本墨迹相对于内容框的间隙，这能区分标记在右侧还是左侧，以及 li 高度加上第一个子元素偏移，这能捕获孤立成行的标记。

说明

方向通过追加到 document.head 的单个  元素应用，并在插件的 fiber 被销毁时移除。

该框匹配为 textarea 或活动的 contenteditable 表面。消息
文本 —— 仅在“also message text”开启时 —— 作用域限定在对话记录
列 [data-chat-flow] 下，因此侧边栏、设置以及所有其他表面
保持其正常布局。方向设置在该容器上（它会继承），
而不是逐段设置，这也正是能作用到用户消息气泡的方式：一个
没有自身稳定类的普通 div，因此无法直接匹配。
在 Auto / smart 模式下，同一个气泡通过 div 上的
unicode-bidi: plaintext 遵循其自身语言。

权限与范围
dsh 插件以其加载它的 dsh 进程的权限运行。这个插件是浏览器端插件，它触及的范围是有限的：

| 表面 | 访问权限 |
| --- | --- |
| 主机文件、网络、子进程、凭据 | 无 —— lib/index.js 只导出一个空的 apply()，别无其他。 |
| 浏览器 DOM | 向 document.head 追加一个  元素，当插件的 fiber 被销毁时移除。 |
| 浏览器存储 | 一个 localStorage 键，dsh-rtl-chat-box，保存方向偏好。存储后端被阻止只会导致无法持久化，绝不会影响实时效果。 |
| 设置 UI | 在 settings.general.item 注册一行。 |

该包声明不访问文件、网络、命令或凭据，并且没有运行时依赖。它也没有 preinstall、install、postinstall 或 prepare 脚本 —— 安装它不会运行任何东西。

被列入插件目录并不等于安全审查，所以请阅读源码：整个插件就是 lib/client.js 加上一个空操作的主机入口。

贡献

欢迎在  提交 issue 和 pull request。

- 对于 bug 或行为问题，请开一个 issue。请包含方向模式（RTL / LTR / Auto）、你的预期，以及输入框实际的表现。
- 让 pull request 专注于一项更改。请不要顺带重构方向逻辑（lib/client.js 中的 cssFor()）：那里的注释记录了每条规则为何如此设计，其中大部分细节是在 Chromium 中实测得出的，而非推理得出的。
- 任何布局方面的论断都应附带支持它的测量结果，形式如检查更改所述。
- 将你的条目添加到 CHANGELOG.md 的 ## [Unreleased] 下，如果发布是 pull request 的一部分，请提升 package.json 中的 version。

许可证

MIT © 2026 Mhmd7-7