跳至主要內容

样式增减规范

LincZero

样式增减规范

开发样式增减类插件时，建议执行此规范，以统一用户体验。

该规范基于用户交互体验设计，完全遵守可能会导致插件较难实现。
所以只是建议尽量执行，而非强制。

一些软件当前的形式

在设计规范之前，我们先来看看别的软件的规范是怎么样的。

图例:

  • 使用 [ 和 ] 来表示当前光标的选区：
  • 使用 --> 表示进行样式增减时，字符串的修改情况
  • 使用 <--> 表示操作是完全可逆的。增加样式时往右，减少样式时往左，变回原样

WYSIWYG 软件中 (支持局部源码)，以加粗为例：

Obsidian

(1) 中心测试

aaaa bb[]bb cccc <--> aaaa **bb[]bb** cccc
aaaa b[bb]b cccc <--> aaaa b**[bb]**b cccc

(2) 单词边缘测试

aaaa bbbb[] cccc --> aaaa **bbbb**[] cccc --> aaaa **bbbb**** cccc
aaaa []bbbb cccc --> aaaa **[]bbbb** cccc --> aaaa **[]bbbb** cccc
(导致错误格式，或无法取消。建议纠正，向 Typora 看齐)

(3) 符号边缘测试

aaaa []**bbbb** cccc --> aaaa **[]**bbbb** cccc
aaaa *[]*bbbb** cccc --> aaaa ***[]*bbbb** cccc
aaaa **bbbb**[] cccc --> aaaa **bbbb**[]** cccc
aaaa **bbbb**[] cccc --> aaaa **bbbb***[]* cccc
(导致错误格式，建议纠正，向 Typora 看齐)

Typora

(1) 中心测试

aaaa bb[]bb cccc <--> aaaa **bb[]bb** cccc
aaaa b[bb]b cccc <--> aaaa b**[bb]**b cccc

(2) 单词边缘测试

aaaa bbbb[] cccc <--> aaaa **bbbb[]** cccc
aaaa []bbbb cccc <--> aaaa **[]bbbb** cccc

(3) 符号边缘测试

aaaa []**bbbb** cccc --> aaaa **[]****bbbb** cccc (存在问题)
aaaa *[]*bbbb** cccc --> aaaa []bbbb cccc
aaaa **bbbb**[] cccc --> aaaa bbbb[] cccc
aaaa **bbbb*[]* cccc --> aaaa bbbb[] cccc

Obsidian Editing Toolbar (Obsidian 插件)

(1) 中心测试

aaaa bb[]bb cccc <--> (没有改变)
(无法自动扩展范围，建议纠正)

aaaa b[bb]b cccc --> aaa b[<font color="#c0504d">bb</font>]b cccc --> (没有改变)
(无法取消，建议纠正)

(2) 单词边缘测试

略，不会进行范围自动扩展，光标不选中内容时不会执行操作

(3) 符号边缘测试

均失败，不会进行范围自动扩展，光标不选中内容时不会执行操作

obgnail/typora_plugin (Typora 插件)

(安装插件后，点击左下角的 A (文字风格) 图标即可显示工具栏)

(1) 中心测试

aaaa bb[]bb cccc <--> aaaa bb<span style="font-weight:bold;">[]</span>bb cccc
aaaa b[bb]b cccc --> aaaa bb<span style="font-weight:bold;">[bb]</span>bb cccc

(2) 单词边缘测试

略，不会进行范围自动扩展，只会在光标位置创建一个空内容的标签

(3) 符号边缘测试

均失败，不会进行范围自动扩展，只会在光标位置创建一个空内容的标签

AnyMenu 的样式增减规范

两种环境、方案设计

AnyMenu 分带 EditorApi 环境和不带 EditorApi 环境两种。

  • 不带 EditorApi 环境时:
    软件只能获取当前选中内容，无法获取光标以外的任何文本，自然也无法进行范围自动扩展。
    此时的行为更倾向于 Obsidian Editing Toolbar 的文本颜色添加的行为，不选中则不进行任何操作。
  • 带 EditorApi 环境时:
    软件可以获取到编辑器的全文信息和光标选区信息，可以进行范围自动扩展。
    此时存在两种设计:
    • 要么行为更倾向于 Typora，提供非常友好的用户交互。
    • 要么更倾向于原来的方式，提供更一致的操作体验。避免在多个不同软件中，操作逻辑存在差异。

手动扩展样式生效范围的难点

而且如果不复用编辑器的一些底层逻辑，复用编辑器已经完成了的 Markdown 解析树，很难仅依靠全文信息和光标选区去手动进行光标扩展的。自己再解析一遍性价比也不高。

会有很多特殊情况。

  • 例如 \* 转义
  • 例如 * 在代码块/公式块/html代码中
  • 例如 ** 前后有/无空格时可能导致导致失效
  • 例如 * 的数量大于2
  • 例如多行内联：
    跨行合法加粗:
**aaa
bbb**

跨行不合法加粗: (补充，这里第一行也不应该被加粗，但仅在 ob 实时模式中，会被误加粗)
**aaa

bbb**

而且不同的插件都要自己专门去处理一下扩展范围点，比较麻烦。

例如在一个 "引用块包裹加粗包裹斜体包裹html内联代码" 的例子中，如果光标在最内层，两个插件分别可以取消加粗和引用块，那么他们就需要分别手动设计边界。大量的简单插件中都会包裹复杂的代码来应对复杂的生效范围扩展需求。

方案: 专门的扩展范围插件

感觉可以先弄一个专门处理这种东西的插件，可以以 md 范围区域为标准，用来扩展 (没有缩小) md 的选区范围。

从小到大可以: 内联范围 --> 块范围 --> 标题范围 --> 全文。

这样当你想重新选中 html 样式标签并进行取消和修改时，选择上会更方便和灵活。

  • 缺点: 操作时步骤数不能压缩到最小，不算最方便。
  • 优点:
    目前逻辑简单，易实现。
    多平台逻辑更统一。
    以后要增强再做强化的范围自动扩展时，可以复用代码。

左右问题

  • 规则1: 当 aaaa []bbbb cccc 光标一侧是空格而另一侧不是，则扩展至非空格一侧的词
  • 规则2: 当 *aaaa*[]_bbbb_ (假设这里不冲突) ，若左右均不是空格，则获取光标左侧字符所在的词

但是这里存在问题: 光标模拟操作的扩展选词中 (Ctrl+Left Ctrl+Shift+Right)，行为与规则1不同。

目前这里其实不是很好设计，即: 当光标左侧为空格而右侧不为空格时，该情况应尽量避免进行范围扩展，存在歧义

测试demo

内联的范围扩展主要针对以下 demo

## 范围扩展测试

start 前置 空格切割 **加粗** *斜体* <span style="color:red;">html标签</span> ==🟥高亮1== ==高亮2== 无空格**加粗**粗 `内联代码` ~~删除线~~ end

start 其他符号 __加粗__ _斜体_ end

start 多行情况 **加粗
加粗** end

start 单边错误 **加粗

start 转义 \**加粗\**
链接到当前文件 0
没有文件链接到当前文件