是全局格式化的意思，我们本来打算开发一个更加语义化的编辑器呢。Ficus 没有任何的版本控制功能，实在是非常不好意思，我们的笔记管理功能也不是对于现有笔记管理功能的加强，而是一个全新的设计，所以可能没法暂时满足您的需要，但是我们会在之后的开发阶段中考虑您的需求的。
反馈几个 BUG 和问题：
- 类似于
.png)，文件名带括号、空格的资源无法解析。 - 类似于
\s```sh，前面有空格的代码块无法解析。 - 大文件(200K+)被忽略了。（大概率设计如此。渲染大文件性能永远是个难题，但是没有提示就不太行，否则用户永远会担心文件是否丢失）
- 资源管理器显示滚动条时，能显示 resize cursor 但不可调节宽度。
- 从资源管理器跳转到文档大纲，再跳转回来，发现资源管理器没有自动定位。
- 正文的滚动条最小尺寸太小了，打开长文件后，太难点。
- 标签的关闭按钮太小，不好点。
- 启动不能指定文件夹，每次都要重新选择。
- 没有 Typora 文件名查找(ctrl+P)功能。
- 代码块编辑时不能高亮。
- 内存占用太高，打开几个文件，内存占用 700M+，最高能冲上 1G，比 Typora 大 2-3 倍（不过这就很难优化了）。
虽然细节打磨得不太好，总体上值得一试。
1 个赞
没看懂特点在哪里，不就是最常见的树形目录结构+标签吗，还是我遗漏了什么
非常感谢您的体验和反馈，我们尽力给出一个答复：
- 这个似乎是我们用的插件 lute 的特性，我们会想办法通过转义的方法解决一下。
- 这个和 1 差不多。
- 确实是 feature，我们会考虑改掉它的。
- 我们美工尝试去修。
- 这个尝试去修。
- 我们美工尝试去修。
- 我们美工尝试去修。
- 我们可以加上这个功能。
- 这个功能确实没有开发，可能来不及开发了。
- 这个确实没有办法，我们之后可能会继续开发 vditor 的即时渲染模式。
- 应该是内存泄漏了，在修了。
确实有树形目录结构和标签，您观察的非常正确。此外我们还提供了引用。这三种东西构成了文档个间的联系，此外，我们有一个特色是允许您转化这些关系，比如将同一个引用网上的文档赋予一个 tag，将同一个 tag 文档生成一个目录，以及相反操作之类的。
此外我们还有一些文档内的树形结构和多个文档的树形结构，也是比较特色的，欢迎您尝试体验。
哦哦，主楼没提“引用”呢，如果是特色的话建议编辑主楼详细介绍一下，不然看不出跟别家比有什么优势
1 个赞
联动下zotero咧不如？ 
请问具体是怎样联动呀
我把他安装放一个obsidian目录，发现还不错！
感谢您的评价，我们会继续维护这个项目的！