Results tagged “emacs”

Magit 是 Emacs 的 git 前端，想对于在 Emacs 当中写完代码再切换到终端去 commit 代码，或者去做一些 diff 之类的操作，把一切都放在 Emacs 当中比较方面一些。而且想对于命令行来说，这种方式也更加直观。

想对于集中式的代码管理外，我感觉对于个人来说，分布式的代码管理更加灵活一些。我目前用 git 的功能也不多，很多高级功能我也还没有掌握。我主要是把 git 用来记录 log 更多一些，有时候建几个分支罢了。我目前主要的编码活动是用 Java 来写面向对象课程的作业，作业本身不算难，但弄出来的代码很多。几部分不能一下子就完成，所以我会完成了一部分之后就 commit 一下。我这学期的面向对象作业都是这么做的，从第一次就开始，感觉一直很好。

有一天我发现 Magit 突然不能 commit 了。每当我写完 commit log 之后，按下 C-c C-c 之后，就没有任何反应了。后台可以看到 git 进程，但 CPU 使用率是 0.0%，也只能手动杀死。杀死之后运行一下 git status 看看，根本没有任何提交，这就让人非常苦恼了。我目前使用 Magit 的感觉来说，其中最爽的一步就是提交了。写好了 log 之后看到之前的工作都进入了 repo 的那一刻，成就感是无与伦比的。这下子不能 commit 了，就让这种快感打了折扣了。

这个问题发生在我写第一次和第二次作业之间，当中我也没注意到发生了什么，突然就发生了这种问题。结果做第二次作业的时候感觉就不如第一次作业时那么顺了。不过那段时间比较紧张，我也没有去找到底是哪里出了问题。我印象里好像是把 Magit 从 0.7 升级到了 0.8 才有了这个问题。于是就尝试重装了几遍，但问题是依旧。我觉得这应该是一个 bug，于是就耐心等待看看下一个版本。

今天看到了 Magit 0.8.1 发布的消息，正好看到 Homebrew 里面也有了 Magit 的 formula，就安装了。安装好后我发现还是有这个问题，就去 issues 去看了一下，发现已经有人报告了同样的 bug report。底下有人回复说是 Emacs trunk 的问题，不过我印象里没有记得那阵子编译安装过最新版 Emacs。

第二条回复里说：“Setting 'magit-process-connection-type' to nil resolves this for me.”，我于是就试了一下，在 .emacs 文件里面加了这么一行：

(set 'magit-process-connection-type nil)

再在 Magit 里面运行了一下 commit，发现久违的 commit 又回来了。

在 Mac OS X 下编译 Emacs 非常简单，从 BZR 上下载（记得要用“--stacked”参数）最新的源代码后，运行

./configure --with-ns
make
make install

就可以生成 .app 程序包。自从我知道了这个方法之后，我一直在用最新的 Emacs。

过去我用 CarbonEmacs 的时候，曾经设置过 Emacs 的全屏功能，用着一直感觉不错。后来自己编译使用 Emacs 23 后，就再也无法全屏了。上网查了一下原因，知道是因为从 Carbon 升级的 Cocoa 的过程中，有一些功能还没有完全实现，而全屏功能就是其中之一，因此我不得不遗憾的暂时放弃了这个功能。后来我发现点两次窗口最大化键也可以勉强达到全屏效果，于是就这么一直凑合着。

今天在浏览 Emacs Wiki 时看到了一篇 blog 文章的链接，文章介绍了在 Cocoa 环境下全屏的方法。按照文章中的办法，略微变通一下，果然成功了。

文章中说，日本黑客 Daisuke Murase 给 Emacs 23 添加了全屏功能。他在 github 上放了一个 Emacs 分支，但除了他添加的新功能之外，这个分支一直没有跟着主分支一起更新。所以文章的作者 Steve 从一个“官方”的 Emacs git 分支 clone 了最新的代码，并合并这两个版本，但在合并的时候发生了冲突。于是 Steve 提取了这个更新（a3585f6c2a）的 patch 并成功的更新了代码。

我在 clone Steve 提供的 Emacs git repo 时速度非常缓慢，已经超出了可以忍受的范围，只好放弃，改用从官方的 BZR repo 来下载代码。但这样我就无法（不会）用 git 来合并 Daisuke 的分支了。不过我在看 Daisuke 的 git repo 的时候，发现他提到了他的分支与主流分支的合并冲突问题，并给出了 patch 文件。把这个 patch 下载下来后，在下载下来的 Emacs trunk 目录下，运行 cat feature-fullscreen.patch | patch -p1 后就按照上面的方法正常编译 Emacs 就好了。编译完成后，用 M-x ns-toggle-fullscreen RET 就可以像过去一样全屏了。

我照样喜欢把全屏功能绑定在 command+return 键上，在 .emacs 文件中加上一行

(global-set-key (kbd "M-RET") 'ns-toggle-fullscreen)

搞定。

既然说道改动 .emacs 文件了，我前两天刚刚也修改了一下功能，就是 set-mark-command 的键位绑定。Emacs 默认对这个函数的绑定是 control+space，但在 Windows 和 Linux 系统上一般被用来切换输入法，在 Mac OS X 下我又把这个组合键设定成了 QuickSilver 的快捷键，所以这个键绑定就失效了。因为我一直用的笔记本电脑，所以我之前在选定文字的时候，就干脆用鼠标板来手动划定，勉强可用。如果要选定整个 buffer，就干脆把光标送到开头，再送到结尾也算是变相的选定了全文，操作起来就是按住 Meta 和 Shift 键，在迅速的分别按 ,. 一下就好了（或许有“正确”的全文选定办法，不过这么多年了，习惯了:-)）除了用 control+space 来选定外，默认情况下用 C-@ 也可以同样的呼叫 set-mark-command，但我一直以来都觉得这个组合键的反人体工学达到了变态的程度。而 M-@ 这个组合键虽然同样需要三个键，但却更加顺手一些。M-@ 默认的绑定是 mark-word，就是选定一个词组，这些年来我从来没有用过这个功能。于是前天我“痛定思痛”，决定彻底解决这个问题，就是把这两个键绑定切换一下。于是在 .emacs 里面加上了这么两行

(global-set-key (kbd "M-@") 'set-mark-command)
(global-set-key (kbd "C-@") 'mark-word)

于是世界清净了。

有些时候最可气的是，明明有个东西你知道见过，但用的时候就是找不到了。

我这学期网络课的项目要求在明天之前交 Proposal，要求中说如果是用 LaTeX 排版的可以有加分。我这学期之前一直在用 ConTeXt，这学期一直在用 Emace Muse 和 org-mode，感觉很长时间没有用过 LaTeX 了。开始的时候我想接着用 ConTeXt，毕竟感觉熟悉一些，但在 Emacs 中打开一个 .tex 文件却提示错误。我才想起我这个自己编译的 Emacs里面还没有安装任何 ConTeXt 的支持。后来为了方便大家一起工作，决定用 LaTeX。之前加上 AUXTeX 插件的 Emacs 也用惯了，于是我就自己装一次 AUCTeX，既为了这次使用，也为了将来编辑 ConTeXt 时用。

AUCTeX 支持通过快捷键来编译文档。我过去用的应该也是 AUCTeX，但一直没有用过快捷键，因为一直不知道有这个功能。我一般都是或者用 compile 命令，或者按 M-! 来执行 pdflatex 命令。而 AUCTeX 的快捷键的好处就是编译完成后，有没有问题都在 mini-buffer 里面告诉你，而不会把窗口切成两半再出来一个新的 buffer。按 C-c C-l 之后才会调出编译的结果，所以我就一直在用快捷键。

但它有个问题，就是 Emacs 找不到 latex 命令。我用 (getenv "HOME") 检查了一下，发现 Emacs 并没有载入我在 .profile 文件里面设置的 PATH 变量。这样的后果是，AUCTeX 找不到 latex 命令，因为它们都不是安装在默认的 /usr/bin 和 /usr/sbin 目录里面。这让我相当苦恼，不仅 AUCTeX 没法用，原先我的那种 M-! 调用外部命令的方法也不行了。

我印象里之前看过让 Emacs 识别 .profile 文件里的 PATH 设定，但从来没有想到自己也有用到的一天。这次我从网上用各种关键字搜索了很长时间，还是没有找到。CarbonEmacs 在这方面工作是正常的，不过我也没有仔细研究过 CarbonEmacs 的目录分配，不知道相关的设定文件在什么位置，一时间也找不到。

后来我想过一个折衷方法，把 AUCTeX 的 latex 命令设定成绝对路径，也就是在 .emacs 文件里面加上这么一行 (custom-set-variables '(LaTeX-command "/usr/local/texlive/2009/bin/universal-darwin/latex"))。但我发先这样的话，单纯用 latex 是没问题了，但要想用 PDFLaTeX 直接生成 PDF 文件，而不是生成 DVI 文件后再转换成 PDF 文件的话，这样做就没用了。原来是 AUCTeX 没有给每个编译命令设定不同的命令行，而是直接偷懒，如果是想调用 PDFLaTeX 的话，就直接在 LaTeX 的命令行前面加上 pdf。这样的话，AUCTeX 生成的 PDFLaTeX 命令行就成了 pdf/usr/local/texlive/2009/bin/universal-darwin/latex，自然找不到相关的程序了。

后来我没办法，直接用笨办法，在 .emacs 里面设定 PATH 变量。也就是加上这么一段：

(setenv "PATH"
        (concat
         "/opt/local/bin" ":"
         "/opt/local/sbin" ":" 
         "/usr/bin" ":"
         "/bin" ":"
         "/usr/sbin" ":"
         "/sbin" ":" 
         "/usr/local/bin" ":"
         "/usr/texbin" ":"
         "/usr/X11/bin"
         (getenv "PATH")
         )
        )

这种方法，我参考了 Xah Lee 的文章。

不知道是不是心理作用，我试验了这种方法之后，总是觉得启动的速度变慢似地。不过这样确实是在设定程序里面加了一些不应该添加的东西，因为他们降低了 .emacs 文件的“可移植性”。所以我又在找其它的办法，于是我找到了这篇文章。文章介绍了通过设定 Mac OS X 本身的 plist 来让 Emacs 获取设定的路径。方法是在终端里面运行 defaults write $HOME/.MacOSX/environment PATH “$PATH” 这么一行。我试验了之后，手动观察了一下 ~/.MacOSX/environment.plist 文件，发现里面是乱码。我对 plist 文件的格式不了解，以为是系统给编码了。文章中说执行完这行命令后，要重启一下计算机才行，我也乖乖重启。但重启之后却发现 Emacs 中根本还是老样子。

印象里 Mac 自带了一个程序，可以编辑 plist 文件的。我于是找了一下，发现了 Property List Editor.app 程序。进去后打开了 ~/.MacOSX/environment.plist 文件，试着把乱码改成了 PATH 变量里的内容，再重启之后就好了。不过这样也不是很完美，我查了一下系统的 PATH 变量，有些路径出现了两次，不过不影响使用。

这件事给了我又一个 Mac OS X 系统与 UNIX 系统之间的不同的地方。可能是为了兼容旧程序，Mac 没有统一实行一个策略。既然已经有了 PATH 方式，为什么还要弄个 plist 让某些程序读取呢？我觉得 UNIX 传统的路径政策是非常好的，通用、设定起来也方便。Mac 的很多这策是只给用户提供一种最通用的办法，而这种情况下，一个简单的路径就有了不同的设定方案，两者还不统一，确实给用户带来了麻烦。

在上一篇文章之后，我在使用自己编译的 Emacs 23 的过程中遇到了一些问题。对于这种经典的编辑器，目前使用的人不多的情况下来说，找一个用户比较集中的地方是提问题的正确地方。USENET 新闻组在我的印象里来说一直太正式，让我每次在上面发帖都战战兢兢，因此比较宽纵的 IRC 自然成了一个很好的去处。

我上的 IRC 频道是 irc.freenode.net 的 #emacs 频道。虽然刚上去的时候也是有点发怵，但当提交了一个问题并与上面的人进行讨论的时候，我感觉到对方也并不是那么遥不可及，于是就放下心来与对方交谈了。

与我有时上的另一个频道 #ubuntu-cn 不同，#emacs 属于比较纯的技术频道。而 #ubuntu-cn 虽然打的 Ubuntu 的名号，但最近我上去的过程中发现里面的交谈绝大部分属于闲聊，可能是被国内的风气给逼到 IRC 这个小角落里面来了，我不喜欢这样的情况，于是后来上这个频道的次数就少了，虽然这是为数不多的比较活跃的中文频道。

#emacs 频道里的灌水就少的多了，多数是问问题的。有时候也会出现几个人之间在谈论一些无关话题，不过并不占讨论的主要部分。

由于 IRC 在国内不流行，我上 IRC 的次数也少，因此一些 IRC 频道的常见活动我见到的不多。不过在今天我“有幸”见到了一次踢人。有人在频道里发广告，然后几秒钟之后管理员就把那人给踢了。情节记录如下：

第一次见到这种情况，还是感觉很好玩的。

我的 IRC 客户端使用的是 ERC，一个运行于 Emacs 上的 IRC 客户端。我几乎是从一开始就用它，到目前已经习惯了，并很难换到其它的客户端上了。虽然对于 IRC 的操作，客户端所占的比例不大，但我的印象里进行聊天活动时能用到 Emacs 的键绑定是最爽的。其它程序可能可以使用 Emacs 的键绑定，但肯定比不上在一个 Emacs 的 buffer 里上 IRC。我最早使用的是 xchat，比较基本，没有什么特殊功能，但可以在 X 上运行。那时没有入门，后来发现了 ERC 就放不下了。还有人喜欢用 Irssi，我印象里试用过一两次，但没有给我什么深刻的印象，更不用说它的官方网页的标题 “The client of the future” 了。

在日常的“非主流”网络交互中，除了 IRC，我还经常上 USENET。如果说我有时会在 IRC 上说话，那么我在 USENET 就几乎是完全潜水了。我感觉 IRC 可以是一般人交流的地方，USENET 上就是藏龙卧虎了。我在上面见了许多人，他们的文章都相当的有深度，我能学到很多东西。

既然是一个 Emacs 用户，我的 USENET 客户端自然就是 Gnus 了。我过去曾经在 Linux 下用过 Thunderbird 之类的电子邮件客户端来上 USENET，不过那段日子就没有什么印象了。我在使用 Linux 的后期也用 Gnus 当过电子邮件客户端，不过在配置 Gmail 的时候废了很大的劲，至今也没有心得。后来用了 Mac 后，收发邮件没理由放着 Mail.app 不用，自然就不用 Gnus 了。不过上新闻组也不用再装一个客户端了，之前的 Gnus 配置拿过来就直接用了。时间长了之后我也忘了一些设定的功能是什么了，不过倒是不影响使用。Gnus 的功能非常博大，我掌握的只有极少的一部分，也就是几个组合键而已，不过用来上新闻组也够了。

作为一个北美大学，我们学校倒是提供了一个本地的新闻组服务器，这让我感觉不错。服务器是内部的，需要用户名和密码才能登录。它的好处是速度快，缺点是中文的新闻组一个也没有收录。不过中文的新闻组也没有什么地位，我之前找过很多免费的新闻组服务商，几乎没有提供中文新闻组的。之前用过的一些国内新闻组好像很多都关门了，比如千网之类的，我在这里就链接不上。之前印象里济南还有一个当地的新闻组，我在中学的时候还经常上去看看，现在也没了。最后好歹找到了 freenews.netfront.net 这个新闻组，缺点是发送的消息最后都会跟上 netfront 的广告，也只好忍了。不过我很少上中文新闻组，目前跟踪的一个也只有水木 BBS 上的 Emacs 版面而已了。我们学校有些课程会在本地的服务器上开设讨论组，不过也只有一些年纪比较长的教授才会用它，比如这学期我们的操作系统课就有一个讨论组，里面全是教授发的通知，学生在里面说话的可能只有我一个人吧。对于这些讨论组，我倒是感觉很高兴，计算机系的学生毕竟不应该荒废了这些“遗产”。

IRC 和 USENET 这两个老牌的在线交流工具，上面中国人的身影越来越少了。虽然它们可能有点过时，但其它国家总是有很多铁杆支持者在上面驻守，而中国人则寥寥无几。不知道这是不是说中国互联网落伍了呢？或者是由于发展的比较晚，与西方国家相比，中国的网民有了断层呢？

Emacs 已经成为了我的计算机上的必备软件之一。平时如果写一些规模不算大的程序，我一般都是用 Emacs （Emacs 有 ecb 可以用来管理项目，不过我还没有入门），而日常上 USENET、上 IRC 更是离不开 Emacs。记不清我在用 Linux 的时候用的是什么版本的 Emacs 了，印象里我要对中文支持进行一些设定，所以我估计当时用的是 22 版本的。很早就听说过 Emacs 23 对中文支持有了新的高度，但限于条件，我好像一直没有使用过。

到了 Mac 平台后，我刚开始不知道有什么 Mac 上运行的 Emacs 程序包，以为 Mac 上只能使用原生的 Mac 程序（我可不想在 Mac 上用 X 来运行 UNIX 软件，实在是太丑了，也不习惯），所以当初还买了 TextMate。当时我急着完成作业，急切的需要一个好的编辑器。后来我找到了一些 Mac 上可以运行的 Emacs，立刻就把 TextMate “打入冷宫”了。TextMate 的问题，除了它不支持中文外，最大的问题还是按键上还不是完全模仿 Emacs 的，有些细节的地方还不方便。而 TextMate 被广为称道的 Bundles，我在看一些 Rails 演示视频的时候看那些人用的很熟练，但后来觉得自己实在是很少有机会用到这些功能，而且那些组合键也很难记忆，所以我反而一直没有用上。

我在寻找 Mac 上可以运行的 Emacs 时试用过不少版本，开始时用的版本配置的都不是很好。尤其是 Meta 键的配置，映射的是 option 键，而 command 键则被用来当作 Mac 自带的组合键来使用，比如用 command+c 来复制等。我还不是一个“资深”的 Mac 用户，所以在用 Emacs 的时候，我更喜欢用 Meta+w 来复制，而不是用 Mac 的组合键。当时我也不知道怎么把 meta 映射到 command 键上，所以这些版本的 Emacs 都被我忽略了。后来我找到了 CarbonEmacs，一个日本人做的版本，里面包含了各种配置，其中就有我需要的 meta 键映射。另外默认的还有很多 lisp 包，比方说各种模式，用起来很方便，于是我就一直用它了。

话说对于完美的追求还是永无止境的。前几天在查 CarbonEmacs 的版本的时候，发现居然还是停留在 22 版本上。随后我也意识到似乎 CarbonEmacs 也有半年多没有更新了，于是就到它的网页上去看了看。看到了有个 2010 Edition。新的一年有了新的版本，不错。不过看了一下版本还是停留在了 22 上，而我希望的版本是 23。除了 23 > 22 这个原因之外（:-)），还有对于 Unicode 的支持也是我希望升级的原因。我印象里在 2007 年用 Linux 的时候，就有人在用 Emacs 23 了。新版本的 Emacs 对 Unicode 的原生支持，使得它不需要额外配置就可以正常的显式中文。CarbonEmacs 的多语言设置虽然好（毕竟作者是日本人），但有些偏字，比如说前总理的名字，就无法正常显式，在 23 版本中，就非常正常了。另外的原因是我想在 Mac 平台上使用 Cocoa 而不是老旧的 Carbon。于是我就搜索了 “Cocoa Emacs”，看看有没有使用 Cocoa 的 Emacs 包。

我找到了几个有二进制包下载网页，比如说 AquaEmacs 等等。不过它们都有一个问题，就是 command 键映射的不是 Meta 键。这一点让我非常苦恼。我从 CarbonEmacs 的包里面找了半天的设定，也没有找到。后来在 Emacs Wiki 上找到了不同平台上 Emacs 的安装方法，上面有在 Mac 平台下通过编译来安装 Cocoa 版本的 Emacs 的方法。通过编译可以把 Emacs 编译成 Mac 下的 .app 包，这是我希望的，而且有之前使用过 Gentoo 的经验，对于编译也没有太大恐惧感，还有本地编译的一些好处，我就尝试了一下。由于所有的 Mac 平台的硬件和软件都是统一的，所以编译安装十分容易。下载了 CVS 的代码之后，输入两条编译命令，大概20分钟就编译完成了，不会出现问题。

用惯了 CarbonEmacs 的 all-in-one 的软件，一下子上到自己编译的 Emacs 下还有些不习惯，因为很多 lisp 包都没有，需要自己安装，这让我第一次面对错误提示时有些愣神。不过等反应过来后，要解决问题也不难，少那个包就下载下来放进 site-lisp 目录里就行了，最后再 byte compile 一下也就完美了。我的 .emacs 文件不算大，里面也没有用什么偏门的包，所以都很好解决。我曾经想过像 CarbonEmacs 那样把所有的第三方 lisp 包放进 .app 目录里面，这样要想移动 Emacs，只要复制一个 .app 目录就行。后来还是放弃了，因为这样会把目录弄的很乱，而且如果在本地机器上再更换 Emacs 的话还要再把包复制到新的目录下。倒不如放进 HOME 目录下一劳永逸。

不过最关键的问题是解决 Meta 键的映射问题，从网上搜索我也找到了解决方法，这也是推动我升级的动力之一。方法就是在 .emacs 文件里面加入这么一行：

(setq ns-command-modifier (quote meta))

这之后就可以把 command 键来当作 Meta 来用了。

有了这些之后，其它的问题其实也就迎刃而解了。不过还是有些兼容性的问题是无法解决的。首先就是全屏模式在 Cocoa 下还没有实现，因此目前为止还没有任何一种方法来完成全屏显式。之前在 CarbonEmacs 下很舒服的用 Meta+Enter 来切换全屏与窗口的方式也就不行了，这让我有点耿耿于怀。不过还在它也不算什么大问题，需要用全屏的话，按两次窗口上的最大化键也勉强可以用。

还有一个大问题是字符的颜色问题。我估计可能是 Cocoa 的原因，光标落在字符上，字符并不反色显式。这一点无论是我用默认的颜色设定还是我用 color-theme 里多数的 theme 时，都让光标下的字符很难以识别。我对照了目前版本和 CarbonEmacs 的颜色设定，都是一样的，因此也不知道怎么能设定好。把 CarbonEmacs 的 color-theme 的 lisp 设定复制到 Emacs 23 上也还是一样，这让我很苦恼。我还去 #emacs IRC 组上去询问，也没有好的方法。最后通过把光标设置成闪烁模式，算是勉强解决了问题。

汉字显式可能是没有完全设定好，目前在 Emacs 23 下的斜体汉字是无法显式的，所有的斜体汉字都被用方块来代替了。我觉得通过设定应该能解决这个问题：或者让汉字不用斜体显式；或者让 Emacs 能使用斜体的汉字。但由于我日常很少让 Emacs 显式斜体的中文，所以也就没有去深究这个问题。

几天用下来，除了上述的一些小细节之外，其它的都没有什么问题。Emacs 23 确实有了一些新功能，不过总体上来说我常用的操作都没有改变，这也算是经典软件的好处了。

我们这学期有门课《专家系统》，课上用到Jess。因此，让Jess在我们自己的环境上运行起来就是我们前几节课的任务。

Jess是用Java写成的，运行在Java虚拟机下，因此在Mac上运行不成问题。今天尝试了一下，除了把路径中的空格给删除之外，似乎直接就能运行。Jess里的bin目录下有jess这个shell文件，我把整个Jess目录放到了/opt下，并在/opt/local/bin里面做了一个软链接，就一切正常了。

我平时用Emacs比较多，因此就想在Emacs里编辑Jess程序。我估计Jess是在Windows下开发的，因为老师给我们的程序包中有TextPad的Jess语法文件。同时，老师也提供了用eclipse当环境的方法。其它的就需要我们自己探索了。

我从网上找到了Jess-Mode，把它给的两个.el文件放在了自己的site-lisp目录中，并按照页面上的要求修改了.emacs文件。但却不能正常运行，说shared-lisp-mode-map这个变量没有值什么的。我对相关方面的编程不是很了解，就胡乱试试，在用到这个变量前面随便加了一行

(defvar shared-lisp-mode-map t "hello")

再试，就可以了。网站上没有提到这个问题，因此我不确定是不是我的CarbonEmacs的问题。

解决了这个问题之后，其它就没有什么问题了。

昨天在写文章的时候，提到了Google Wave和谷歌翻译助手以及维基百科的结合，顺便让我想到了一件事情。

先说Emacs。在一些人严重，Emacs可以算是个完善的工作环境了。除了日常的文字编辑之外，Emacs可以上网、操作ftp、运行shell、远程编辑、上irc、上usenet、玩游戏……这一切都已经超出了一个编辑器的范畴。而Emacs以编辑器为基础，竟然也可以很好的完成这些工作，虽然有些不可思议的感觉，但又让人觉得很自然。

再来看Google Wave，突然觉得Google和Emacs非常相似。从本质上来说，用户的工作界面就是一个编辑器。所有的同步功能，都在编辑器里面实现。真正让我想到Emacs的地方是Google Wave里面可以查阅并更新Twitter信息，而这些也都是在那个编辑框里面完成的，可以说是与Emacs神似了。

把一切看作编辑器，看似不大可能，但真正使用起来却并不觉得突兀。我想这大概是某种思想，具体是什么我说不好，但似乎有些东西可以应用在很多事务上。除了编辑器的许多功用外，UNIX系统的一切都是文件应该也有这种思想。