小灰笔记

这一次算是趁热打铁，把之前优化掉了的counsel-M-x的匹配功能再推进一步。虽然还是没有达到spacemacs中的乱序匹配效果，但是还是让默认的模糊匹配增色不少。接触到新的功能的时候，更好的方式或许是尝试吸收消化而不是见异思迁直接尝试其他的新配置。这样对于自己的配置的维护熟悉度以及功能的精简性应该都是很有好处的。可能是之前的文章之后，这个插件更新了很多地方。我尝试的时候发现模糊匹配不奏效。反倒是，上面的配置全都不加的时候可以支持两种匹配模式。这个方案应该是非常成熟了，我找到的文章时间也是很久之前的。

这是一个简单的noweb的介绍，从这里看到了很多参考资料以及信息，不过对于基本的了解以及上手来说并不是很理想。尤其是关注的语法处理信息，这里并没有看到。或许，5种控制结构看一下之后会对此能有更深入一点的理解。本质上来说，我对noweb没有太多的了解欲望。但是我看到的很多采用 org-mode 进行文学式编程的项目用了很多 nowebref 之类的参数。因此，需要对此做一个简单的了解。noweb是一个简单可扩展的文学式编程工具，操作简单且不限制编程语言。这个材料其实就是 noweb 的官方简介。

我是因为想要了解org-mode的表格功能才来做calc的了解的，本来我的想法是简单浏览一下就过去。不过，一个简单的入门说明以及开发背后的信息故事让我觉得这段技术文档写得荡气回肠，因此还是把这部分信息做了一个整理。本以为对calc的了解会是一看即过的，但是这种有趣的事情以及功能，还是值得整理到自己的笔记系统之中的。calc是emacs内置的一个计算器，可以提供多种计算表达方式并且可以支持org-mode中的表格功能。上面这个链接是calc的手册，我这一次参考的主要是第一个章节的部分。

前面通过org-mode、babel以及代码块的管理等一系列的文档，基本上能够做我已经理解的文学式编程的功能。但是，如果直接在org文件中的代码块中修改代码，体验并不是很好，因此觉得这一部分的操作有必要做一个简单的总结。代码块的编辑可以间接快速进行org-mode中代码块的编辑，而且有着类似纯粹的代码文件编辑的体验。

这算是babel团队所做的一个尝试性的研究，为了探索现在的团队资金是否可以支撑全职的开发人员。而且，当我们在不同的社会中面临不通的汇率的时候，可能更加感受得到这种境况下个人的乏力感。我个人在支持我自己使用的开源产品的时候，会是不是利用便捷的网络支付进行小额度的捐赠，勉强可以请作者喝个咖啡。大部分推荐的人员我相信应该都是babel的用户，也对babel的未来有一定的思考。最近看了关于babel中资金问题的文章，觉得引起了我的一些思考，把这一份文章内容整理扩展一些自己的思考问题。

文学式编程其实是把直接写代码转换成了写文学式的篇章，在这个文学式篇章之中，插入我们设计中的代码碎片。这样，我们的思维模式会回到一个人类思维的模式。然而，当我们做完自己的设计之后，最终参与运行的还是得用代码，这样就需要有一个代码提取的过程。其实，针对简单的文学式编程支持，只需要掌握很少的一部分功能就能够支持。而emacs的org-mode功能，很多的扩充是针对可重现研究的。代码提取是从 org-mode 的org文件中提取生成我们所需要的代码的过程，这里结合官方的文档来看看还有什么细节的配置信息。

这部分的特性看起来更多的是为了支持可重现研究，在一定程度上我还没有对可重现研究的 Babel 功能有太大的认可。因为在我看来，或许里面涉及到的引用或者处理等工作只是让这个文档更加复杂化了。而可重现的一些信息，或许可以通过一个具备连接性的脚本就能够轻松实现。看 org-mode 的代码块部分的时候，其实就有这部分的主题。从之前我看的资料来说，更加偏重于可重现研究但不一定是文学式编程的必要部分。这样，后续的org-mode的学习，还是着重于对笔记、大纲以及文学式编程的内容。

通过这一部分文档的阅读，看得出来如果只是做简单的文学式编程的化，其实目前的功能支持基本上没有什么语言的限制了。由此，前面提到的各语言的支持文档只需要做一个泛泛的了解应该就可以继续我个人工作流的定制改进了。这是如何激活一个语言的说明，之前看多语言支持的文学编程以及可重现研究的论文的时候也接触了一点。其实根本原因就在于，对应的语言支持没开。上面的语言的支持配置，其实只有在需要执行代码的时候才需要。如果只是文学式编程，这些功能看起来没有开启的必要，因此，我自己的配置中保留了但是禁用了，以此保证我配置的最小化。

如果使用的很频繁之后，我们的自然习惯也会督促我们寻找一个比较合适的快捷键来实现类似的功能。org-mode的代码结构主要是简单介绍一下如何让插入的代码片段具备源代码的处理属性，比如说以一定的语法进行显示、执行、被某些程序或者代码块调用甚至是扩充出来的代码本身的处理结果等。只是明确了一下之前熟悉的代码结构，扩充了其他的等效实现方式，理清了一些处理的规则性问题。刚开始还以为没有包含shell，其实这里不仅有eshell还有一个CLI，而支持的关键词分别是eshell和shell，应该就是我之前接触到的内容了。

这样的功能，呈现给大家的不仅仅是一个文档与代码能够做到完美的一致。即使初始的设计可能会多花一些时间，但是随着时间的进行，文学式编程在可维护度上的优势应该是可想而知的。org-mode中的代码管理是比较复杂的，如果是文学式编程的话恐怕也只能算是org-mode功能的一个子集。设计的过程中，不再是考虑“我们要设计一个XX功能的计算机”的问题，而是转换为“我们希望计算机做什么”的思考模式。基于上面的信息的整理以及思考，看起来后续的文学式编程、可重现研究以及org babel，都应该是日后需要研究的主题。

其实，这个功能我一直在用，因为我近几年的emacs配置基本就是spacemacs，而这一套配置之中其实是由这个插件的。其实并不是这个插件本身的问题，而是我使用了evil，因此导致了C-u的按键用作了其他的用途。因此，测试这样的功能的时候，我尝试禁用了我自己配置中的evil才实现了几个参数选项的不同效果尝试。这样的一些信息有时候会让我觉得很有趣，软件的开发成长其实不是一时间的事情，而其背后，其实有很多有意思的小故事。从这个页面的介绍可以知道，其实这个插件的开发是受到了这个问题的启发。

有时候，我觉得我弄得一些代码不能够称之为是软件设计，只能叫做最为粗浅的脚本，兴许很多人的脚本设计都是有着精心的设计的，而不是简单的功能堆积。我觉得这个交互式模式下的一些功能设计功不可没，这不仅让emacs有了类似UNIX的shell交互模式，而且可以直接基于这样的功能进行二次开发，的确是非常好的设计。结合上面的字符串的处理，感觉上其实软件获取的全都是字符串，之后做了格式的转换。这一个交互函数在执行的时候就需要跟编辑功能挂钩了，这里的xy其实是获取的我们在emacs编辑器中选中一个区域的开始以及结束的位置。

之前，我采用的模板基本上是对着别人的一些现成的信息拿来主义直接用。当我编辑这一份文件的时候我遇到了一些导出以及显示相关的问题，在探索这一类问题的解决方案的时候参考了很多互联网上的信息。org-mode的标记功能是通过成对儿匹配的包裹字符来实现的，可以实现的标注效果有：加粗、斜体、下划线、删除线、阴影等。上面的内容只是一点开胃菜，只是记录一下为什么这段时间从成熟的富文本的模式又切换回了org-mode的模式。完成上面的解释例子列表的过程中，其实有一个很有意思的编辑操作技巧。*/_组合效果_/*

这个是文档信息，这里的value其实不是默认的数值，下一行中说明了它的原始值。这个是我测试的时候使用的一个参数。前面已经基本了解了org-mode的归档的规则或者方法，但是还有一点跟我现在的工作流有点不相符。我自己的工作流中会每月做一次工作的整理总结，因此归档的文件是按照年月份来进行归档的。而我的TODO清单的名字一直都是不变化的。修改之后，在配置文件中其实是能够找到这个基本的配置信息的。其实1和3的处理方式基本等效，但是我不是很想修改生成的文件属性信息，包括名称。接下来，我尝试查看这个变量的文档。

就比如说通过org维护一个工作清单，我的方式是把做完了的工作通过转移到其他的文件的方式来保持我清单的清爽。最后直接看看这个全部的归档效果，其实可以看得出来，这种归档有时候是会破坏掉整个树状结构的。因此，在归档的时候尽量是按照自己的理解，确认自己归档的这个树基本就是一个基础的单元之后再归档，否则的话可能会导致整个大纲框架的丢失。最后，处理掉第一行。这样看，其实789行只完成第9行也是可以全部归档到这里的，应该是类似的效果。不过，操作可以采用直接调用命令的方式，而我现在的命令支持模糊搜索，处理起来也会很简单。