图片来源于 DeepSeek。是一个当前 DeepSeek官方觉得优雅的一种大纲功能部分。即大纲以低干扰形式融入编辑区，仅占用少量空间，并在鼠标交互时展开显示详情。我只能说这是一个很有创意的设计,真的是百花齐放。
哈哈，看到了感兴趣的话题，忍不住参与了一下。
1 个赞
很多人入门
Markdown编辑时都用过Typora，因此会自然期望其他软件也能作为基础的文件查看编辑器,目前新来的一开始就养成库习惯的始终是少数，时间还不够。
确实如此，Typora 更像是“记事本”或者“Sublime”，可以作为一个「打开方式」，随便查看/编辑任意的文本文件。
但是 Obsidian 这种「基于库」的就要强势很多——甚至没法直接“用 OB 打开某个文件”（这似乎也会是一些新人的疑惑点）。
相当于想用它就得全盘接受用它构建一整个库。
整体有利有弊，好处是库内的文件得以轻易互相链接，坏处是上手需要更多理解成本，而且感觉“不够灵活”。
试想如果黑曜石能承担
Markdown编辑器的职责，做到点击文件直接打开编辑，那对养成Typora使用习惯的用户来说，就已经实现了一个体验升级。
感觉这个应该有生之年看不到，因为「基于库」算是它的底层逻辑（。
只是单个文件编辑的话，Obsidian 的体验未必比 Typora 好多少。
优势发挥不出来，劣势又尽数体现。
很多笔记软件自称是“知识管理工具”而非
Markdown编辑器，却连打开txt都不支持预览。明明底层用的是CodeMirror这类编辑器，txt与Markdown都是明文，有何本质区别？只支持Markdown反而更像在暗示自己就是md编辑器 。更何况像黑曜石这样支持各种画板等高级功能，却连txt都不支持，未免有些荒诞。
哈哈哈哈哈确实又是一个我也忽略了的“痛点”。
是有不少人有这个需求的，而且也确实有几个插件是解决这个问题的——正如原帖中绝大部分的 features 一样：官方不做+用户需要=用户自己做
前面的几点结合起来，其实让我又有一个感想：
Obsidian 像是一个全屋管家，你享受它带来的好处的前提是你住在它给你搭的房子里。
它也只在自己的 Vault 里能发挥能力，一旦去别的地方就没什么优势。
这其实是带有一些强势性的，或者说，需要培养用户的使用习惯。
我猜测从官方视角看也一样——你如果使用 Obsidian 管理库，你从头到尾不会出现什么「创建出 txt 文件」这样的情况，自然也就不需要考虑对 txt 文件的支持（哪怕技术上完全可行甚至比较容易）。
他们的核心定位真就很简单：一个 Markdown 编辑器。
其他超出范围的需求，大部分都不会给予太高优先级。
这个在 少数派 那边也有类似设计的大纲目录，很漂亮：
相对应地——
也有群友开发了类似的 OB 内大纲插件：
likemuuxi/obsidian-sspai-toc: A floating toc of contents inspired by Sspai.
所以总的来说，虽然我对 OB 的原生体验有一些微词，但是插件社区实在太完善了，整体体验也就没啥毛病，这类高度定制化还是很爽的。
当然，我理解并尊重。用户最初接触的往往是软件官方的设计理念，在用户期望与官方路线尝试融合的过程中，会有颇有微词也在所难免，这几乎是必然的，毕竟很难事事尽如人意。
从黑曜石当前在笔记赛道中的位置来看，它显然已经走出一条属于自己的路。我个人也认同它所采取的态度：一个健康的软件生态，需要有主导者坚持自身的核心理念，并有选择地吸纳反馈，而不是全盘接纳以至于偏离最初的定位。
1 个赞
其实这些限制未必无法突破，更多是理念选择问题。举个例子，很多用户希望编辑好的文档在导出为 Pdf 或普通 Markdown、或在其他笔记软件中打开时，仍能保持几乎一致的视觉效果。可一旦某个软件提供了过于强大的扩展功能（比如实现复杂布局、自定义链接别名等），这种期待就难免落空。
一旦出现这种体验断层，用户自然会感到落差，同时也无形中被限制在了该软件之内。此时即使源文件仍是文本格式，也可能因为依赖了特定语法而难以在其他环境中还原。这虽然勉强实现了“数据可掌控”，却已违背了“避免被私有格式绑定”的初衷。
现实中，面对新奇强大的编辑功能，大多数用户很难保持克制，最终往往只能妥协到保存为可读的源文件。但在转换格式或迁移时，不得不承受一定的信息损失。这几乎是个无解的死循环。
我看思源就有类似分栏，我没具体了解其在不同迁移形式下会是什么样子。并且这种其实感觉也是违背了黑曜石官方的理念。
从某种角度上来说，我们可能期待的是一个包含以简洁易用为核心理念的这种离线优先的笔记工具，当前的帖子所包含的理念完全符合这个意图。
思源已经是 json 格式了，想做啥拓展都会容易很多 ¯\_(ツ)_/¯
包括他们还支持像是「块属性」之类的 feats，这些在 OB 里全是需要用奇技淫巧才能实现的。
因为纯文本（md）对于 文字块级的操作和属性、文本颜色 以及 复杂布局 就是天生瘸腿。
我其实在想，以后会不会有那种完全放弃源码显示模式的 MD 笔记软件,即当然还是可以用键盘打标记，只是在编辑时，格式源码不会特意显示出来。
对于各类输入和快捷键符号，我不确定这对新手而言是否本身就构成使用门槛——你可能觉得这不算什么，但实际上很多早期习惯使用 WPS、Word 的用户，并没有形成这类操作习惯。
此外，关于“选中文字后是否显示源码”这一点，不同用户也有不同看法。我注意到这类讨论其实早有源头，早在 B 站某个往年关于笔记软件评价的视频里 BV1CZ4y197CX，评论区就出现过不少分歧。
因此我认为，当前这种混合形态的所见即所得编辑器，已近乎一片成熟的红海。这就引出了另一种类型： 格式完全不用手动输入标记来调整，编辑时也根本不显示源代码。
例如，输入一段文字后，用户可以用鼠标圈选想要加粗的部分，顶部随之弹出格式选项。这个操作对习惯键盘输入源码的用户来说可能反直觉，并且需要同时操作键盘和鼠标，但对一般用户而言，反而可能更符合他们的使用直觉。
再比如图片这类典型对象：常见处理方式是鼠标悬停时显示路径，或切换显隐状态，整体容易产生跳动感。不如改为将路径信息悬浮显示在图片表面，减少界面跳动。
就我个人而言，我更适应纯键盘操作模式，但我推测，如果是真正的新手，尤其是那些不习惯只依赖键盘的用户，这套逻辑或许会更自然。说到这，我联想到 Linux 发行版中平铺窗口管理器与常规桌面管理器的区别：Linux 世界里很多设计极力推崇纯键盘操作，这固然很酷，但这类模式注定无法适合所有人。
确实，思源那里可以任意拓展，但就迁移成标准 Markdown 源文件来说，我估计还是会不太一样，即很难做到和编辑时看到的视觉效果完全一致，多少得有信息损失:)笑。
认同的。但是我可是观测到了大批源文件理念的用户，貌似对于文件的掌控欲才是最大的事。
听起来就像是 Notion？
或者说 Octarine 似乎也已经很接近了，大部分样式加进去之后，就不会再显示出原始符号，删除也是直接一起删除。
关于“选中文字后是否显示源码”这一点，不同用户也有不同看法。
是呢，我也见到过不止一次有人觉得「显示符号很烦」的。
只能说 md 就是这个样子，接受不了的话还是换软件比较好 XD
我最开始知道这东西记得是在好久之前了，就是在说它体积小。我特意记得我当时在推荐帖子下面留言，软件体积小的好处具体是什么？然而至今也并没有人回复我。
是吗，我还以为 obsidian 的吸引力在于花里胡哨的插件呢（
的确是这样。我最近也经常想到这一点。Obsidian 宣传 file over app，但是它仍然是带有一定妥协性质的。尤其最近官方推出的 canvas，bases，都增加了数据迁移的难度。不过再往前看，双链本身就是这样一种存在。Kepano 自己是很少有文件夹的，觉得这样是不受文件夹束缚，也更加利用了 Obsidian 的特性，但是这样又何尝没有降低库的互操作性呢。
我自己曾经为 Obsidian 开发过一些插件，其实并不是什么新奇的 idea，而且明明已经有很多更成熟，更丰富的插件存在了。但是它们都是不 file over app 的，也就是，假如某一天我需要停用 obsidian ，去用其他 markdown 编辑器，数据是完全不可读的。我就根据 file over app 的理念重新写了插件。
下载尝试的阻力小 
你跟我说这玩意儿2个G的话我可能就懒得尝试了，从而也不会有这篇文章x
这不就是富文本了嘛（
或者说，markdown 编辑器当然可以通过很多辅助功能看起来像是富文本编辑器一样工作，但是反过来，富文本编辑器也可以去优化自己的 markdown 导出功能。但是无论是朝那个方向努力，都存在着某些限制，而且看起来不像是为一个很大的用户群体准备的。
然后就说到这，这或许的确是一个新需求。不知道是否能够算是一种时尚单品（
题外话：
楼上二位头像朝向完全一致（笑
然并卵：）。无非就是在宣传体积小巧这一点。我刚打开 Octarine，什么都没做。然后这个软件总内存占用超1G。
话说我昨天才知道每天发言有次数，这是一个很好的策略，看来以后发言要尽量一次性集中回复了。
我觉得这两个根本不冲突，官方坚持自己的主要理念，插件则是插件。
说到各种花里胡哨的插件，还有你所说的‘file over app’，让我想到笔记圈里经常涉及到的一个话题，就是“all in one”。用户总想把手头各种散乱的资源全都集中到一个地方管理，但依我看需求往往不止于“管理”——一旦涉及到查看以外的操作，其实就有点“越界”了。说实话，‘all in one’ 在当前阶段几乎不可能实现。操作系统都没做到真正的‘all in one’，应用层的软件还能指望啥呢？
需要说明，用户想要‘all in one’的心态是合理的，但现实中就是做不到（除非未来一天有一个大一统的信息处理系统，笑）。因为用户常常会把很多本来不该由笔记软件承担的任务也强加给它。我觉得吧用户颇有微词的源头就是这个：他们预想中应该有的功能，结果并没有。
对于‘all in one’，我想到两种实现途径：
一是把各种不同格式的资源，都转换、迁移或者说降维成更底层的格式（比如纯文本、Markdown）来统一管理，代价是不可避免会损失信息纬度。
二是各种格式就按原样存储，不做转换，这样没有信息损失，但代价则是你需要一堆不同的软件才能打开这些数据，而且大部分数据也不是明可读的。
其实想到这里我就意识到：哪里存在不损失信息的“舒适圈”呢？ 哪怕是 Markdown、Word 或 PDF，也都只是待在自己的“圈”里——这个“圈”包括软件/功能本身在不同环境下的适配与支持。
这时候再看你强调的‘file over app’，我会觉得，也许唯一的出路就是：把那些特殊格式的“可读性支持”尽可能地延伸到用户需要的最大地方。不管数据本身是不是可读的，只要你能在足够多的地方打开它、解析它，那它本质上就是可用的，从某种角度来说，假如各种软件都能打开一张图片，那么我认为这就可以达到用户所需要的安全程度，无论是否可读。毕竟用户可以确认不再是单一软件掌控自己的数据。
这么一想，就和你后面坚持的“保持数据可读”理念有点冲突了。毕竟 Word、PDF、图片这些从来就不是纯文本，唯一能指望的，就是让相关软件或解析库到处都有。试想一下，如果你在一个未知的平台上，没有装对应的图片库、没有 Wps 或 word，那这些文件根本打不开，自然谈不上数据迁移。
所以关于“数据迁移”这个月经话题，我目前能想到的路径只有一条：要么把数据降维成更底层的格式，用损失信息纬度来换取更广的适用范围；如果不想损失信息，那就要设法让解析它的能力（插件、库、规范）渗透到各个平台，让大家都能打开。
至于数据是否“可读”，我觉得这可能涉及到另一个根本问题：用户对软件和数据的“所有权”焦虑。我们之所以这么在意格式开放，根本上是怕有一天失去对数据的控制权。这份焦虑来自于不信任。
要么，就让这部分代码彻底开源，接受监督；要么，就制定标准的格式规范，自己可以不实现，但让别人能实现。只有这样，可以打开用户数据的方式越多，用户信任才可能建立起来。
可以说就是：）但我希望是离线的。
也许这部分用户不是目标用户，毕竟md本来就是标记性语言，跟Linux一样，从始至终都是广泛范围下的小众。
你还真别说，搞不好以后会有软件会内置完整 Latex 渲染、塞好几个轻量化模型，或者干脆往“全能信息管理”的方向走——到时候安装包说不定真得几个 g 上下，赶上操作系统镜像了 。
的确是如此。或者说一个格式被广泛的支持存在两种保证，一个是足够简单，一个是足够流行。有时候明明拿不到源文件，或者源文件可以拿到但是不可读，反而也因为其足够流行反而有安全感。因为总归其他新的平台或者服务会提供解析和导入的服务。
1 个赞