“实战Elisp”系列旨在讲述我使用Elisp定制Emacs的经验，抛砖引玉，还请广大Emacs同好不吝赐教——如果真的有广大Emacs用户的话，哈哈哈。

半年前我在这篇文章中展示了在Emacs中查阅笔记的效果——用emacs-request请求ElasticSearch查询关键字、基于helm以下拉菜单的方式展示查询结果的标题（即问题），最后打开浏览器查看笔记内容。稍加使用就发现一些不足之处：

1. 需要离开Emacs打开浏览器。我更希望能在Emacs中查看；
2. ES的响应内容为JSON，要快速地辨认出question和answer字段比较困难；
3. 一个问题的答案往往是多行的，但在浏览器中answer字段是以一行的形式展示的，不利于阅读。

为了解决这些问题，我实现了一种新的查看笔记内容的方式。

改良后的效果

尽管我最近开始用VNote做读书或读在线文档的笔记，但更多的时候，我把经验型知识都记录在一个名为my_note的Git仓库中。这个仓库中有许多.org`文件：

1. TeX.org，记录与LaTeX相关的问题和解决方法；
2. asm.org，记录的是与编写汇编语言程序相关的问题和解决办法；
3. cl.org，记录的是与编写Common Lisp代码相关的问题和解决办法；

这些内容被我称为FAQ。尽管不同的文件记载着不同方面的内容，但它们的格式是一致的：

1. 每个文件都以org-mode的语法书写；
2. 文件中只有一级条目，没有嵌套；
3. 每一个条目的标题就是一个问题的表述，下方的文字则是这个问题的答案。

A picture is worth a thousand words

这些问题都比较常见（不然怎么叫FAQ呢——也许上图的不算常见吧），回过头来查找的机率很高。显然，在纷繁复杂的文字中凭肉眼寻找关键字是低效的，即使是祭出grep，用正则表达式这样的大杀器来查找也不是特别称手——因为并不知道怎样的正则表达式可以匹配到寻找的内容——也许多写了关键词，也许少写了，也许顺序不对。

对于搜索这类非结构的文字资料来说，全文检索是一个更好的选择，因此，我是把这些内容丢进ElasticSearch里再查找的。

解析并导入到ElasticSearch

“实战Elisp”系列旨在讲述我使用Elisp定制Emacs的经验，抛砖引玉，还请广大Emacs同好不吝赐教——如果真的有广大Emacs用户的话，哈哈哈。

GTD的第一条原则是“搜集”，为此我有一个inbox.org文件，专门记录所有的新想法、新任务。我会在每晚的固定时间处理其中的内容——有些可以马上开始做并做完，更多的则是移动到其它.org文件中，等待排期。

org-mode有一个内置的快捷键C-c C-w，专门完成将条目（org-mode的术语，即.org文件中带星号前缀的一行，参见An Explanation of Basic Org-Mode Concepts）移动到其它.org文件的需求，但它有一个缺陷——不能把条目移动到其它.org文件的顶层，而这是我经常需要做的。

为了移动到顶层，需要：

1. 使用org-cut-subtree命令剪切当前条目（其实还会包括条目的子节点，但inbox.org中的条目基本上都没有子节点）；
2. 打开目标的.org文件；
3. 将光标定位到文件末尾；
4. 使用org-paste-subtree命令粘贴条目。

为了轻松完成上述四个步骤，org-refile-to-eof函数应运而生。

上大学后不久我开始用挖财记账，当时记得很随意，不会去追究一些不知道花在哪里的钱，不时就要强行修正账户余额，就这么一直用到了2019年中。后来挖财的启动时间越来越长，同时我不想看启动时的广告，便动了换记账软件的念头。

本想着试试MoneyWiz，但其价格令人望而却步，于是决定继续物色免费的记账工具，不久便遇到了GnuCash。由于它是GNU出品的，让我对其一开始便比较有好感，加上想尝试一下复式记账，便在同年9月份换到了GnuCash上。

可惜好景不长，我很快便发现了GnuCash的不足：

1. 启动速度随着录入数据的增多显著变慢；
2. UI不够美观；
3. 比较依赖鼠标操作；
4. 交易时间的精度只到天，且无法轻松调整一笔交易的位置——这一点是我尤其在意的，因为着意味着一旦我有一笔交易漏记了，再追加回去后，整个账本的交易数据次序也与银行记录的不一致了。

于是我抛弃了GnuCash，投向了ledger（以及ledger-mode）的怀抱。

ledger和ledger-mode

“实战Elisp”系列旨在讲述我使用Elisp定制Emacs的经验，抛砖引玉，还请广大Emacs同好不吝赐教——如果真的有广大Emacs用户的话，哈哈哈。

序言

在之前的文章中，我提到自己用org-mode管理工作日午餐和晚餐要看的动画及其进度。简单来说，就是为每部动画创建同名的二级条目（它们有一个共同的一级条目叫“动画”），每当准备看新一集时，就在对应二级条目下创建形如“观看第X话”的三级条目并设为TODO。

按这种方式，在《钢炼FA》下最终会创建出64个三级条目——而可怜的Emacs甚至一屏只能显示50行！这些“阅后即焚”的三级条目浪费了其它（或许）更有价值的内容的展示空间，因此最好将每一个切换至 DONE状态的三级条目藏起来。

org-mode可以“internal archive”一个条目，但这样仍无法节省它们占据的纵向空间。后来，我想到了org-mode的drawer特性。