学习Vim、VSCodeVim的历程＆写书探索的一些经历

学习Vim、VSCodeVim的历程＆写书探索的一些经历

[系列文目录]

相信不少人最早接触Vim，都是因为使用Git的时候出现Merge Conflict会突然进入Vim的编辑器里，这时候大家如果不熟就会不知道怎麽离开Vim，於是就开始被迫要理解一些Vim的操作。一开始笔者也是差不多这个路线，平常就是使用 Git或者修改远端机器上的一些设定档时会使用到Vim。

多少透过自学知道Vim的命令，但就只是零碎的使用命令，不了解为何h, j, k, 'l'左下右上的移动。也不知道为何Vim的模式被这样设计。

到後面是为了深入研究编辑器的操作，所以请教了公司里的後端工程师Ryan大大，他习惯使用Vim和VSCodeVim。

第一次请教了在VSCode里使用Vim的观念与技巧以後，笔者开始练习《Vim CheatSheet》的各种用法。使用过一会之後，发现不见得可以在VSCodeVim里使用出CheatSheet上的几个操作，於是再请问了一两次，大概把一些VSCodeVim上的指令掌握。之後，笔者主要就以CheatSheet和《Boost Your Coding Fu With Visual Studio Code and Vim》作为主要的学习资源。

这个时候的观念还并没有被真正建立，但VSCodeVim是一个你随时可以离开Vim Mode的Extension，所以在动手操作时，如果太卡，还是可以先切回原本的VS Code里操作，无形中减少了许多转换工具的成本。

之後，为了进一步掌握VSCodeVim，笔者挑选了一些市面的相关书籍，最後找到了《Practical Vim, Second Edition: Edit Text at the Speed of Thought》这本经典好书，後面也实际购买书籍支援作者。

书里之後介绍了使用各模式转换的观念，让笔者一开始就掌握了学习Vim所需的基本观念。

另外很重要的是，它在前言里一开始就跟读者们讲解了学会「盲打」（Touch Typing)的重要性，虽然没有介绍如何盲打，但已经让笔者有了方向，知道应该往何处寻找资源掌握这们技术。

Touch Typing让我熟悉并且对於一些基本的Vim中的h、j、k、l操作感到亲切，熟悉後使用的非常自然。

虽然後面也看到一些网路上前辈分享使用底下的键位图学习并熟悉Vim。

但笔者自己的经验是熟悉盲打以後，键盘的英文位置已经烂熟於胸。看不看这张图差异其实不大。遇到有操作就看《Vim CheatSheet》或相关网站熟悉命令即可。

在自行找资源补齐了相关的基本知识後，笔者发现但仍有一些跟Vim重要部分是空白的，与实际在VS Code使用上的一些难点

1. 自订键位的方法与使用观念，一开始《Practical Vim, Second Edition: Edit Text at the Speed of Thought》》作者在写书时就不考虑介绍此点
2. Vim的操作与一些命令并未被VSCodeVim支援(此处详见：VSCodeVim Roadmap)
3. 不是所有Vim操作都是在VS Code里最有效率的操作，花较高成本学习到的技巧，在实务上还是要挑选、打磨後才能找到最适合现有编辑器环境的用法

这些问题并未从外部资源直接得到解答，还没有一本书可以解答相关的问题，於是笔者开始尝试去探索相关议题。

後面，笔者开始接触一些VSCodeVim的使用者，也到官方群组帮忙回答问题，顺便观察一下Extension社群的生态，可以把一些好的部分分享给读者。

结果实际上让笔者很失望，大部分的使用者会想解决自己的问题，并没有深入Extension是怎麽运作的，在社区参与上的贡献与交流也比较少(相比笔者在国外看到的一些社群的活跃状况)。真正的社群回答问题、贡献程序码的，还是少数人。因为VSCodeVim是一个非常多人使用的工具，文件已经非常丰富，每隔一段时间就有高手帮忙贡献一些程序、解决一些问题，所以许多使用者可能并没有意识到这点。

国内的社群笔者疫情底下参与的社群数量不多，但走过，遇到有Feedback可能是提议笔者说，这个东西可能有需求，你可以往这个方向做这个工具，或是遇到现成问题就抱怨、评价工具不好的人。多数人都在使用现成的工具，不关心相关议题。

实际上，一些笔者觉得应该可以很早被解决的Issue，没有太多人提出来，或动手解决。

以VSCodeVim在settings.json中的键位对应为例，读者们知道在VSCodeVim v1.23中，我们是没有办法使用或这两个Key Notation绑定「Ctrl+s」与「Ctrl+z」这两个快捷键的吗？

这是在Vim的环境可以做到，也很常见的一个需求啊（Ctrl+z有网友提议说可以新增这个Key notation，但Ctrl+s一直都没有）。大部分的读者可能就会在这里绑定、发现设定没有生效，之後疑惑这样做到底对不对，最後可能使用绕路的方式在keybindings.json中定义对应的快捷键，但不会比较方便。

新增这两个快捷键的Key Notation一点也不难，笔者提了相关PR，确定可以在VSCodeVim v0.1.24中使用。另外在写书的期间，笔者考察了Vimrc的使用方法，整理出稳定可用的部分介绍。後面发现有两、三个相关问题，也提出PR解决，不过此点读者并不会知道这点，因为书里并没有特别写到这一部分。

总之，这些我们可能觉得理所当然应该要有的东西，从来都不是自然地出现的。

至於，开源专案的开发者、维护者知道这些吗？就我自己的观察，我认为有人知道，而且他们动个手就可以解决了，只是他们没有什麽理由帮使用者做到这些事。开源的工具是需要使用者加入、feedback才会成长的，让专案变好从来就不是一个人的事情。

当时一些PR是在写书期间提出的，开源专案Pull Request等待的时间许多都很漫长。为了确定哪些功能确定可用，笔者承受了时程压力(有写书的人应该更能体会这点)，也感受到现实。

总之，笔者後面一边探索的工具可以处理到哪个程度，探索时间成本是相当高的。

也可能是为了一些热情，笔者尝试让不同作业系统的一些快捷键跟键位的配制方法，Windows和MacOS都有，期间为了Windows的一些配置无法跟MacOS上一样顺利设定感到费神。後面有和一些使用者接触，但时间成本昂贵。虽然後面总算对齐了Windows跟MacOS上的一些设定，但也因此花了不少时间。原本计画探讨下Linux的环境的快捷键设定的，在前面为两个作业系统消耗了不少时间後，笔者花了一天处理Linux上的环境，因为相关进度的书稿落後了被编辑责备，Linux的设定方便就再也无法探讨了。

至於否入花费Vim的时间是否真的值得呢？单看金钱，远远不够。写书的稿费是比不上笔者一个月的薪水的。

写书会让作者处在一种类似长期加班的状况，但工程师作者是没有办法因此领以劳基法而言要比正常工时还高的时间或加班费的。

在写书跟探索相关问题时，一直感觉有一堵堵墙在前头。但在越过後面这道墙翻跃过去解决相关问题後，回头一看，并没有人帮助自己解决相关的技术问题。墙壁依然在那头，只是自己跳的过去了。

跳过去以後，回过头看到一些群组里使用者过去抱怨的问题，自己都有解法。不过没有什麽情境或理由让笔者多花时间谈论、改变这些人对工具的印象，每个人平常也都有自己要做的事情。

当时会去写书的动机有多种，笔者自己也喜欢挑书、买书跟看书，所以也会挑书，尝试自己写一本书看看。

说实在，过程中比自己想得费功夫多的多，有很多排版、校对、格式转换、大陆用语之类的问题要处理。但如果选初学者可以自学起来的题目，却又不会给笔者带来太多下笔的动力。因此选择了介绍靠自学难以学会的技术，并介绍一些思想、观念还有一些独创的内容。

事後来看，就以铁人赛的系列书来讲，如果要卖得好，写给初学者的系列，其实就够了。一本书毕竟也只有几百块，所以如果是为了销量，让书卖得好的一个重点其实是行销与曝光。

回头看，写这类书或做这类教学，到底值不值得呢？

说实在，只有其中一个读者能从书籍或相关文章中因此自我学习、有所启发，进而改善现在的环境，对作者来说才能说可能比较值得。

真正会去改变环境的人，也许100人中也只有一个。书再多卖100本，对作者的收入来讲其实增加有限。但只要出版书有其中一本或多本被放到图书馆去，就有机会有更多人阅读。或许有一个人有些点子想法或思维，因此被启发，那是能够有更大的影响的，虽然笔者不知道这些正向的影响会不会回到自己身上。