这里是 AnyBlock（后面简称AB） 作者，虽然这个话题会和该插件有点相关，但是：
- 不知道插件的也没事，基本不影响后面的讨论
- 不打算使用该插件或扩展语法的也能讨论，基本对笔记没污染，没装插件也不影响
- 如果后面对插件有兴趣，可直接第三方插件搜
Any Block，或给Github点Star：GitHub - LincZero/obsidian-any-block: A Obsidian Plugin. You can flexibility to create a 'Block' by some means. It also provides some useful features, like `list to table`.
效果预想
废话结束。我将为插件新增一个将列表转化为文件夹结构的功能，效果是这样的：
- md语法：
- 渲染成：
效果很简单：用/来表示目录，没有/就根据后缀名来判断文件类型并上图标，然后支持点击折叠（折叠必须有，有折叠才能够写上百个文件的目录结构时还能保持较好的阅读性），以及强制不允许换行！
这里的图标也可以不要，你可以在CSS将before伪类去除，然后仿照Linux的路径方式也是可以的：深色模式下蓝色表示文件夹、白色表示文件
其实AnyBlock插件本来就已经能够做到这一点，渲染后也支持文件夹的折叠，还支持目录或文件的备注，其实也能用于表示目录。但我个人还是认为非常不足，没达到我的期望。AB的 list2lt 原来的效果：
不足点在于样式不对不紧凑、还不能禁止换行（前两个还可以用anyblock的addClass处理器来解决这个问题）、还有不能很好地区分文件夹和文件、文件类型又缺少图标
语法的规定（目前想要征集的意见）
要用什么来表示一个目录呢？有三种方案：
- src/： 后面加
/。简称后/方案 - /src： 前面加
/。简称前/方案 - /src/： 前后加
/。简称双/方案
分别的效果大概是这样的：
- src/
- componment/
- utils/
- SuperButton.vue
- /src
- /componment
- /utils
- SuperButton.vue
- /src/
- /componment/
- /utils/
- SuperButton.vue
各自的优缺点
先给结论，我下面会解释这张图
(1) 后/ 方案
这也是一开始的方案
- 优点
- 最科学，最规范，路径拼接起来是绝对正确的！
- 可以表示linux的
根路径，其他两个方案则无法做到这一点
- 缺点
- 无ab渲染的话，纯文本不好看。特别是在AB语法里，是可以写文件备注的（如果你要记录文件夹结构，大概率是会写各个文件夹或文件的一些备注的，AB还支持多层备注）。
（关于纯文本可读性这点是否需要保持得非常NICE，经常会在群里看到争议，这里就不要吵，都对！）
前置： - /xxx， 文件夹备注1 - /xxx， 文件夹备注2， 备注2.2 - xxx， 文件备注 后置： - xxx/， 文件夹备注1 - xxx/， 文件夹备注2， 备注2.2 - xxx， 文件备注 - 无ab渲染的话，纯文本不好看。特别是在AB语法里，是可以写文件备注的（如果你要记录文件夹结构，大概率是会写各个文件夹或文件的一些备注的，AB还支持多层备注）。
(2) 前/ 方案
在 后/ 的基础上，将/前置。但其实这是比 后/ 更开始的方案。因为我一开始设计时就没想到用/这个符号，而是选择了另一个符号表示文件夹的图标，类似于这样：
- = 文件夹1
- = 文件夹2
- = 文件夹3
- 文件1
- 文件2
其实就是类似于前面有个折叠符号这种效果：
（但不能真的用这两个符号，> 在其他md软件会混淆成引用的，而∨不会打，V也怪怪的）
- > xxx1
- xxx2
- ∨ xxx1
- xxx2
这里主要是从图形来看，会更美观一点，还是举回刚刚的例子。前/在辨别一个项是目录还是文件，会更快更舒服！
其实主要是大量同级路径时区分度较低（如下，其实这里举了一个比较极端的例子，例子不极端效果不明显。一般来说先文件夹再文件是合适的。不过在Linux ls是可以选择先目录再文件，以及是纯按字母排序的，并且默认方案好像是按字母而非是否文件夹排序，这点与Windows的规则有所不同）
前置：
- /xxx， 文件夹备注1
- /xxx， 文件夹备注2， 备注2.2
- /xxx， 001
- xxxx， 001
- /xxxxxx， 001
- /xxxx， 001
- xxxxxxx， 001
- xx， 001
- /xxxxxxxxx， 001
- /xxxx， 001
- xxxx， 001
- xx， 001
- /xxxxxxxxx， 001
- /xxxx， 001
- xxxx， 001
后置：
- xxx/， 文件夹备注1
- xxx/， 文件夹备注2， 备注2.2
- xxx/， 001
- xxxx， 001
- xxxxxx/， 001
- xxxx/， 001
- xxxxxxx， 001
- xx， 001
- xxxxxxxxx/， 001
- xxxx/， 001
- xxxx， 001
- xx， 001
- xxxxxxxxx/， 001
- xxxx/， 001
- xxxx， 001
缺点：
- 正确性欠佳。路径拼起来是错的，为了美观而前置
/是否值得？这是一个需要深思的问题 - 如果我想表示这是个linux的
根路径，则无法表示
（也能想其他方法表示，不算大问题，但其他方案肯定没后/方案直接在前面加个/直观和方便）
(3) 双/ 方案
特点和优缺点和 前/ 差不多，美观性可能还会更好，但写起来会很麻烦。
最后的唠叨
三者各有优缺点，不过说是缺点，但如果不是太强迫症，其实大家的缺点都是可以接受的，三套其实都可用。只是这个东西可能会有主观性，我不想太草率。如果草率定下来了，第一批用插件这样写了，后续发现不合适就很难再做修改了，不然这段时间写的笔记都要全部重新修改。
另外，前面说了不用该插件的也能参与讨论。而不说插件的特殊渲染，我觉得仅仅是作为一种风格，也是可以平时这样去写的。如果以这个角度来看，可能会更多地站在文本美观性的考虑来想。
相反，如果是重度插件依赖症，文本美观性的权重会较低，反正都是看的渲染后的结果。
至于……而大家喜欢怎么写就怎么写？给一个切换的选项？……再说吧，我不想发展成这样。希望大家的选票结果能尽量一致……emmm最好是和我心里青睐的答案一致
投票就三个选择：后/，前/，双/。或有其他方案也可下面评论交流
定选，以及新增可选方案（编辑新增于08.03）
编辑这里的时候，其实投票已经结束了，结合在另外两个Ob群的意见，后置/ 方案以碾压式的选择获胜。
而我后来也想到了一种可选的方案：
一开始两种方式不能并存，是因为两套方案的解析规则是冲突的。前/ 在 后/ 语法里表示的是根路径。但是我可以用 ./ 来做一个前置标识。如下：
原后置：
- xxx/， 文件夹备注1
- xxx/， 文件夹备注2， 备注2.2
- xxx/， 001
- xxxx， 001
- xxxxxx/， 001
- xxxx/， 001
- xxxxxxx， 001
- xx， 001
- xxxxxxxxx/， 001
- xxxx/， 001
- xxxx， 001
- xx， 001
- xxxxxxxxx/， 001
- xxxx/， 001
- xxxx， 001
可选的前置标识：
- xxx/， 文件夹备注1
- ./xxx/， 文件夹备注2， 备注2.2
- ./xxx/， 001
- xxxx， 001
- ./xxxxxx/， 001
- ./xxxx/， 001
- xxxxxxx， 001
- xx， 001
- ./xxxxxxxxx/， 001
- ./xxxx/， 001
- ./xxxx， 001
- xx， 001
- ./xxxxxxxxx/， 001
- ./xxxx/， 001
- xxxx， 001
两种方式的解析不冲突，所以可以共存。前面有个 ./ ，这是可选的。
如果需要像linux默认ls那样按字母排序，文件夹和文件混杂在一起且文件较多，实在希望在文件名的最前面将目录与文件能更好地分割开，且文件比较多，可以临时选用这种方案。其他目录比较简单的情况，可以不用（按需使用）
- 优点
- 在上面说到的这种情况下可以临时选用，作为“可选项”来说很灵活。
- 确实能有效增加辨识度
- 拼接起来也是对的：/usr/./local/ === /usr/local/。语法解析时，我会将这种
./原地cd的符号给省略掉。
- 缺点
- 写起来麻烦，一个目录要用三个符号表示。所以一般不建议这样去做，只是作为特殊场景的可选项。
-
这个才是最致命的缺陷：
./其实是无含义的，并不是说这个表示的是目录，目录的表示还是以后置的/来表示。也就是说，如果你文件项这样写：./xxx.md（这种写法我就不去禁止说是语法错误了），我会将这一项看作是一个文件而不是目录。前面增加./来表示目录这一行为 —— 是约定而不是必须这样做。如果用户乱用，反而会带来书写混乱的缺点。