建议优化对插入行内公式时渲染逻辑

[mlzxy]

在什么情况下你需要该特性？In what scenarios do you need this feature?

目前，当插入行内公式时，一旦输入了成对的 $$，Siyuan 会立刻渲染内部的公式，无论用户是否输入完毕。

如下 GIF 所示，插入行内公式时，当输入 \ 会立刻抛出 KaTeX 错误，然而此时输入才刚刚开始

此时，要点击错误信息，打开编辑窗口进行修改

描述可能的最优解决方案 Describe the optimal solution

第一次输入行内公式时，不要立刻渲染，允许用户结束输入，即使 $ 已经成对。

描述候选的解决方案 Describe the candidate solution

No response

其他信息 Other information

No response

[mlzxy]

更通用地来讲，这是目前 Siyuan 编辑器在处理行内公式的输入时的关键缺陷：

编辑器会立刻渲染公式，无论用户是否结束了输入。 很多时候，我要输入一个公式，比如 [a, b], 我习惯先输入 $$, 然后在其中填补内容，但刚输入了 [ (此时内容为 $[$), 编辑器就把 [ 渲染了，此时我要打开编辑窗口才能继续写。

目前的 workaround 就是先输入 $, 然后输入latex代码，最后以$ 结尾。 用WYSIWYG的编辑器 比 写代码还要小心。

[88250]

其他行级元素也有这个问题，暂时无法避免，否则解析会有二义性。

可能只能改变输入习惯，比如使用 / 菜单插入元素，谢谢。

[mlzxy]

其他行级元素也有这个问题，暂时无法避免，否则解析会有二义性。

可能只能改变输入习惯，比如使用 / 菜单插入元素，谢谢。

这个问题非常严重，不只是改变习惯的问题

对于本 issue 汇报的问题，通过逐渐形成习惯来规避相对容易，比如先输入 $ 然后输入代码，再输入 $

但另一个 issue #5371 ，书写的时候经常要对文字进行修订，那么从左边插入公式一不小心就会爆一大堆错误，把格式彻底搞坏

解析有二义性，但从使用的角度至少很多竞品都解决了该问题：

• 我来拿 logseq 举例，他的做法是：编辑当前行时，不渲染行内公式，行内公式会在光标移开后再渲染。这个解法我觉得比
  Siyuan 当前一味的追求 “所见即所得的编辑” 体验好很多，而且逻辑很简单。
• 再说 Typora 和 MarkText，他们甚至从功能上看已经完美解决了该 “二义性” 问题。 希望开发者至少试用一下 MarkText 以及 logseq。

当然我尊重开发者的计划，但我想基于自己的使用经验指出，Siyuan 对于数学公式的编辑体验真的非常差，这说明一开始设计就没有把数学公式当作重要的功能对待。 如果 Typora 对公式的支持是 90 分，那么 MarkText 80 分，logseq 60 分，目前的 Siyuan 也就是 40 分。

为什么这很严重？听起来似乎不是所有用户都有写公式的需求，但事实上，Siyuan 这种知识管理软件，面向的本来就是“有大量复杂知识需要管理的用户“。因为对于普通用户，Siyuan 没有吸引力，他们更喜欢稳定易用的传统记录软件，如 OneNote。 这些 ”高知识量用户“ ，他们对于公式编辑的需求是远大于普通用户的。

---

如果真的无法解决公式插入的问题，希望能提供切换到 markdown 源码编辑的渠道。

[88250]

之前思源也是使用保留标记符的即时渲染模式，光标插入符离开之后才渲染。后来经过一段时间测试反馈，才决定改为所见即所得的。

前面我指的改变输入习惯是使用 / 来在左边插入元素，不使用 $。二义性问题其实在即时渲染模式中依然存在，举个例子：

输入：

foo $bar$

然后光标插入符移动到 foo 后输入 $b：

foo $b $bar$

这时候就会出现二义性，这个问题可以在编辑器层面解决，让用户看起来是正确渲染，但是实际上导出 Markdown 文件以后却是错误的。思源为了保证数据迁移（比如转换为 Markdown）的正确性所以在编辑器层面将解析问题暴露给用户。

之前说的使用 / 插入公式可以规避这个问题，因为使用 / 插入公式时会自动闭合 $，这样才能做到没有二义性。

如果你有更好的方案，欢迎讨论，谢谢。

[mlzxy]

之前思源也是使用保留标记符的即时渲染模式，光标插入符离开之后才渲染。后来经过一段时间测试反馈，才决定改为所见即所得的。

前面我指的改变输入习惯是使用 / 来在左边插入元素，不使用 $。二义性问题其实在即时渲染模式中依然存在，举个例子：

输入：

foo $bar$

然后光标插入符移动到 foo 后输入 $b：

foo $b $bar$

这时候就会出现二义性，这个问题可以在编辑器层面解决，让用户看起来是正确渲染，但是实际上导出 Markdown 文件以后却是错误的。思源为了保证数据迁移（比如转换为 Markdown）的正确性所以在编辑器层面将解析问题暴露给用户。

之前说的使用 / 插入公式可以规避这个问题，因为使用 / 插入公式时会自动闭合 $，这样才能做到没有二义性。

如果你有更好的方案，欢迎讨论，谢谢。

我做了一个 Siyuan 和 MarkText 的 Side by Side 比较，如下 GIF

可以看出，MarkText 也面临解析二义性问题，但当出现该问题时，MarkText 仍然允许用户继续编辑，从而让用户有机会消除该二义性。 因为二义性的出现，往往在一些编辑的中间状态。

而 Siyuan 没有给予这个编辑空间，我在左边已经不知道怎么修改了，其实只能都删掉。 我目前的 workaround 是在另一行写好了公式，从左边 Copy/Paste 进去。

[88250]

使用 / 插入公式吧。

[mlzxy]

使用 / 插入公式吧。

这个 workaround 我可以接受，但建议把该点放在 FAQ 或什么地方，告知用户。

因为这个缺陷（或特点）是 Siyuan 独有的，大量从其他编辑器来的用户依旧保有 $ $ 的输入习惯，提前告知会控制预期，减少 Surprise

[88250]

有道理，稍后加入 FAQ。

[mlzxy]

有道理，稍后加入 FAQ。

嗯，比如建议 Cmd+M 来插入公式，不推荐 $$

用快捷键习惯了后，效率蛮高的，这个 workaround 也不太糟。

[mlzxy]

参考其他编辑器，可以加一个设置，让用户选择是否开启 $ $ 语法

如果开启了可以使用，但会有上述问题，如没有开启，可以用 / 或 Cmd+m 来插入行内公式

[88250]

这个不只是公式，所有行级元素都有这个问题。

[mlzxy]

这个不只是公式，所有行级元素都有这个问题。

啊确实，inline code 也有，要用 Cmd+G 才能稳定输入。

[Godsing]

之前思源也是使用保留标记符的即时渲染模式，光标插入符离开之后才渲染。后来经过一段时间测试反馈，才决定改为所见即所得的。

前面我指的改变输入习惯是使用 / 来在左边插入元素，不使用 $。二义性问题其实在即时渲染模式中依然存在，举个例子：

输入：

foo $bar$

然后光标插入符移动到 foo 后输入 $b：

foo $b $bar$

这时候就会出现二义性，这个问题可以在编辑器层面解决，让用户看起来是正确渲染，但是实际上导出 Markdown 文件以后却是错误的。思源为了保证数据迁移（比如转换为 Markdown）的正确性所以在编辑器层面将解析问题暴露给用户。

之前说的使用 / 插入公式可以规避这个问题，因为使用 / 插入公式时会自动闭合 $，这样才能做到没有二义性。

如果你有更好的方案，欢迎讨论，谢谢。

能否考虑一下保留“即时渲染模式”呀？作为一个选项供大家选择😊

在新建公式的时候，通过快捷键来 workaround 也挺方便的。

但是，当要修改公式时，还需要用鼠标点击一下，没法做到全键盘操作，效率依然比较低。

此外，我还遇到一个问题，我在 typora 书写的大量文档，因为包含很多公式，在导入到思源笔记时，发生了一些错乱。当我需要手动调整时，很难预期实时渲染结果。

又比如，当要把 a $b$ c $ 的第一个 $ 去除时，就很难操作。

[mlzxy]

之前思源也是使用保留标记符的即时渲染模式，光标插入符离开之后才渲染。后来经过一段时间测试反馈，才决定改为所见即所得的。

前面我指的改变输入习惯是使用 / 来在左边插入元素，不使用 $。二义性问题其实在即时渲染模式中依然存在，举个例子：

输入：

foo $bar$

然后光标插入符移动到 foo 后输入 $b：

foo $b $bar$

这时候就会出现二义性，这个问题可以在编辑器层面解决，让用户看起来是正确渲染，但是实际上导出 Markdown 文件以后却是错误的。思源为了保证数据迁移（比如转换为 Markdown）的正确性所以在编辑器层面将解析问题暴露给用户。

之前说的使用 / 插入公式可以规避这个问题，因为使用 / 插入公式时会自动闭合 $，这样才能做到没有二义性。

如果你有更好的方案，欢迎讨论，谢谢。

我有一个思路，在这里分享一下。

思路：记录用户输入的最后一个配对符（如 $），来解决二义性问题。

该二义性问题发生于 markdown 既可前向解析，也可以反向解析，但在奇数个$（且数量>1）时，两种解析方向会产生不同的结果，如：

a $b$ c $d

可以被理解为 [a, $b$, c$d] (前向) 或 [a$b, $c$, d] (反向)。但显然，只会有一种是用户想要的解析结果。 但但从上述信息，我们无法知道哪个解析结果是用户想要的。

但是，如果我们记录了「哪一个 $ 是用户最后一个输入的」，也就是使得 $ 数量变成奇数的那个字符，假设用户自左向右输入，那么我们可以将 markdown 文本分成三段分开解析：

如 a $b$ c $d 中第一个 $ 是用户最后输入的，那么 markdown 文本可以切成如下三段：

1. a
2. $b
3. $ c $d

其中，第二段只包含最后输入的 $ 和下一个 $ 之前的内容，而第一段和第二段肯定保证了是偶数个 $，从而每一段都能被唯一地解析。

这个思路基于一个重要的观察：在一个所见即所得的 Markdown 编辑器中，使得解析出现二义性的配对符，肯定来自用户最新的编辑。

@88250 希望听取您的意见，谢谢！

[88250]

该二义性问题发生于 markdown 既可前向解析，也可以反向解析

只是 Markdown 解析的话没有二义性，是从左往右解析的。

[mlzxy]

该二义性问题发生于 markdown 既可前向解析，也可以反向解析

只是 Markdown 解析的话没有二义性，是从左往右解析的。

但前向解析是不能给出一直给出正确结果的，这个 issue 上面已经给出不少例子了

比如「跳回行首插入一个公式」

[88250]

一次性插入闭合标记符的公式应该没有问题。

[mlzxy]

一次性插入闭合标记符的公式应该没有问题。

快捷键的解法（一次性闭合）等效于：永远输入一对 $，从而不会出现奇数个 $。

这是个好解法，但对于上面 @Godsing 提出的一些高级需求就不能很好支持了。

当然这属于较高级的优化体验功能，Typora 显然做了（不知道是否用了类似上述思路），大量的新型 Markdown 编辑器如 Obsidian, logseq 也都没有，所以也不能说是一个明显缺陷吧。

[WingDr]

我有一个想法，针对上面 @Godsing 提出的第一个问题，也就是在创建完公式之后回头修改的问题。

可以在公式的周围做判断，如果向公式内移动光标，则视为点击公式，自动打开编辑窗口。

同样的，在公式中进行操作的时候，如果向公式外移动光标，则视为关闭公式编辑，关闭编辑窗口并移动光标。

但是还有一些要考虑的问题，包括所有公式应该只能在第一行向左向上或者最后一行向右向下才会触发退出之类的，但是依照这样的思路写起来应该比较简单，并且是在目前的规则范围内的。

对于第二个问题，我感觉这个是对markdown基本规则的问题，在typora上如果书写了 a$b$c$ 这样的语句，并且想保留 $c$ ，这本身就算在typora里面也会渲染错误。如果真的有这种需求，那么在siyuan里多几步 ctrl+x 和 ctrl+v 应该也可以接受，我感觉可以暂时不用针对这个提出新的规则或者修改架构之类的。

但是第一个确实是提升手感的重要问题，希望能够解决。

[88250]

@WingDr 最新的改进方案请参考 #5787

[Leeepu]

今天遇到了这个问题，发现以及可以在设置里开启这个功能了，点赞👍