- 主题:发现一个影响办公效率的问题
既然是搜索，如果结果不是unique的，产生了ambiguity怎么办？
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 大概05年前后，我觉得所谓的目录管理有条理是个伪命题。因为一个文件你可以按照不同的维度去切割分类，你分的越细越有条理，就越容易遇到另一种非常难检索的维度。
: 于是我基于fuse做了一个虚拟文件系统，把目录的层级作为搜索关键字，比如cd a/b/c，进入的目录其实就是用a b c作为关键字去搜索匹配后的所有文件。这里因为是关键字，所以顺序就不重要了，cd c/b/a和a/b/c的结果是一样的。也即你可以随心所欲的按照你想要的tag cloud方
: 总之，要完善细化还需要不少后续工作。但我觉得这个基本理路是可以针对这类需求的。
: ...................
--
FROM 117.10.133.*
厉害，以后cd命令要内置强化学习了
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 这就是核心问题了。
: 首先考虑duplication，这个感觉是可以合并的。但编辑文件的时候就又有问题了，因为一份文件在几个目录里面复制几遍完全合理。有的场合是只更新其中一个，有的场合又希望全盘所有副本同步更新，具体要哪个是我说了算的。
: 其次就是你说的ambiguity问题。结合duplication问题，我不得不对模型进行了一些简化。在你不断cd（也即不断提供更多的搜索关键字）的过程中，返回的结果是从全盘搜索结果的aggregation到一个精确的sub folder的逐步过渡过程。最终在你提供了足够的信息，完全消除歧义之
: ...................
--
FROM 117.10.133.*
虽然我觉得tag很好，但是肌肉记忆还是主导着每次都键盘敲关键词去spotlight而不是选tag，可能这个确定集合的思考过程的内在成本太高，大脑觉得不够直接吧
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 对，简单的说我们标记文件有两种思路。
: 一种是文件系统目录，是包含关系。
: 另一种是tag cloud，是并列关系。
: ...................
--
FROM 117.10.133.*