【发布时间】：2009-08-04 19:57:21
【问题描述】：
首先，我终于把它做成了一个 wiki，但我相信一个“简单”直接的答案是非常可取的，特别是因为结果将为每个人定义一个统一的 IDE 行为。稍后再详细介绍。
过去，我曾在博客上写过 well-behaved member selection 下拉菜单意味着什么。如果您还没有阅读，请立即阅读。 :)
Visual Studio 2010 为 IntelliSense 选择过程添加了新功能，这让事情变得……不那么容易了。我相信我们可以利用这些功能发挥强大的作用，但如果没有一套清晰的管理规则，这将非常困难。
在您回答之前，请记住这一点： 与其他解决方案相比，规则应该允许与系统“协调一致”的人以更少的击键和更少的时间利用 IntelliSense 功能。这不只是你习惯的 - 如果你像我一样长时间和频繁地使用一个系统，那么重新学习模式是微不足道的，因为它可以节省时间以支持一个伟大的算法.
以下是可控轴：
- 过滤：“完整”列表包含当前位置允许的每个标识符或关键字，而不考虑光标所在的部分键入的文本。
- 排序：我们（至少是 Visual Studio 用户）习惯于按字母顺序对成员选择下拉菜单进行排序。其他可能性是通过某些概念“相关性”等进行部分排序。
-
选择：根据当前键入的文本，我们可以选择一项作为“最佳匹配”。选择状态是：
- 未选择任何项目
- 被动选择：勾勒出一项，但按
.、<space>或类似方式不会在不使用箭头键的情况下填写： - 活动选择：选中一项，除非
Esc或箭头键被按下，否则.或<space>等将自动完成该项。
我之前的一组规则将操作限制在选择轴上。他们考虑到：
- 使用
StartsWith操作（前缀匹配）匹配列表项键入的字符，以及匹配是否区分大小写的变体。 - 以前的补全以相同的字符集开头。
以下是额外可用且可能有用的，但并非必须全部使用：
- CamelCase 匹配或 underscore_separation（“us”）：长的、富有表现力的标识符？没问题。
- 子字符串匹配：长前缀阻碍了您的选择速度？没问题。
- 摘要文本中可用的信息（如果有）：我反对这一点，但我必须承认它在 Firefox 地址栏中很方便，所以你永远不知道。
您编写的规则应按顺序处理轴（上面的粗体）。在我之前关于该主题的帖子中，规则非常简单，但额外的考虑可能会使这变得更加复杂。
- 过滤
- 排序
- 选择
【问题讨论】：
-
亲爱的给我打分的人：我大部分时间都在努力改进开发人员的日常工作。我如何试图进一步解决这个不是真正的问题？
标签： algorithm language-agnostic ide intellisense