Composer 坐标与序列化¶
草稿存储拥有 Markdown,而 Tiptap 拥有编辑文档。富文本设置会改变已安装的扩展,因此切换该设置会从存储的草稿重新挂载编辑器。纯文本模式必须保留格式标记的字面形式。富文本模式保留空白和 chip 来源,但会将支持的定界符规范化(__ 到 **,_ 到 *)以及复选框大小写([X] 到 [x])。
存储游标不是 ProseMirror 位置:折叠坐标将一个 chip 计为一个字符,展开坐标按其源文本计数,而 ProseMirror 还会计算块边界。将转换逻辑保留在文档模型中。
空段落需要真实的光标位置,即使它们不包含任何文本。显示在样式文本旁边的标记是装饰,因此它们内部的偏移量会被限制到文本边缘。
仅在受控文本改变时才替换编辑器内容。因光标移动而替换内容会创建撤销记录,并重新生成引用标识。待处理的引用弹出框必须等待所请求的草稿到达编辑器后,才能定位其 chip。
富文本任务通过原生编辑器命令拆分,以便标记和 chip 都能保留下来。纯文本列表使用存储编辑。换行符会变成段落拆分:否则,末尾的硬换行似乎需要按两次。程序化移动必须显式地将光标滚动到可视区域内。
剪贴板文本必须来自 Markdown 序列化器,而不是 DOM 文本:chip 标签省略来源,标记装饰也不是内容。如果存在结构化上下文记录,它们会伴随该文本。粘贴会补全 chip 的尾部定界符,并在直接于文本后插入 chip 时添加前导边界。
块级节点(围栏、列表、引用、分隔线、标题)将其确切的 Markdown 定界符保留为节点属性,因此往返转换是字节级完全一致的,并且定界符内部的偏移量会像任务和样式标记一样限制到块的文本。序列化器只写出语法允许的内容:引用包含段落,列表包含段落和列表。因此,块只能在顶层段落处形成。输入规则会检查这一点,并且 Tiptap 自带的块级组合键(Mod-Shift-8、Mod-Alt-c 等)已被移除,因为嵌套一个序列化器无法写出的块会导致其文本从存储的草稿中丢失。列表语法与 composer-list-continuation 中的纯文本模式续写语法一致;保持两者同步。
按下 Enter 会发送,因此 handleKeyDown 中的围栏处理必须在发送处理程序之前运行:如果在发送处理程序之后才检查,围栏永远不会打开,围栏内的换行也会把草稿发送出去。
本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 t3/t3code