几年前，刚转行为专职程序员不久时，出于对 vim 的喜爱与信仰，自己开发了一个 vim 插件，以支持在 vim 环境内记笔记及管理笔记。我知道市面上有不少笔记软件，但记笔 记这事是很个性化的东西，而且很多吹成云笔记的产品，把个人笔记上传到人家服务器上， 怎么都觉得有点敏感。所以我决定就用 vim 在本地写 markdown 文本笔记，要怎么上传 至 github 托管仓库，也是自己能完全控制的。基于这个出发点，我自行设计并开发 vnote 插件，虽然基本只是给自己用吧，当初也乐此不疲。
但是再过几年回头再看，这个插件软件可能设计的不尽如人意。
vnote 项目概况
项目地址在 https://github.com/lymslive/vnote， 这是标准的 vim 插件目录结构。
强依赖另一个 vim 项目，vimloo 。这算是
viml 的基础代码库，我推出的用面向对象的思想来写 viml 代码，很多基础设施就放在
了 vimloo 仓库。这两者或许是相辅相成的，也可能是先想到了 vimloo ，而
vnote 就是个具体的练手项目。
在初期，还有个配套辅助的 C++ 命令行工具， lymslive/vnote-tool 用于为一个笔记本目录生成索引及查询。后来从 vnote 插件仓库剥离出去。可能由于需 要额外编译，使用度不高。原计划想做成 vim 通过异步 channel 与该外部工具的通讯也 没实现。后来又写了几个 perl 脚本，放在 vnote 插件目录，重建索引还更方便。perl 处理文本还是有优势的。
然后我自己实际的笔记本仓库是 lymslive/notebook 。当然现在是设为 private 访问权限，不适合公开的。
比较遗憾的是，这几个仓库，几年后都渐失维护，少有更新了，包含 notebook 内容。
记得 SpaceVim 项目曾收录 vnote 插件，但我本身不喜欢用别人整的开箱即用的配置好 的 vim ，所以也没跟踪 vnote 的使用率。推广与运营，向来不是我所擅长的，但这并不 是我对 vnote 感到纠结的地方。而我主要遗憾的是 vnote 本身渐渐不能让自己满意了。
vnote 的主要问题
一个主要问题可能是过度设计，对笔记本目录结构与笔记文本名的约定设计偏复杂了。
vnote 假定一篇笔记是一个 markdown 文件，文件名位于
${NoteBook}/d/yyyy/mm/dd/yyyymmdd_x.md 。其中为每层年、月、日建立目录，而笔
记文件名也包含 yyyymmdd 8 位数字拼接的年月日信息作为前缀，再加个编号后缀，因
为当然设想要支持一天写多篇笔记的情况，所以加编号。
这其中最大的现实问题是，高估了用户（比如我自己）写笔记的热情。一般用户可能很难
坚持每天写笔记，更别说每天写几篇了。所以大部分情况下，三层日目录下只有一个文件
yyyymmdd_1.md ，显得很冗余滑稽。还有很多日期是一篇笔记也没有的，也就不会建那
天的目录。但在顶层目录只看到年份，不能直观看到里面哪个月哪天是空缺的。
vim 的哲学是做好一件事，所以仍有时候我想在 shell 下进入笔记本目录去查看，也就
是 cd 与 ls 的常规。所以三层目录结构的设计造成很大困扰。如果能重新设计，我
想就平坦一层的 yyyy-mm-dd 目录会更方便。没必要担心子目录名太多，能写一年也就
三百多个目录，能坚持三年不间断也就一千左右个子目录。类似 ls 的命令也完全可以
加上通配符过滤只列某年或某年月的日记目录。
目录太深可能也让我忽略了在每天目录下还能放非 .md 文件，如插图，没意识或不方
便去维护可能有用的配图表，最多只用超链接记下参考资料来源。
笔记文件名还有个不良的设计是，可以再加后缀表示私有日记，如 yyyymmdd_x-.md ，
可在 .gitignore 中加入规则忽略提交。这又进一步增加复杂度。可能当时的 github
免费用户，还不允许设私有仓库。否则将整个笔记本仓库设为私有是最恰当的，完全没必
要在同一个笔记本公私混杂。真有这么闲，可以建两个笔记本仓库，一个公开，一个不公
开。
vnote 的第二个问题是，我在使用过程中可能偏离了它作为简单笔记的初衷。后来还迁入 了大量长篇大论的原创文章，搞得像要维护博客的站点内容一样。
这也有个原由，之前忘记从哪得到一个阿里云的优惠促销券，买了个低配的云服务器，用 于学习练手。就想手动搭个博客网站。我寻思着博客建站主要还是内容，建站技术还是其 次。我在笔记本 notebook 存的文档有一定组织规律，适合转成 html 静态网站。但 notebok 里面的原创内容还是不够看。所以我就将早年在国内一些网站如网易博客、新浪 博客、百度贴吧写的文章，备份文档，导入 notebook 了。国内那些博客网站如今基本死 了，我之前在上面写的是非 IT 技术文章。
历史备份博客文章导入 notebook 后，也导致 vnote 插件的管理复杂度提升，可能多级 标签系统就是那时引入的。
其实，博客与笔记还是有很大不同的。博客文章是原创的，比较成熟与成体系的写作，并 且是有意分享与公开出去的。而笔记是比较松散的，记录学习知识点，或不成熟的头脑风 暴点子，并不适合公开。仅管有时在笔记中随手记下的点子有可能孵化出博客文章，然而 区别还是显而易见的。所以强行放在一起管理，并不是很合适，尤其是一开始可能并未仔 细考虑到这种需求。
只是从个人角度，利用 notebook 完成了一次对早年博客文章的备份归档，也是体现了价 值的。那些博客文章虽然对我今后程序员职业并无助益，但无疑也是值得蔽帚自珍的。国 内建博客网站挺麻烦的，备案监管就一堆破事。所以当阿里云服务器优惠到期后，也就没 续了。想来在那段时间的一个实践成就，就是依托 notebook 的内容，学习了用 go 的基 本 Http 功能建站，后来还是换 perl 了。我在工作之外的个人项目中大量使用 viml 与 perl ，也是任性。
现在不想太折腾了，github page 应该是比较稳定的，国内访问速度不稳定的因素就不考 虑了。因此打算把 github page 搞起来，也不想自己从头搞山寨了，就找开源的静态 html 渲染系统与网站主题，当然也是任性选了 rust 系的 zola 。后面也许会把 notebook 私库备份中值得公开的博客文章迁到 github page 了。
第三个问题也是个人使用的问题，后来没有坚持写笔记了。notebook 仓库在某年开始近 乎停更了。
直接起因可能是某次换工作了，新公司对员工上网控制比较严格，刚入职时也比较小心翼 翼。所以可能不太方便从 github 拉下原来的 notobook ，继续原来的笔记体系。仅管也 可以在工作机本地建个笔记本，也在纠结中意兴阑珊了。一旦中断了写笔记，再拾起来就 难了。
也正因一度中断使用 notebook 与 vnote ，在淡忘之后回头再看，容易以一种局外人用 户而非开发者的角度看重新审视其利弊，更能体验到哪些是直观的核心功能，哪些是不必 要的复杂功能。也幸好当初留下了不少文档说明，仅管有些文档没有随后续开发修改同步 更新，但也还是个指引。不过也犯了个低级错误，vnote 与 vimloo 默认 clone 下来时 不在同一个分支，一个在 master 一个在 dev ，结果运行起来报了好多错误，好久没写 viml 代码，有点慌。后来把两个仓库代码的 dev 都合到 master ，一起用 master 就没 有问题了。
总结
复盘了程序员生涯第一次写的个人项目，vim 的笔记插件 vnote ，以及自用记笔记维护 notebook 笔记本的历程。并不算太成功，大致有以下几点问题：
- 设计的笔记文档目录结构复杂，导致功能也复杂，有点过度设计的意味。
- 对公有笔记、私有日记及博客文章的概念模糊不清，产品定位不太明晰。
- 没有坚持写笔记。
- 没有心力去推广 vimloo 的基本思想，这也许是比开发具体的 vim 插件更有意义的。
不管如何，汲取经验教训。后面的 flag 就先不立了。