目前在使用Obsidian的时候，如果希望编辑一个markdown文件，则一定需要将其在一个仓库中打开。这显然比较繁琐。
能否添加一种简单的编辑模式（或者叫独立模式），即不需要创建或打开仓库，即可编辑markdown文件。或可以打开某些单独的markdown文件？
也许是这样，Obsidian在某个位置存储一份全局的配置，当使用独立模式打开的时候，将会使用这份全局配置（包括主题、插件、各项设置等），并且对配置的修改也将存储在这里。
用起来的效果可能像Typora、MarkText，或者更准确说类似于VSCode的那种效果。
这样就可以完全通过Obsidian来编辑任意的markdown文件，而不需要通过其他软件或者必须将markdown文件放到仓库内再编辑了。
ob非常多的操作都只限于库内文件（例如万年不改的嵌入pdf），如果开发一个独立模式的话，底层逻辑全都要改，插件也要改一堆
从设计上来说，可以通过创建一个全局的仓库来模拟（也就相当于在某个位置创建了一个仓库），这样可以不用修改大部分的逻辑与内容。
而且如果只是为了编辑markdown文件特化的模式，也可以舍弃掉很多在仓库中才能用到的高级功能，仅保留markdown编辑相关的功能。
如果内部代码设计的时候耦合性不强的话，这也许不是很难做到。
那就可以不用Ob，而是采用Marktext，Typora这种软件就好了
这当然可以，并且我现在的方案就是使用Typora临时处理单个markdown文件，或者有必要的时候我把文件挪到仓库内编辑，编辑完后再挪出去。
但显然如果Obsidian能胜任这个工作的话，我也不太乐意换个完全不一样的软件来干活，毕竟无论是Typora还是MarkText的markdown编辑体验都没有Obsidian做得好。而且如果支持了这个功能的话，Obsidian的可用情景会变得更宽泛。
当然，如果开发者觉得这个功能投入大于收益，我自然会选择继续用其他软件代替。又或者自己搞个插件之类的来满足我的个人需求。但我觉得，也许“选择什么方式代替”并不是目前这个话题的核心。
不如在盘根目录里放个库目录,打开文件时时转义成对应的链接,obsidian本体用tray之类的插件缩小到任务栏?
其实和我现在的方式差不太多，但终归还是麻烦一点。我猜测这个功能也许不是很难实现，所以就想着提提看。
建议楼主到 Obsidian 的 GitHub 或者英文论坛提提看。只是这个功能也许也不是很容易实现。
楼主的观点是“不创建库”“舍弃部分功能”，但又提到“可以通过创建一个全局的仓库来模拟”“在某个位置存储一份全局的配置”。
前一个观点，目前，库有索引双链和存储配置功能。
双链和第三方插件的编辑支持等，是否属于可以舍弃的功能。
舍弃了这些功能，Ob 编辑体验效果是否会比 Typora 或 VSCode 好。
后一个观点，现在的功能支持将盘根目录作为一个库，#6 也提供了类似方式，创建了全局的库，也存储了全局的配置。楼主期望实际上和现在的情况应该有哪些差别。
从收益看，舍弃一些编辑支持可能能做出能跑通的“独立模式”，但相对应认为这项功能有帮助、支持这项功能的人就会变少。
从支出看，增加新功能的背面是后续长线的兼容与维护成本。
首先这样的应用场景我想应该不只有我一个人会这么用，但也许暂时还没人提出来过。
以我对程序的浅显认知，markdown编辑器与库里的各种额外功能应该是互相独立的，或者说应该不是处于强耦合的状态。
根据我的了解，目前定义“仓库”的是在某个路径下存储的若干个相关的配置文件，这些配置文件让Obsidian将其该路径识别为仓库并进行相应处理。
因此我想象中的一个简单方式是，新增一个入口。当从该入口启动的时候，不需要去找某个路径下的配置文件，而是去固定的路径下找配置文件，例如在我的文档里，或者AppData里等位置。
此时，实际上与打开了一个普通的库没有明显的区别，也不需要做非常大的更改。
然后在此模式下，可以把所有与仓库特性相关的官方插件禁用掉，第三方插件的话可能也需要做类似的筛选操作，或者干脆全部禁用掉。
此时Obsidian应该处于一个约等于纯净版markdown编辑器的状态，接下来就只需要支持打开任意路径下的文件就可以了。
因为既然追求编辑单个的markdown文件，那肯定是说明这个markdown文件并不需要与其他文件建立复杂关系，否则就应该使用普通的方式打开仓库编辑了。
而Obsidian本身作为markdown编辑器的功能对我来说就非常好用（相比于其他软件），所以理论上来说，应对轻量级的markdown编写也是有足够的竞争力的。
但无论如何，只要是新功能就一定有更多的成本投入，我也打算把这个想法发到Github跟开发人员讨论一下。
如果开发者认为并不是一个值得去投入的新功能，那我也会自己想想办法做到类似的效果。
按目前描述，我有很多顾虑，一时表达困难。但既然楼主愿意主动投入推动，还是鼓励尝试吧。
鼓励提PR
确实是哈，仔细想想 VSCode 也有单文件支持的，把 md 编辑器单抽出来是个好点子。
因为我并不是很专业的开发者，所以我也很难评估这个想法的确切实行成本。
仅仅是根据我个人的推测来说，也许这是个不太难已完成的点子。
如果确实很容易搞定，并且维护成本不高，那自然是好事。
如果相关的开发者认为这个功能不值得去做，那我也只能通过其他方式曲线救国了。
我在英文论坛上也找到了相关的讨论帖，看来有类似想法的人确实不止有我一个：
哈哈，那楼主也应该明白为什么我说这个功能也许也不是很容易实现了吧。
既然现在认识到 GitHub 和英文论坛，以后有什么想法也可以先去这些地方搜搜看。