mint 用过一阵子，因为编程全都是 ssh dev server emacs 所以，其实对 desktop 的要求是很低的，用起来从来没觉得哪里不爽过。配合 google 的全套服务，日常办公也很好用。玩游戏就不用折腾了。后来为了装 13 才换了 mac ，很怀念的说。

@chainkhoo 囧

这个问题踢到铁板讨论不下去了吗？

翻墙或者找加速地址。

markdown 很顺手，用的人越来越多，想必是不会死掉的。

@reorx 多谢建议，我们会考虑，是否有必要推出其他更简洁的布局。

weibo／twitter fav 导入这里有点 tricky 想问问大家的意见。
weibo 的 fav 是私有的（在 weibo 里，只有你自己可以看到你的 fav），所以，导入之后默认私有。
twitter 的 fav 是公开的（在 twitter 里，谁都可以看到你的 fav），所以，导入之后默认公开。
貌似不大好理解，大家觉得有没有必要搞成全部都是私有的？

另外 微博／twitter 的 fav 导入是一次性的，不会重复导，但 unfav 就没有导入。

可以删，导入之后不想要，直接删了就好。

晕，漏掉了一个 0 全部都用 hash route 的页内地址伤不起。
功能说明页是 http://cliclip.com/#help/0

忘了贴 API 的文档地址： http://github.com/cliclip/htm/wiki/API-Document

aws 的 api 基本都是 build 在 http restful 的接口之上，so，这个早该出了。

debian，build from source 前一阵子还是 0.6.x 有很多 native 依赖的 module 伤不起呀。

嵌套层次太多确实难看。要追求漂亮，但不能以失去灵活性为代价。

@luin 论坛氛围不错，我改写了例子，希望能把问题引向更深入。
主要的改写是引入了需要传递更多因素的情况，来表达这种灵活性在使用 control flow module 之后的丧失。

http://gist.github.com/4214679.js

引入之后，感觉有两个问题。

传参自由度的问题：

第 6 行分别引用了两个外层里定义的 id 和 val 。对应在 async 写法的第 24 行，是不 work 的。要解决这个问题，需要显式地向外用 callback 传递或者引入一个 params object 来解决问题。需要传递的参数更多的话，可能更麻烦。

async 的思路是通过 callback 的参数传递给下一个 function 。各个 function 的变量作用域是并列的，也就是说，嵌套层次的扁平是以引用外层变量的能力作为代价的。

错误处理自由度的问题：

上述每一个错误都给了一个不同的错误处理，之前的例子是全都用 next(e) 来处理，所以，体现不出这种约束来。在 async 的版本里，所有的错误都汇集到 27 行来处理，要如何区分这许多种错误呢？

我也有用 async ，主要是用它抽象数据结构的相关方法，比如 map 之类，但 control flow 的因为上述的问题，就暂时还没有用。

@linlinqi 这是否意味着需要在 callback(e,r) 的 node.js 标准风格和 deferred 风格之间做适配呢？这个适配，在 node 没有推出标准的 deferred 风格之前，似乎是没有动力去完成的。

还是那句话，要追求漂亮，但不能以失去灵活性为代价。我知道这可能有些不切实际，必然要 trade off 什么的。不过，思考一下倒也有益。