完全本地布署，即win软件操作自己指定目录下众多md文件，不想用数据库。为什么不能做到定时自动保存？

[wcx1978]

经过几天折腾筛选各种markdown软件, 我决定最终还是入坑你这软件好了,那目录功能和代码块功能对我们这半个程序员收集网上各种代码小工具很好用. 自己做的==链接跳转==查找也方便. 你这软件做的功能真是超乎预期.

只是功能太多,反而基本的功能都有点没做顺手.

如,我启用绑定数据源为本地存储的话,编辑本机实际目录群下的Md文件的话,按人情道理,应就有个自动保存时间的设定, 你这却没有,每个打开的文件都要一个个去ctrl+S . 很累. 人家wps 和 office 都有自动保存的. 你这逻辑有是有,但不符大众。

作为半个程序员也认真看过你细心写的说明书，大概了解这软件的架构是， 前端UI 加 数据库couchdb的。 如 连接到 GIthub，码云又是另一种运行模式。 但无论怎么变最终存储点，本身软件 就是要把 单个md文件读出，填到 内部的 couchdb 数据库，在里面索引什么的，用户修改文章，也是先变动 couchdb 数据库里， 再同步到 最终存储点的。不知这理解对不对？

这样中间加了层 存储件 反而 增加了不确定性。 每次我同时打开七八个文件 同时互相参照编辑时，都不知哪个改过哪个没动过的。 突然要出差走人。哪有这么方便一个个去ctrl + s.
你说的云服务的那些，大家都好理解，是不好实时老是去保存。 但本机的数据库也要这么麻烦吗？ 一般像我们技术人员，只求存好一个个md文件。 然后一个批处理 压缩打包上传云盘最保险。 下飞机落地后，随便找个电脑就可云盘下载重新布署。 那些什么奇奇怪怪的数据库新技术，一般不怎么内行人不乐意就了解的。

能搞个可以整个系统文件可ftp 上传到 只支持php+apche+mysql环境运行的ｍａｒｋｄｏｗｎ在线文档库更好。 这样小书匠系统到处可生根。 要使用插件就要付点小费谁都乐意。

[suziwen]

不提供自动保存到第三方存储，除了以前说的 markdown 转换成富文本需要消耗比较多的 cpu 资源的原因外，
现在，小书匠的定位是一款笔记应用，或者说是知识管理工具，不再是单纯的编辑器，比如纯文本的编辑器(比如记事本,markdown编辑器等)或者富文本编辑器（比如 office, wps等）,文章不再是单独的个体，文章与文章之间可以双向关联，创建标签，分类等多种知识管理纬度，方便进行知识的检索，全文搜索等。为了保证索引，标签，分类等信息不被破坏，是不会让用户直接参与编辑本地文件，所以就选择了一个数据库，方便数据的管理。

其实，应该把小书匠分开开发发布的，做一个单独的本地客户端编辑器，和单独的笔记应用。想要单独编辑器功能，类似那种编辑器自动保存到本地文档的，就选择编辑器版本，不需要什么第三方绑定这个操作步骤，直接双击 md 文件就可以打开编辑，编辑中自动实时保存。对于另一个方面，就是笔记软件，就提供文章链接双向引用，标签，分类树，全文搜索等功能，但不提供什么第三方存储，也不提供本地直接编辑 markdown 文件，这个就像 Evernote/印象笔记这种笔记软件，压根就不会让你编辑本地 markdown 文件。

现在很多用户疑惑的最多的，也就是小书匠到底是编辑器还是笔记软件，这个也是目前小书匠最大的问题，太多功能混在一起，软件功能的边界没有定义清楚，导致只想要编辑功能的用户，会对软件的使用上，与一般的编辑器操作逻辑不一致的问题。

另外，关于你提到的自己服务器部署 apache-php-mysql 环境的想法,小书匠是支持自部署的。

能搞个可以整个系统文件可ftp 上传到 只支持php+apche+mysql环境运行的ｍａｒｋｄｏｗｎ在线文档库更好。 这样小书匠系统到处可生根。 要使用插件就要付点小费谁都乐意。

小书匠提供了 天马版（suziwen/pegasus - Docker Image | Docker Hub），　如果你会一些 Docker 基本操作，只需要一条命令，就可以部署类似小书匠网页版的知识管理系统了。