Vim 为我编写书籍和课程节省了大量时间

2025-06-10

Vim 为我编写书籍和课程节省了大量时间

本文最初于 2019 年 2 月 12 日发布于:https://nickjanetakis.com/blog/vim-is-saving-me-hours-of-work-when-writing-books-and-courses


当我即将完成我正在进行的课程时,我会尝试想办法改进我的工作流程,以便更容易创建下一门课程。

这意味着要评估从音频和视频硬件到代码编辑器甚至操作系统的一切。

本文重点介绍如何组织和处理大量文本。这适用于书籍、课程、笔记或任何其他内容。

在过去的两周里,我在 WSL 中同时使用了终端 Vim + tmux 之后,我的工作效率已经比以前设置的 VSCode 更高了。

tmux对于同时处理多个项目的人来说尤其有用。我总是在自由职业开发工作、我的博客、开源项目、业余项目和课程之间切换。能够按下 tmux 热键切换到任何指定项目,并且所有内容都会立即加载并准备就绪,这真是太棒了。

我之前使用 tmux 和 VSCode 做过同样的事情,但是打开 VSCode 并将其移动到正确的大小总是我必须手动完成的。

这听起来可能微不足道,但事实并非如此。每次你这样做,都会让你陷入一种消极的心态,心想“唉,现在我又得重新整理一下了”

Windows 最大的缺点之一就是管理窗口布局非常繁琐,考虑到它的名字叫 Windows,这倒也挺有意思的。自从我在 Linux 上尝试用 i3 作为窗口管理器后,我就再也不想用别的了。

因此,在过去几周编写课程时,我一直在寻找在 Windows 中尽可能多地复制 i3 的方法,并使用 WSL 中的终端 Vim 和 tmux 让我几乎可以在终端中做任何事情。

这就是我选择尝试 Vim 的主要原因之一。这不一定是因为 VSCode 作为编辑器限制太多,尽管在我认真考虑改进我的课程创建工作流程后,我最终发现它并不适合。

创建课程涉及什么?

这是一项耗时数月的投资,与写一本书相当,只不过增加了额外的复杂性,因为你写的不仅仅是人们会读的东西。

例如,一本书,有目录、章节以及每个章节的正文。你可以用任何你喜欢的格式撰写书籍,完成后将其导出为 PDF。你只需要关心 PDF 的格式。

课程与此非常相似。它包含目录、章节和课时。章节只是将课时分组的一种方式,课时则是你计划通过视频讲授的文本脚本。

例如,我目前正在编写的课程有24个章节,158节课。每节课大约有2000个单词。课程内容大约有30万字,而且课程还没有完成。

每节课最终都会被制作成一段时长在2到20分钟之间的视频。这实际上取决于这节课写了多少字。

那么现在我们就来谈谈我整理这些内容时遇到的一些问题。

以下所有问题都是在我开始使用 Vim 之前所做的事情的背景下发生的,最后我将介绍如何使用 Vim 解决这些问题。

处理文件名

我目前对所有这一切的方法是为特定课程创建一个scripts文件夹,然后在该文件夹内为每个部分创建单独的文件夹,在这些部分文件夹中,我为每节课创建单独的文件。

它看起来像这样:

├── 001-introduction-and-setup
│   ├── 001-welcome.txt
│   ├── 002-downloading-the-starter-files.txt
│   ├── 003-tooling-setup.txt
├── 002-foobar
│   ├── 004-example.txt
Enter fullscreen mode Exit fullscreen mode

换句话说,我手动为每个部分和课程编号,并且课程编号不会在每个部分重置。课程编号从 1 一直到最后一课。

事情变得更加有趣,因为我还有一个单独的 git repo,里面有与特定课程匹配的编号文件夹。课程编号和 git repo 文件夹编号最终对齐非常重要。

但是,正如你可能看到的,当你需要在课程中间添加课程时,这种方法很糟糕。想象一下,在第50节课之后添加一节课,现在课程已经是第51节了。这意味着你需要手动将第50节课之后的每一节课都加1,这太糟糕了。

就此而言,几乎不可能预先制定课程的最终内容表,因为课程内容是无法预测的。

我需要编写脚本,并边学边玩。我甚至在写完课程后才会想出课程的标题。而且由于视频的时长很重要,所以课程的字数实际上决定了课程的衔接。

为了帮助解决这个问题,我现在通常会为每个部分创建一个文件,写出整个部分的所有课程脚本,当我对它非常满意时,我会将其分解为手动编号的文件。

所以我现在就是这样处理的。我会手动给所有课程编号,尽量减少以后需要添加课程的情况。如果真的需要添加课程(这门课到目前为止发生过两次),我会硬着头皮手动重命名所有内容。

这种方法的另一个痛点是,如果我想更改课程标题,我需要进入文件系统并手动更改文件名。这看起来可能是一件小事,但它会给写作过程带来麻烦。确实如此。

最后,我会定期确保每节课与下一节课衔接顺畅。所以,如果我在写第5节课,我通常会打开第4节课,滚动到文件底部,阅读我写的内容,然后确保第5节课的衔接自然流畅。这需要在文件之间来回切换。

使用我现有的工具可能解决其中一些问题

我尝试过完全不给它们编号,但保留一个单独的 YAML 目录文件。这样,我可以编写一个小 Python 脚本来读取该目录文件,并在课程结束后以编程方式为所有章节和课时编号。

我确信我能实现这一点,但现在我需要保留一个单独的目录来与实际文件同步。处理文件名本身就已经够烦人的了,而这个解决方案却没有解决这个问题。这简直是火上浇油。

不过值得一提的是,与书籍不同,课程不仅仅是一个导出的PDF文件。我希望人们能够在我的网站上在线观看课程,这意味着需要在课程平台的后端创建一个目录。

最终,人们会与之交互,而不是直接与这些脚本文件交互,所以实际上我的开发箱里的这些章节文件夹和课程文件并不需要存在。它们只需要编号,这样我就可以将它们与 git 仓库中的文件夹编号关联起来。

完美世界中的理想解决方案

如果我不需要考虑章节和课程在代码编辑器中出现的顺序之外的顺序,那就太好了。

基本上,如果我有这样的课程列表:

  1. 欢迎
  2. 下载启动文件
  3. 工具设置

我只想以人性化的方式处理课程标题,而不是数字。如果我想重命名课程,它只会在那个位置重命名;如果我想下移课程,我只需下移一行,课程编号就会自动更新。

需要注意的是,如果我在中间添加一个新课程,它下面的所有其他课程的编号都会调整。章节编号也是如此。但请记住,课程编号会在所有章节中编入索引。每个章节不会有自己单独的课程索引。

我也不想手动创建tooling-setup.txt文件。

另一个重要的事情是课程隔离。如果我点击或展开“工具设置”课程,我只想查看该课程的文本,但有时我可能想查看上一节或下一节课的文本,以便快速了解它们的开始和结束方式。

话虽如此,它不仅仅是为了帮助我集中注意力而提供的隔离功能。如果能够直接跳到课程的开头、中间或结尾,而不是将其应用到整个章节或课程,那就太好了。尤其是在搜索文本的时候。

不过,如果能对整个课程文本进行操作,有时确实会非常方便。比如,我可以搜索“例如”之类的短语,看看我说了多少次,然后尝试用其他短语,让内容听起来不那么条理。

说实话,我发视频的时候不会一字不差地读这些脚本。它们主要是为了帮我理清思路,但我在录制视频的时候会用它们作为指导。

使用 Vim 解决问题

我在还没想好要用什么编辑器和工具的时候就写下了上述理想的解决方案。我认为这不仅能帮你发现问题所在,还能帮你找到解决办法。

我读过的唯一一本技术书籍是《SICP》(计算机程序的结构和解释),在这本书中,他们谈到了一个叫做“一厢情愿”的概念。

在本书的背景下,他们讨论了在设计软件时,假设某些库或函数在编写之前就已经存在。这让你可以专注于设计应用程序的 API,然后再填充细节。

这有点像我在这里所做的,但是是在不同的背景下。

创建一个包含 300,000 字的大型文件:

我开始参考我的理想解决方案来思考这个问题。我整个问题的一个重要组成部分是处理单个文件名。

那么为什么不首先消除这些文件并使用 1 个大文件呢?

我没有一个大文件来测试,但根据我已有的文件,只花了几秒钟就创建了一个。我只需在 WSL 中打开一个 Bash 提示符并运行即可cat */*.txt > all.md

现在我有一个 30 万字的 Markdown 文件,大小大约 1.5MB。我决定尝试用我现有的 VSCode 和 Vim 打开它。在这两种情况下,我都启用了插件,而且两个编辑器都有处理 Markdown 的插件。

令人惊讶的是,VSCode打开这个文件的速度非常快。只花了大约 3 秒钟,甚至在文件中输入内容的速度也感觉和打开小文件一样快。

但是,仅打开文件而不执行任何操作就会占用我 i5 3.2ghz 四核处理器上 50% 的整体 CPU 占用,而打字时则跃升至 65%。

这根本行不通。这个文件我几个月来每天都要打开。它不能占满我的整个电脑。顺便说一句,它也占用了 800MB 的内存,但说实话,我不太介意,因为我有 16GB 的内存。

然后我用 Vim 打开了同一个文件。Vim 的打开时间大致相同,但它占用的内存不到 10MB,打开时 CPU 为 0%,而在文档中间打字时 CPU 负载会跳升至 3-4%。

感觉输入速度和处理小文件一样快。它甚至可以处理在 Markdown 中输入 ** 来开始加粗文本,而且速度很快,即使当时加粗了 30 万个单词。

这比我期望的结果要好得多,尤其是考虑到 Vim 直接在 WSL 中运行,而 WSL 的速度众所周知很慢。我想在原生 Linux 系统上速度会更快。

设定一个现实的最坏情况:

如果我的文件有90万字怎么办?一门课程的字数绝对不可能超过50万字,但我想看看结果会怎样。

用 Vim 打开 90 万字的文件花了 10 秒,但一旦打开,一切感觉都和 30 万字的文件一样好。进入和退出插入模式大约有半秒的延迟,但这是唯一的区别。内存和 CPU 占用率大致相同。

如果你好奇的话,VSCode 的表现也和 30 万字差不多。在这种情况下,VSCode 打开文件的速度实际上比 Vim 快得多,但这完全是因为 Vim 在 WSL 中运行,而 VSCode 直接在 Windows 中运行。

在单个大文件中浏览各个章节和课程:

由于我不会使用它,因此比较 VSCode 已经没有意义了,因此本文将特别关注 Vim。

vim-markdown插件非常棒,确实使这一切成为可能。

我通常不喜欢代码折叠,但事实证明,代码折叠是这种方法的最佳选择,并且 vim-markdown 插件对基于 markdown 标头处理折叠提供了一流的支持。

这意味着我可以打开所有折叠都关闭的文件,然后跳转到我想学习的课程,并在几秒钟内将其展开。效果非常棒。

该插件还支持使用[[和在标题之间跳转]],因此我可以轻松跳转到上一课和下一课。

Vim 还支持代码折叠,因此你可以只对打开的折叠进行搜索和文本操作。这满足了我对理想解决方案的所有期望,因为如果我想对整个文件进行操作,只需按一下热键即可展开所有内容。

除此之外,还有fzf.vim,它允许你在缓冲区中模糊搜索行(以及其他功能)。它是查找短语的绝佳选择。说真的,junegunn是一位出色的开发者生产力工具作者。FZF 和其他一些工具都是他开发的。

史诗。

编号章节和课程:

vim-markdown 插件恰好有一个方便的命令,:Toc它会根据你的标题创建完整的目录。这个目录在一个单独的缓冲区中生成,你甚至可以点击标题跳转到实际 Markdown 文件中的区域。

这种行为几乎正是我想要的。我不需要一直知道课程编号。只有当我想知道课程数量,或者想在 Vim 之外将课程编号与 git 文件夹编号关联起来时,我才会这样做。

目前该插件不支持对目录输出中的标题进行编号,因此我在 GitHub 上开了一个问题,但这个问题目前是可以解决的,只是集成度稍差一些。

例如,我的所有章节#和所有课程都使用##,所以只需要一点 Bash 魔法就能解析文件。例如,你可以使用 grep 遍历文件,找出以 开头的行#,这样你就得到了所有章节的列表,等等。

我还没想出一个完美的脚本,但我100%确信它是可行的,而且目前我只关心这个。谁知道呢,等我完成目前的课程后,也许vim-markdown的作者会把这个脚本集成到他的插件里。

提高大文件的滚动速度:

在 WSL 中,我注意到使用相对行号时,即使是只有 100 行的小文件,滚动起来也非常慢。也就是说,从滚动到看到光标移动之间会有几秒钟的延迟。

事实证明,相对行号才是主要原因,但我不想失去它们。应用以下两个设置后,滚动速度又变快了,即使在 90 万字的文件中也是如此。看到超过 10 万行的文件,感觉有点奇怪。

set lazyredraw
set regexpengine=1
Enter fullscreen mode Exit fullscreen mode
加速代码折叠:

默认情况下,30 万字文件中的代码折叠速度慢得令人难以忍受。即使只是打开文件也几乎无法使用,但经过一番研究,我找到了一个完美运行的插件。

在我的 vimrc 中添加FastFold插件后,问题立即得到解决。它从无法使用变得非常棒。基本上,折叠更新后,它就会发生变化。

说到 vimrc 文件,如果您想查看我的整个配置,它位于 GitHub 上的我的dotfiles repo中。

无需编辑即可为截屏视频添加润色

当谈到创建编程等技术主题的课程时,你会发现自己花费大量时间记录代码编辑器。

在这里,您将在视频中查看、编写和解释代码。

录制时,我经常使用非常大的字体和明显的光标,以便更容易理解我所说的内容,但最近我开始做的一件事是在录制视频后添加特殊效果来强调文本。

后期制作亮点

例如,在我录制视频后,在编辑阶段,我经常会使大部分屏幕变暗并突出显示代码的特定区域,只是为了更清楚地说明我们正在谈论的内容。

很多人说他们非常喜欢这种效果,也有很多人说我的“深入 Docker”课程是他们参加过的制作质量最高的课程。

然而,这种制作质量是有代价的。我需要花很长时间才能浏览几个小时的视频,并手动突出显示我想要的区域。

碰巧的是,Vim 有一个名为limelight.vim的插件可以让你实时实现这一点。它和 FZF 的作者是同一个人。

聚光灯

它会自动突出显示光标所在的区域,并且您可以调整暗淡的颜色和不透明度等内容,以便使其与任何颜色主题看起来都很棒。

这意味着我可以打开 Limelight,而不必在后期制作编辑中手动为屏幕添加暗淡和高光。仅此一项就节省了几个小时。目前 VSCode 还没有类似的功能,但我想可以实现。我知道它有一个 Emacs 版本。

当我准备录制即将到来的课程时,我会尝试一下。

最后,我很高兴给了 Vim 第二次机会。很久以前我就放弃了它,但现在它已经成为我编写代码和创建课程的工具链中最重要的工具之一。期待未来更多关于 Vim 的文章。

你有什么 Vim 写作技巧吗?请在下方留言告诉我。

鏂囩珷鏉ユ簮锛�https://dev.to/nickjj/vim-is- saving-me-hours-of-work-when-writing-books--courses-c56
PREV
苏格拉底今天会使用 Docker 吗?
NEXT
开发人员的生产力可以衡量吗?引言:专家们一致认为,那么我们该怎么做呢?一个温和的建议:结论