Repository navigation
@符合 接着跟任意文本在会话中会被误渲染成文件引用样式 #9836
Replies: 4 comments 1 reply
|
你的观察对，但要先改两处措辞，否则会被维护者第一轮就纠正。 一、不是"任意文本"，是词首
|
| 输入 | 是否成 chip |
|---|---|
@name |
是 |
@a.ts |
是 |
@"/" |
是（引号形式） |
mail@host |
否（@ 前面不是空白） |
裸 @ |
否（@ 后面要至少一个非空白字符） |
⇒ 所以准确说法是"词首 @ 后面跟任意非空白串都会被画成文件引用"。这个收窄很关键——按"任意文本"提，维护者会用 mail@host 反证你。
二、这是有意设计，不是低级 bug
packages/client/ui-reference/README.md:62 明写着 "without file discovery" —— 也就是说这个规则故意不看文件系统，纯粹的文本模式匹配。装饰侧是 ui-reference/src/client/FileReference.tsx:40（渲染成 <ReferenceChip appearance="file">），配 ui-primitives/src/user-text.tsx:37-55。
而且官方测试已经把这个行为钉死了：packages/client/ui-reference/tests/user-text-rules.client.spec.ts:70-76 里，'@"/" @/ mail@host prefix@a.ts @。 @' 这一串断言 0 命中，但 { text: '@name' } 断言得到 id: 'file'。
⇒ 所以你要提的不是"渲染错了"，而是"这个规则太宽，把明显不是文件的文本也吃掉了"。这个提法才有讨论空间。
顺便排除一个方向：这跟 Markdown 渲染无关。ui-primitives/src/markdown/parse.ts:26-31、:38-43 的 extensions 只有 gfm / cjkFriendlyStrong / math，没有参与这里的处理。
可以怎么改
在 match 之后加一层启发式，只有满足下列任一才当文件引用：
- 含
/或\（像是路径）； - 带已知扩展名（
.ts、.md、.json之类）。
这样 @name 不再成 chip，而 @src/index.ts 仍然成。代价是会漏掉一些真实场景（比如引用同目录下没有扩展名的文件），所以这是个取舍，建议在报告里写明。
user-text-rules.client.spec.ts:70-76 那条断言现在把 @name → file 固定住了，你的改动会让它红。这是预期内的，但要在 PR 说明里讲清楚，否则看起来像破坏了既有契约。README :62 那句也要一起更新。
边界
我核的是 origin/master = 1517a4dbca（2026-10-16，dsh-v0.2.1-alpha.5）。packages/client/ui-reference 与 ui-primitives/src/user-text.tsx 在最近两个版本之间未改动，所以这些行号是稳的。
另外你帖子里写的是"这个错误挺低级的"——建议去掉这句。它的行为是可测的、有测试固定的，用"太宽"来描述比"低级"更容易被接。
|
你可以看看其他平台的harness 不会出现这种，这本来就是不应该被渲染成 胶南的。 |
复现了，还能点开预览，然后再提示文件不存在，就有点离谱了😂 至少应该先判断一下是不是文件引用，而不是看到 @ 后面有内容就直接套上文件引用样式吧？
|
|
正确的做法是 @符号只作为触发 文件搜索弹窗的 触发器，真正选择完文件后进入输入框的应该是一个特定的包裹如： 
根据这种特殊匹配进行渲染，而不是针对@符号进行正则， |
|
或者 应该直接匹配 "@文件名[文件路径]" 这种特殊，通常其他harness 也是这么做的 |
正确的做法是 @符号只作为触发 文件搜索弹窗的 触发器，真正选择完文件后进入输入框的应该是一个特定的包裹如：
根据这种特殊匹配进行渲染，而不是针对@符号进行正则，