全部学习汇总：GreyZhang/g_org: my learning trip for org-mode (github.com)

         我使用org-mode其实很多年了，但是使用的org-mode功能非常少而且技术自然也是很浮于表面。很多org-mode本身的功能我了解不多，更谈不上能够掌握。就比如说通过org维护一个工作清单，我的方式是把做完了的工作通过转移到其他的文件的方式来保持我清单的清爽。为此，我人工维护了很多文件。后来无意中看到了别人的用法我才发现，其实这个操作已经有一个比较成熟的工作流内置在了org之中。这个功能就是org条目的归档。虽然，采用的方式跟我自己的方式有相似点，但是这个操作更加简洁。

         这个就是org-mode中已经内置的一个命令，我觉得这个快捷方式可能不是很适合我。兴许，一不小心可能就误关闭。不过，操作可以采用直接调用命令的方式，而我现在的命令支持模糊搜索，处理起来也会很简单。

         上面的说明来自于： Archiving (The Org Manual) (orgmode.org)

         假如有这样的一份org文件，我接下来尝试做一些归档的信息处理测试。接下来，我会先完成11行的内容，之后看看归档效果。第10行，我计划不标注完成直接归档看看效果。789行，我完成第9行之后直接归档。而第2行，做一次完成后的归档。最后，处理掉第一行。记录一下每一步的效果。

         这里发现，其实这个命令有好几个。这里，我直接用文档中提到的这个。

         Emacs提示了归档的信息。

         从标识信息看，其实这个文件还没保存。我觉得这个很有意思，接下来我也会尝试直接关闭emacs看看这个效果是否可以自动处理。长时候其实发现，emacs会询问是否保存，至少spacemacs中的设置是如此。

         这是两次归档的效果，展开里面会有时间等信息，信息太长我这里不做展开了。这样看，其实789行只完成第9行也是可以全部归档到这里的，应该是类似的效果。后面确认了的确如此，而且顺便看到了其实这个文件中的条目顺序从上到下也就是归档的次序。

         操作了几条之后，可以看得出来这个操作的一个大概的处理规则。整个过程的记录也就直接省去了几个记录。最后直接看看这个全部的归档效果，其实可以看得出来，这种归档有时候是会破坏掉整个树状结构的。因此，在归档的时候尽量是按照自己的理解，确认自己归档的这个树基本就是一个基础的单元之后再归档，否则的话可能会导致整个大纲框架的丢失。不过，如果是针对工作计划清单来说的话，这样的问题可能就会少得多了。

         还有一种方式是内部归档，这种方式是给这个条目打上一个归档的标签。后续，默认的行为下将不会展开也不会再一些导出的信息中进行过多的展示。

         这是几个支持的命令，测试下来每个效果差不多，这个toggle其实是最好用的。

  这是归档之后的效果，归档之后TAB将无法再将其展开。如果使用set-tag的命令，可能得手动折叠一次。如果是使用这个toggle命令，标记归档的同时会将这个条目折叠到一行之中。因此，从便捷效果来说，这个toggle的命令我觉得好用一点。

         综合看，我觉得对我来说比较好用的还是归档到另一个文件。