Omnibar

人，总是先遇到什么，然后选择什么，最后相信什么。

我一直习惯于用 Chrome 的扩展 vimium 浏览网页。vimium 有一个叫 omnibar 的搜索功能，在一个搜索框中，能够实现搜索历史记录，书签或者是已打开的标签，也可以直接访问连接，调用搜索引擎。

对于经常需要在历史记录和书签中找资料的人来说，这个功能非常实用。omnibar 提供了一种快速访问浏览器资源的方式，而实际上，类似的功能在其他很多软件中都存在。

无处不在的 omnibar

在 vscode 中，这个功能叫做 command palette（命令面板），能够调用几乎所有命令；IntelliJ IDE 中可以通过 shfit+shift 搜索几乎所有内容，包括变量、函数定义、文件、设置和命令等等。 在 Mac OS 系统自带的 Spotlight 能够搜索程序、文件或调用搜索引擎；在 Windows 下有一款叫 Listary 的程序也能实现类似 Spotlight 的功能。

具体搜索的内容， 根据软件的性质的不同而不同，但总的来说，可以以定位资源来统称。资源可以是文件、函数定义或网页，也可以是一个能够执行的功能。omnibar 几乎是能够引入到所有软件中的功能。

omnibar 是什么

在我看来，omnibar 是一种通过搜索来实现所见即所得的方式。在脑机接口还未实现的现在，人机接口中，向计算机输入结构化信息带宽最大的方式仍然是键盘。人的想法转化为动作，传递到手指，手指敲击键盘，作为输入信号传达到计算机程序，而传递的内容带有语义信息。资源命以人类语言的基础上，在搜索的过程中，并不需要记住一个资源的完整名称，只需要记得名称的一部分就能够搜索到，而对资源的描述越完整，语义越清晰就越容易记忆，也就意味着越容易找到。至于资源名可能相同的问题，引入命名空间，其本质上还是字符串，就能轻易解决。这种记忆信息少，但定位信息准确的方式在各种场合都可以得到应用。

在 Emacs 编辑器中，可以按下 M-x，通过函数名来直接调用函数，而 emacs 的函数名即能在一定程度上说明这个函数本身的功能。在 emacs 中能够实现所谓的文学编程，即能够运行的文档。而具备语义的函数名也能体现这种思想。名称、功能、描述、实现可以统一起来，这是文学编程的魅力所在，在 omnibar 中，也能不怎么费力地实现这种统一。

在对比没有使用 omnibar 的场景，传统的功能映射方案有两种：菜单栏和快捷键映射。定位菜单需要视觉的大量参与，而“想”这个动作本身不能很快地传达到视觉功能上（暂且认为眼神不能对计算机传达想法），以图形为中间介质的信息传达必定在某种程度上降低了信息的传递效率。绝大多数的快捷键没有语义，这意味着只能够机械记忆。

从人的表达和记忆信息的角度而言，omnibar 在两个方面都具备传统功能映射方案所不具备的优势。

虽然找了这么多理由来解释 omnibar 究竟为何如此方便和强大，实际上它就是 console 或 repl 的弱化，在图形界面加入命令行，基本上就只有图形/命令两种交互方式，现在两种方式都具备，即所谓双剑合璧。

omnibar 还可以是什么

Omnibar 的未来已经露出了一点苗头。近几年流行的语音助手和当下流行的智能音箱都是在通过识别的人命令来执行来特定功能，基本上就是语音版的 omnibar，虽然前两者的可用性依旧堪忧。

实际上，我并不需要什么语音助手，在绝大部分时候，我很确定自己想要什么，而所谓的语音助手只是在将机器拟人化。机器自有其语言，让机器试图理解这些人类自己都感到理解困难的自然语言，很有可能是曲线救国。假若机器会有语言，它们的语言绝不会想自然语言一样允许歧义的存在。

给一切资源适当详细的描述，再加上一个强大的模糊搜索引擎，还不够的化再加上命名空间，即便没有用户界面，也没有语言聊天，就已经足够了。

未来或许还会有许多语音助手之类的东西冒出来，不用感到迷惑，但它们顶多也就是 omnibar 罢了。