[Extra] 建议：相同一大类功能的选择器收归到同一个模块接口，以免用户难于选择。

[Linzeal]

1. 同大类的选择器收归到同一个模块接口，有助于用户使用

目前各选择器表现的很杂乱，如[list2table]、[2mdtable]、[2lt]、[2ut]、[2mdut]、[2tableT]，其实就只是列表转表格这一功能的不同样式表现，但看上去就有六种功能之多，用户难以选择。

建议：相同一大类功能的选择器收归到同一个模块接口，同一大类下的各特殊样式用参数来表示。当用户参数输入不正确时调用默认参数来渲染。日后要增加新的样式时也无需新增加一个选择器，多一种参数即可。

像上面这些列表转表格都可全部收归为[2table]，或用户使用更简洁的[2tb]，然后通过参数来指定特殊样式，当参数不正确时调用默认接口来渲染，例如：

列表转表格	模块接口	用户默认入口	转树表格	转MD表格	转树形可折叠表格	ut方法	mdut方法	转置
当前	无	[list2table]	[list2table]	[2mdtable]	[2lt]	[2ut]	[2mdut]	[2tableT]
建议	[2table]	[2tb]、[2tb()]	[2tb]、[2tb()]	[2tb(md)]	[2tb(lt)]	[2tb(ut)]	[2tb(mdut)]	[2tb(T)]

再如列表转各类图表，也可收归为一个接口：[2graph]：

列表转图	模块接口	用户默认入口	转流程图	转脑图
当前	无	[2mermaid]	[2mermaid]	[2mindmap]
建议	[2graph]	[2gr]、[2gr()]	[2gr(flow)]	[2gr(mindmap)]

等等诸类。

2. 接口统一后的关键词有助于识别是否是选择器，有助于排除意外的错误渲染

接口统一之后，选择器就有了几个固定的关键词。这个也有助于识别是否是选择器，凡是[ ]里与关键词不匹配的，统统不是选择器。可以排除很多意外的错误渲染。

#2

#2 (comment)

[LincZero]

列表转表格的种类

其实就三种，看正则

• list2(md)?table(T)?
• list2(md)?lt(T)? （不过其实lt的T不生效，树形表格无法转置）
• list2(md)?ut(T)?

md标识的问题见 #12，等解决完 #12 我就将他弄掉。
T标识也是很有用的（其实功能没做全），不仅能转置表格、还能将流程图从左到右变为从上到下、能将标签tab从顶部变为左侧、能将overflow从上下溢出滚动变为左右溢出滚动

识别是否选择器

识别是否选择器，我原来的设计中有另一个方案解决

关于头部标识的使用，如果太复杂，不利于用户输入。如果太简单，则特征化程度低，容易误选，而且用户想一键清除所有头部样式时也会变得困难。

我倾向于输入简单的方案。
但可能会有人比较倾向于稳定、容易标识、导出时更容易去除头部标识的方案，相对会损失一点输入便捷度。

在我原构想中，是加入一个可选的空处理器ab来解决，这个处理器不会做任何事情，仅仅用于标识。
[ab|list2table] 同 [list2table]，这个 ab 你加不加都行，如果加了就方便你自己筛选。
同时设置面板提供一个 严格模式 的选项，开启后如果头部标识不为 ab| 开头，则不选择……

自己还有很多做起来麻烦得一批的设计，issue也一堆……太累了，赶紧毁灭吧

你的方案

全局方案的话，我感觉有点长，其实如果是我自用的话，不考虑给你们用的话，我甚至想直接 l2t l2u l2lt。

但是一方面，这需要给不使用这个插件的人看得懂源码表达的是什么意思。所以头部信息要简明，不要太参数化（这又得考虑简明 和 简短及便于输入 之间的平衡，比如到底是 list2listtable 还是 list2lt，（我打算在下版中，修改为两种方式均能生效））

第二方面，无论是我想改成（l2t l2u l2lt）还是你想弄得比较长、参数化一点，虽然都可以通过自定义处理器解决，但还是需要一个比较适合大众综合使用的官方方案。感觉直接用一个独立的单词比较合适

[Linzeal]

1. 选择器的编排统一比是否输入简短更重要

在我原构想中，是加入一个可选的空处理器ab来解决，这个处理器不会做任何事情，仅仅用于标识。
[ab|list2table] 同 [list2table]，这个 ab 你加不加都行，如果加了就方便你自己筛选。
同时设置面板提供一个 严格模式 的选项，开启后如果头部标识不为 ab| 开头，则不选择……

你这个可选的空处理器ab+严格模式选项是个不错的办法。

至于头部信息，我认为信息的明确和统一要比输入简短更为重要。一篇MD文件写下来，写几个AB选择器的打字输入量那几乎就可以忽略不计了。因此头部信息的格式编排更侧重于要让用户容易记住，不会混淆。比如，当需要列表要转表格，他能非常容易想起来是l2t。而不是要去AB官网或参考文件去看，是l2t，还是l2ut，还是l2lt。

现在AB插件刚起步，以后AB的API接口成熟了，谁知道日后它会发展出多少种转化渲染类型，现在只是列表转表格、列表转图表、列表转时间线、列表转标签栏等几种，难道以后就不会有列表、表格、图表、时间线、标签栏之间两两相互转化渲染吗，以及其他开发出来的奇奇怪怪越来越多的类型？

因此，你在定处理器时就要分类好，并在介绍里，尤其是FOR DEVELOPERS里就要分门别类，以免最终用户混乱。同一个转换类型，就要让选择器的编排及关键词看上去像同一个类型的，用户才容易记，不会乱。

独立工具类处理器：

• addClass
• X
• fold
• scroll
• T （T应当从[2tableT]独立出来做为独立处理器）

转化类处理器（标记[X]为已实现）：

两两轉化	关键词	列表	表格	图表	标签栏	时间线	代码块	引用
转列表	list
转表格	table	[X]
转图表	graph	[X]
转标签栏	tab	[X]
转时间线	tline	[X]
转代码块	code	[X]						[X]
转引用	quote	[X]					[X]

所以需要在AB没太多转化类型之前就给选择器定好格式化的写法，以便日后扩展以及API扩展。如：
[源类型+2+转化类型+样式参数]

从用户角度，源类型往往需要省略掉，更应当由AB插件本身根据当前选择器的上下文来判断源类型，而不应该交由用户来定当前源类型是什么。这样变成：
[2+转化类型+样式参数]
（其实应该认为大部分Obsidian用户根本不清楚当前要操作的块是什么源类型，就算知道了，那在AB选择器里列表应该用什么字母表示，表格又要怎么表示？用户很头疼，根本不想知道。用户只想知道要转化的类型要怎么写。）

至于样式参数是否要像函数()参数那样的写法，就随便了，并不重要，反正只是你代码的处理方法不同，关键是看用户用哪种写的顺，用的顺。比如，列表转表格的可折叠样式，可以像2t(l)这样的参数化写法，你也可以直接去掉()用2tl这个写法，或加用-来方便辨识2t-l，等等，关键是2+转化类型要给用户固定体现出来，让用户易记不混淆，如下面这些写法都行：

2t开头	2t、2t(u)、2t(l)	个人觉得函数的这种()参数的写法最好，你代码好处理，用户更看的清楚明白， 没有什么特殊转化样式就想简单转表格的就简单写个2t， 要特殊样式比如可折叠的就写2t(l)。 若你实现了默认参数渲染，比如AB新版把2t(l)统一改2t(fold)了，那用户旧的2t(l)也能按默认的2t来渲染成简单的表格
2t开头	2t、2tu、2tl	这个与你现在的编排方案l2t、l2ut、l2lt很像，就是前后字母顺序改变了一下，使之有一个同样的开头，更统一，更容易被用户理解和记住，
2t开头	2t、2t-u、2t-l

2. 更好的办法是用户只需记住最简单的[2+转化类型]，然后点开右上角的转换按钮去挑选想要的样式并设为默认

其实，让用户记样式参数也不是好办法。源类型和样式参数？他们不喜欢去记！这两样都应当交给AB插件代码本身去处理。用户只需记住简单的[2+转化类型]，渲染后用户点开在右上角的转换按钮，按分类缩进列表弹出所有可转化渲染的样式，让用户可以切换挑选对比，当切换到某种样式觉得适合，就点该样式条目的勾选等类似的操作来设为默认，并由AB插件改写当前选择器变成[2+转化类型+样式参数]。这样，用户下次再次打开此MD文档，这个改写后的选择器[2+转化类型+样式参数]就能直接为用户渲染成想要的样式了。

所以，用户最喜欢的就是这个最简单的[2+转化类型]了，然后去右上角的转换按钮里去对比挑选他们想要的样式然后设为默认就行。

而懂代码的用户，他自然可以直接完整写[2+转化类型+样式参数]一步到位即可。

3. 统一编排后方便用默认样式来渲染，增加兼容性，减少AB插件更新换代的代价

这一套格式化下来，其实就是参数化，无非就是看用不用让用户写括号。不论你用何种编排方案，这些关键词一旦定下，用户开始使用后，后面就不好改来改去的了，不然新版AB不支持旧的处理器，用户以前所有操作过的文件就全部失效要全部重弄了。基于这一点，我前面有个建议：当用户参数输入不正确时调用默认参数来渲染。日后要增加新的样式时也无需新增加一个选择器，多一种参数即可。 若选择器编排统一了，就比如AB新版l2tu要改为l2tx了，那用户的旧文件的l2tu还能通过l2t来默认渲染。就像scroll处理器，没参数就按默认的460px参数来滚动。反之，若没统一，如l2ut要改l2xt了，那用户的旧文件的l2ut就只能失去渲染，用户只能全库查找替换旧选择器了。

4. 转置的T标识更适合独立出来让用户知道这是一个独立处理器T

T标识也是很有用的（其实功能没做全），不仅能转置表格、还能将流程图从左到右变为从上到下、能将标签tab从顶部变为左侧、能将overflow从上下溢出滚动变为左右溢出滚动

至于转置的T标识，我认为不要和l2t放一起好。你对T的规划，更适合像addClass、fold、scroll这样做为独立的处理器，因此要让用户知道这是一个独立处理器T。所以list2tableT应当变为 l2t|T，T独立出来使用。

[luqin2007]

不如直接加一串命令呗，选中一个列表直接根据命令转换成不同图，类似 Tabs 插件有个 Convert selected text to tabs

[LincZero]

开发计划

暂时的计划是，抛弃指令，使用一个独立的自然语言模块 (虽然目前这个模块完全靠穷举 x_x )

好处

1. 无插件环境下更好看，指令可读性更好，别人甚至不认为你打那串东西是因为开了什么插件，全当作你的个人习惯
   
2. 更具体的分类相关的工作，放在文档中进行，用文档来将类似的处理器归为一类。而不是在插件本身进行
3. 解耦、可自定义。别名系统到时改为可在设置面板随意配置，用户可以根据自己习惯随便选择一个名字代替原来的指令名

具体的实现方案

1. (目前选择，这两天会发布插件的下一版本就可以使用这种方式了！) 采用穷举策略，可以保持极高的稳定性，但依旧需要一点点学习成本。而且功能受限
2. (后面会替换成这种) 使用分词功能 (加入关键字版)。案例：客户说 [黑底红字的居中转置表格]，那么先经历分词，提取有用的信息，“的”这种没用的就去掉。然后需要调整顺序生成：[列表转表格|转置|黑底|红字]。
3. (估计用不了) 但是方式二没办法应对关键字缺失的情况，用户就不说 “红字”，他说 “红色的字体”……这种情况只能上AI了。但先不论AI可能需要本地或网络环境，另一个问题在于AI生成结果的不稳定性。可能这会儿他认出来了正常渲染，但另一会儿认不出来就不能正常渲染了。（当然可以让他先问AI再接转化后的指令写到指令头，但这样一来又不符合我一开始说的初衷：让指令尽量可读，让其看起来不像是这一行是为了插件而服务的，而是你个人的写作习惯。那如果不生成指令而是生成我说的第二点那种自然语言呢……似乎也不是不可行，有点蛋疼）

[luqin2007]

有没有可能，像 Obsidian Tabs 一样做一个命令，选中列表做一个弹窗选择需要的功能

[LincZero]

Obsidian Tabs 是哪个插件，有点印象但不确定，方便给链接吗？

最终效果应该类似在阅读模式那个下拉框吗？暂时没计划，想了想这会一些其他的前置工作：

1. 将剩下的几个计划的处理器做完的，等处理器的数量再多十几个（现在对一般用户来说，能常用到的不过五六个处理器，我不建议什么都用一点。感觉有按选项的时间早敲完命令了），等全部做完处理器数量估计再多十几个，感觉就不得不做这个功能了。
2. 文档都还没归类好
3. 像阅读模式那种下拉框感觉是不太好用。新增的GUI方式，一是想要优化交互操作，二是想要能够支持串联处理器。关于第二点，还需要额外工作，将一些list/json处理器做好并暴露出来

现在应急使用的话，要不用自动补全插件 Various Complements / Completr，将命令都放进去看看效果？然后敲list自动出 list2.... 的结果？

[luqin2007]

obsidian-tabs 这个。

加下拉菜单感觉用处不大，毕竟大部分情况都是选定一个视图就不变了。

tabs 在命令面板中添加了一条命令，可以将选中的内容直接转换为不同标签页。

[LincZero]

之前说想要规范这个，需要一些前置工作（详见楼上上）

当前前置工作的完成情况：

1. T后缀拆解了出来，重写了转置处理器，变成单独的处理器：transposition、transpose
2. 拆解一些独立处理器出来：list/json 等，现在也拆了，会多出一些中间处理器。
   如 title2list 可以用 title2listdata|listdata2strict|listdata2list 来代替、list2utT 可以用 list2ut|transposition 来代替。
   这些处理器会将list解析后的中间结果暴露出来，从而提高复用性和提供更灵活的使用方法。

需要在拆分后的基础上，后面文档再归类一下。然后再对照文档归类结果做AB块的辅助生成面板，应该就对了。

使用新的辅助面板，原来阅读模式下拉框那个东西就不要了。那个也没办法很好地在串联处理器下工作

不过另一方面，这种更细的拆分也给分类带来了挑战