功能价格文档博客
获取 mote
← 博客
设计·2026年7月31日·阅读需 5 分钟

只在光标所在的单词中显示 Markdown 符号的理由

你是否有过这样的经历:只是为了修改一个粗体词语而放置光标,整个段落却都恢复成了 Markdown 源文?mote 只会显示光标所触及的那个语法结构的符号。

m
mote
在实时模式中,插入符触及粗体语法结构,只有其标记恢复为源文显示。同一行的斜体和行内代码仍保持渲染后的状态。
在实时模式中,插入符触及粗体语法结构,只有其标记恢复为源文显示。同一行的斜体和行内代码仍保持渲染后的状态。

在实时模式中,光标的位置就是画面。Markdown 符号平时应该隐藏,只有修改时才出现。

那么,要怎么判断何时是在“修改”呢?

mote 最初以整个段落为判断单位。只要光标进入段落,就会显示该段落的所有符号。

实现方式很简单,但画面十分杂乱。明明只是为了修改一个粗体词语而放置光标,三行之后的链接和代码却也变回了源文。眼睛只看着一处,整个段落却都动了起来。

关注的不是段落,而是语法结构

现在,mote 只显示与光标接触的语法结构。

只有当光标位于起始符号和结束符号之间时,源文才会出现。符号正前方和正后方也包含在范围内。因为把光标放在那里,同样也是想要修改该语法结构的操作。

只要光标移开一格,就会重新恢复为渲染后的样子。出现和消失时使用 120 ms 的不透明度过渡。因为这是有明确起点和终点的过渡,所以结束后不会留下任何东西。

即使一个段落中同时包含粗体、链接和行内代码,其他部分也不会移动。只有光标触及的语法结构会发生变化,重新绘制的范围也仅限于那一行。不会重新解析整个文档。

斜体、粗体、删除线、高亮、下标、上标、代码、公式、链接、图片和脚注引用都采用相同的原则。

行首符号略有不同。#>决定整行的性质,因此无论光标位于行中的什么位置,它们都会以相同的样子显示。相比之下,列表的- 只在光标位于符号上时显示。越过空格移入正文后,它会立即恢复为项目符号。

选择文本时,也只有与选区重叠的语法结构会变回源文。因为如果只选择了三个字,整行却都变成源码,反而更难看清究竟选择了什么。

符号也会沿用文字的样式

显示出来的符号会完整沿用该语法结构的样式。

粗体文字的**会以粗体显示,斜体的*会保持倾斜。删除线的~~上也会画上删除线。

光标触及斜体语法结构,只显示出两个*的画面。星号也一同倾斜,同一行的粗体文字和行内代码仍保持渲染后的样子。
光标触及斜体语法结构,只显示出两个*的画面。星号也一同倾斜,同一行的粗体文字和行内代码仍保持渲染后的样子。

以前,所有符号都以灰色显示。于是,当光标放到粗体文字上时,词语看起来就像被关进了灰色括号里。当前正在修改的文字是粗体这一信息,也会暂时消失。

让符号沿用文字的样式后,含义变得明确了。词语会继续以粗体显示,而星号只作为标示其范围的符号保留下来。

灰色只用于#>、项目符号等块级符号。因为这些符号说明的是整行的性质,而不是文字的性质。

原则很简单。附着在文字上的符号要像文字的一部分,定义整行的符号则要像背景一样显示。

只有星号会自动配对

输入一个星号时,会同时生成一个结束星号。再输入一个星号时,它们会扩展为用于粗体的一对符号。

写完内容后输入结束星号时,不会生成新的符号,而是越过已有的符号。星号一次出现四个的问题,也通过这条规则得到了解决。

不过,在文字或星号正后方输入的星号,会被视为用户正在手动结束语法结构。此时不会创建配对符号。

下划线和波浪号不会自动配对。因为它们可能会妨碍输入snake_case__init__~/路径这类日常使用的文本。只有在包裹选中文本时,它们才会成对工作。

插入符应该比文字更不显眼

最初,插入符使用的是作为强调色的蓝色。现在则使用与正文相同的墨色。

蓝色竖条很适合简短的输入框。但在文档中,文字才是主角。插入符只需要告诉用户写到了哪里就足够了。强调色只保留给选区和搜索结果。

宽度通过将插入符高度除以正文墨迹高度,再四舍五入为整数来确定。正文中得到的是 1 px,只有在大标题中才会增加到 2 px。如果直接使用小数宽度,它就会分散到两列像素上,不仅不会变细,反而会显得又粗又模糊。

高度跟随的不是行距,而是文字高度。正文为 18 px,h3 为 24 px,h2 为 29 px,h1 为 36 px。仅看插入符,也能知道光标是在正文中还是在标题中。

并排放大标题和正文插入符的画面。h1 的高度为 36 px,正文为 18 px,正文插入符的宽度为 1 px。
并排放大标题和正文插入符的画面。h1 的高度为 36 px,正文为 18 px,正文插入符的宽度为 1 px。

闪烁被记作“空闲状态下不放置重复源”这一规则的唯一例外。窗口失去焦点后,闪烁会停止,选区也会退至 45 % 的 Alpha 值。

位移被保留了下来

符号出现时,后面的文字会稍微向后移动。我们决定不消除这一移动。

我们也测试过持续以浅灰色显示隐藏符号,以此预留空间的方法。但粗体文字旁会留下灰色残影,删除线也会伸出词语之外。结果成了一种既不是渲染画面、也不是源文的别扭状态。

不过,对于像项目符号和待办事项方框这样带有绘制图形的行首符号,会按照源文与渲染结果之间的宽度差移动整行,因此即使符号显示出来,正文文字也不会移动。标题的#和引用的>则保留为推动正文的方式。这是因为我们认为采用这种方式的编辑器更让人熟悉。

链接的地址可能很长,因此画面变化也可能更大。所以平时只显示链接文字,并在末尾附上一个小箭头。可以知道它是链接,但地址只在修改时出现。

如果需要准确查看源文,可以使用源码模式。实时模式并不是显示所有符号的地方,而是只打开当前需要修改之处的地方。

mote 不会猜测用户的意图。光标位于语法结构内时就显示符号,位于外部时就隐藏。猜测正确时很方便,但猜错时却很难知道原因。只使用位置这一项标准,就能始终预料结果。

决定何时显示符号,归根结底就是决定让用户的目光停留在哪里。

← 较早让符号出现时文字也不会抖动的方法较新 →原样保留手工输入表格的表格编辑功能
通过RSS持续关注。
只留下文字
简体中文
© 2026 mote