AnyBlock V3 新版发布，新帖子在这：
这篇帖子后面就不要再回了，去新贴回复
bug有点多的插件发布了
作用：块转化、列表转表格/其他树类图、详见demo示例文件夹
_
https://gitee.com/LincZero/obsidian-any-block
10 个赞
这个Any Block插件牛逼！！！
尝试着只是在列表的上一行添加[list2table]，在实时阅览模式下列表立马变表格，渲染效果比MD自身灵活太多了。
最为关键的一点是，Any Block插件只是通过在列表的头部（即上一行）添加一个选择器，然后对该列表做了渲染效果，并不改写此列表本身以及MD文件的其他内容，不用在列表外添加代码块符号“``` ```”来包裹，也不将列表内容裁切转移到其他辅助文件中，做到了源数据的完整性和安全性。哪怕是Any Block插件不生效了或卸载掉了，整个源数据除了添加的用“[ ]”标记起来的选择器外没有什么不同，渲染起来也几乎与添加选择器之前一模一样，原来是列表的依旧会被MD渲染为标准的列表样式，不会变的乱七八糟的难于辨认，也不会对日后的阅读和编辑造成麻烦和困扰。Any Block插件这种在渲染的灵活多样性的同时还保障了MD源数据的完整性和安全性，这一点是最最重要的！！！
列表渲染为表格：
而在阅读视图里还能切换到其他更多渲染效果（要是在实时阅览模式下也能切换到其他渲染效果就更好了，一般都在实时阅览模式下工作，轻易不会切换到阅读视图和源码模式）。
切换更多渲染效果：
然后把插件在Github里demo目录下的3个使用示例MD文件直接复制粘贴到Obsidian中，看到了更多的选择器更多更灵活的渲染效果，比如列表渲染为标签栏、流程图、思维脑图等等。太强大了！
列表渲染为标签栏（当前选中标签没有高亮，完全不知道选中哪个标签了。截图中我选中了“linux”标签）：
列表渲染为流程图：
列表渲染为思维脑图：
编辑方面的便捷性不足和缺失
-
Any Block插件在渲染方面做到足够灵活、多样，在数据完整性、安全性上做到了足够优秀，但只做好了前半部分的渲染工作，尚需要在渲染基础上建立后半部分的可视化编辑工作。一个MD文件不单只是用来渲染阅读的，它需要不时的编辑更新。若是使用插件后会使编辑一样困难甚至更麻烦，会使插件的使用场景变得很小，不敢用。
-
编辑时在列表中的定位及插入、删除是个非常头疼的问题，尤其大列表。解决的办法是在渲染的元素上增加控件，点击控件可选择编辑、增加、删除等操作。让程序代替人眼人手去MD的源数据上去定位去操作。
-
比如，列表转表格。小列表目前还好，但小列表都有可能随着数据增加而变成大表格。而大列表编辑起来太费劲，比之MD自身用”|“和”-----“格式化的表格，列表形式转换的表格非常难于找到要修改的单元格，而更困难的是插入列和删除列。要插入列就要去列表每一个行中定位到需插入的地方增加”|“或增加子列表，极其不好定位，若列多了，挨个行进行定位和插入，非常的繁琐。删除列也同样如此，盯的眼睛疼。
解决的办法是在渲染的表格上增加单元格控件，比如点击任一单元格的控件可选择编辑、插入/删除列或插入/删除行等操作，点击表头和首列任一单元格的控件还可选择锁定表头、首列的操作，等等。若Any Block插件有这样的便捷编辑操作，从编辑到渲染形成了完整的工作流，列表完全可以替代MD自身用”|“和”-----“格式化的表格。 -
比如，列表转流程图。同样，若能在每个项上增加控件，点击控件即可选择编辑、删除、增加子项、增加同级项、增加上级项等操作，也免去了编辑时要到列表里定位的痛苦。
-
赞！希望Any Block插件早日上Obsidian社区插件市场！
5 个赞
谢谢，本来想着有空再写图文介绍，居然有人帮我写了 
1 个赞
因为你懒！ 
当然，介绍图文你可以不写，但插件要勤快更新，早日上Obsidian社区插件市场，让更多的人可以用到你开发的优秀作品。
我上面的介绍图文你可随便用，无版权。
1 个赞
真的很不错的插件！
优秀优秀!! 这个插件很需要!
Any Block插件实际使用时的问题
中午忙完也没时间午睡了，就想着实际运用一下Any Block插件。选了一个大表格，改为列表后经Any Block插件渲染，效果很完美，但想编辑一下这个表格，问题来了。编辑起来太费劲，编辑得眼睛疼。因此写了Any Block插件的不足之处，并更新到前面的介绍图文中了。希望后面能在渲染的基础上增加一些控件以便于编辑，让Any Block插件形成从编辑到渲染完整的工作流。
编辑方面的便捷性不足和缺失
-
Any Block插件在渲染方面做到足够灵活、多样，在数据完整性、安全性上做到了足够优秀，但只做好了前半部分的渲染工作，尚需要在渲染基础上建立后半部分的可视化编辑工作。一个MD文件不单只是用来渲染阅读的，它需要不时的编辑更新。若是使用插件后会使编辑一样困难甚至更麻烦，会使插件的使用场景变得很小，不敢用。
-
编辑时在列表中的定位及插入、删除是个非常头疼的问题，尤其大列表。解决的办法是在渲染的元素上增加控件，点击控件可选择编辑、增加、删除等操作。让程序代替人眼人手去MD的源数据上去定位去操作。
-
比如，列表转表格。小列表目前还好，但小列表都有可能随着数据增加而变成大表格。而大列表编辑起来太费劲，比之MD自身用”|“和”-----“格式化的表格，列表形式转换的表格非常难于找到要修改的单元格，而更困难的是插入列和删除列。要插入列就要去列表每一个行中定位到需插入的地方增加”|“或增加子列表，极其不好定位，若列多了，挨个行进行定位和插入，非常的繁琐。删除列也同样如此，盯的眼睛疼。
解决的办法是在渲染的表格上增加单元格控件，比如点击任一单元格的控件可选择编辑、插入/删除列或插入/删除行等操作，点击表头和首列任一单元格的控件还可选择锁定表头、首列的操作，等等。若Any Block插件有这样的便捷编辑操作，从编辑到渲染形成了完整的工作流，列表完全可以替代MD自身用”|“和”-----“格式化的表格。 -
比如，列表转流程图。同样，若能在每个项上增加控件，点击控件即可选择编辑、删除、增加子项、增加同级项、增加上级项等操作，也免去了编辑时要到列表里定位的痛苦。
-
[bug] 列表转表格时列表中的行内代码符”` `“无法正确渲染 已经同步提交到Github：
列表转表格test
- 列表中有行内代码符
` `无法正确渲染 - 列表中代码符
` `里有<符号时渲染出错 - 复选框列表的勾选框无法正确渲染
测试环境：
- Windows 11 22H2
- Obsidian 1.1.9 沙箱仓库中仅安装Any Block插件1.2.4
说得很不错。我补充一点：你可以不把AB当成一个插件来看，而是多个插件。甚至可以理解为AB语法的范围选择器是一种对官方api的扩展接口
- 核心是AnyBlock，
AnyBlock的功能是提供了比代码块渲染registerMarkdownCodeBlockProcessor更强大的接口
_ - 列表转表格或是其他树形图可看作是一个个其他的插件，
就像是在```后面增加ad-note、-tx-、chat-view、mermaid这些处理器一样，是同质的
_ - 所以我希望的是，可以有更多依赖于AB的插件开发出来。
（就像很多插件依赖于安装dataview、style setting运行）
未来你可能会在github上看到许多依赖于ab的插件- 有list2editabletable（可交互编辑的表格，like
table enhancer） - list2editablemindmap（可交互编辑的流程图，like
enhamcing mindmap） - 再或者是mermaid/tab等等（脑图、标签栏）
- 或者更多，例如我暂时完全找不到头绪的代码块转简易文档/代码大纲/可折叠代码
- 例如一些特殊需求，加
todo、tobug、books/movies、Q&A、heimu、fold if overlength等极具个性化需求的插件
反正，要实现的东西实在是太多太多了
_
- 有list2editabletable（可交互编辑的表格，like
- 其实这是一个非常适合开源的项目，
要把处理器做得齐全就相当于要同时开发和维护十几个插件项目（而不仅仅是一个），我一个人的力量是有限的不可能的，所以我开源了出来，并会把在短期内将重点放在接口优化上面和编写接口文档上
_ - 如果在其中遇到合适的有依赖AB功能的插件，可能会考虑收录内置，像现在内置的列表转表格/其他树类图一样，但不会将所有东西都收录在内。
例如这版插件，我为了思维导图这一个功能，重复导入了最新版mermaid另加一个mindmap的包，使得插件大小由200KB变为了9MB+。
这可能会让一些不会使用思维导图的人有意见了，其实如果不是我考虑到未来ob官方会更新mermaid版本，然后我可以将这个包给去除掉变回正常大小，我可能也不会内置这个功能吧。
同理，其他处理器可能还会借助一一些其他包，例如markmap.js来提供更强大的导图功能、使用doxygen包来解析代码、或者会使用vue/react/svelte等框架辅助开发插件
不可能都塞进去的，以AB为核心，其他处理器分流变为多个插件供用户自由选择才是更自由使插件不变得臃肿的做法
2 个赞
非常赞同！！！你可以把这些设想规划在AB的readme里体现出来，比如增加for developers章节。
另外，你在Github上对前面issue的回复已知，我明白了list2mdtable和list2table的区别及使用场景。
但我觉得在同一功能上给用户提供多个选择器，什么分为[list2mdtable]、[list2table]、[2lt]等等诸多个，不太适合，纯属在人为制造问题。因此在issue里回复了一些个人看法，并同步到此处以方便大家讨论。
不论Any Block是否计划要做为一个平台提供API给其他插件，届时Any Block的用户肯定是世界各地、各式各样，一定会有很多用户不会去深入了解各选择器的使用要求，就会用着[list2table]但单元格里有MD的内联样式；或着是一开始有耐心去阅读使用须知从而知道各选择器的使用要求，看单元格没有MD的内联样式就使用了[list2table]选择器，但一段时间后单元格修改时无意间添加了MD的内联样式，这就出现了渲染出错，若是做为API数据出错就更麻烦。你无法预知用户会选择什么选择器、输入什么内容，性能更不是首要的，稳定及容错才是首要，性能待稳定后再去优化。因此，接口应当统一，少给用户做选择，就算有选择的事情也应当尽量交由代码代替人类去做。
而且从用户角度思考，用户只是想转换为表格，不会想去思考这是转mdtable、那是转listtable、那是转ut，懒得去费那脑筋。甚至用户连要把什么来转为表格的东西都不在乎，别管我是要把列表转表格，还是要把脑图转表格，反正就一个，只在乎简单的目的：[2table]。
因此，个人建议在用户层面无须提供多个同类的选择器，应当合并做减法，同功能只提供一个统一选择器即可，并提高容错。如转为表格，统一使用[2table]，一律默认按同时有MD的内联样式和html语法标签以及可折叠来处理。如转为脑图，统一使用[2mermaid]，等等。至于性能优化，放到代码中去选择去优化，比如[list2mdtable]、[list2table]、[2lt]等等选择器藏在代码里，供程序员和API使用。
想问下，阅读模式下该插件的功能是不能开启吗？在实时渲染下是能正常使用
实时和渲染模式都可以用的。
先别下beta版，beta版是给实时模式加了一部分功能，但还未给渲染模式加。
甚至觉得这个直接内置，就像admonition一样
另外不知道能不能增加转换html表格的功能，网上有些表格是真的没办法转换为md的表格
在todo里，但不会这么快上这个功能
真的期待
另外我在英文论坛里放了这个插件的帖子，希望可以
版本是1.3.1不是beta版本
直接卡第一步了，无法正确加载插件，哭了
第一次遇到这个用户反馈，和当前插件或当前打开的文件冲突？
无法判断，看看新建一个ob库是否能加载插件，或者提供下软件和插件版本？
