通用智能感知新的全面实现
我有兴趣为SQL和C＃编写一个支持通用智能感知的编辑器（如果可能的话，等等）。 我想这样做在C＃中作为重写或扩展的WPF richTextBoxtypes的控件。 我知道有很多示例项目可用，我已经实现了我自己的基本版本; 但我所遇到的大部分例子（甚至是我自己的）都是基本的 。
几个代码示例是：
-
DIY智能感知由yetanotherchris
-
CodeTextBox – 另一个RichTextBox控件，带有语法高亮显示和Intellisense By Tamas Honfi
然而，我已经find了一个很好的例子，使用Intellisense的QueryCommander SQL编辑器作为MikaelHåkansson似乎工作得很好。 微软必须使用命令关键字的XML库，但是我的问题是：微软如何（详细地）实现他们的Intellisense（as-you-type Intellisense），以及如何创build我自己的同样的标准？
编辑 – 答：一年，我已经设法开发我自己的编辑器控制基本intellisense主要是为了我自己的“享受”。 我想我会回来提供一个免费的.NET项目清单，帮助我进行自己的开发，并可以使用开箱即用和免费的：
-
ICSharpCode（WinForms）
-
AvalonEdit（WPF）
-
ScintillaNET（WinForms）
-
Query Commander [例如intellisense实现]（WinForms）
编辑B：问题提出15个月后，我仍然在寻找新的改进编辑。 这个很好…
- RoslynPAD很酷！
编辑C：2年+的问题，我已经find了以下项目，都使用WPF和AvalonEdit的支持。
-
使用NRefactory的AvalonEdit的CodeCompletion 。 这个项目真的很不错，使用NRefactory完全实现了智能感知。
-
ScriptCS ScriptCS使用简单的文本编辑器轻松编写和执行C＃。
微软如何（详细）实施他们的即用型智能感知？
我可以把它描述成你所关心的任何细节层次的名字，但是我没有时间做一个简短的解释。 我会解释我们在Roslyn如何做到这一点。
首先，我们使用可高效地表示编辑的数据结构构build令牌stream的不可变模型，因为明显的编辑正是将会有很多的东西。
使持久重用高效的关键洞察是在编辑缓冲区中表示令牌的字符长度 ，而不是它们的字符位置 ; 请记住，文件末尾的标记将在每个编辑中更改位置，但标记的长度不会更改。 无论如何，如果您想要在极其庞大的文件上保持高效，您必须不惜一切代价最大限度地减less重新陷入困境的次数。
一旦你有一个不可改变的模型，可以处理插入和删除操作来build立一个不可变的标记stream而不需要每次重新整理文件，那么你就必须做同样的事情，但是要进行语法分析。 这实际上是一个相当困难的问题 。 我build议你获得计算机科学的本科或研究生学位，如果你还没有学习，那么你的parsing器理论的重点。 我们获得了博士学位的人的帮助，他们在parsing器理论上做了一些devise这一特定algorithm的部分。
那么，显然，build立一个可以分析C＃的语法分析器。 请记住，它必须分析破碎的 C＃，不正确的 C＃; 当程序处于非编译状态时，IntelliSense必须工作。 因此，从修改具有良好错误恢复特性的语法开始。
好的，现在你已经有了一个parsing器，可以高效地进行语法分析，而不需要重新编译或重新parsing除编辑区域之外的任何东西，大部分时间，这意味着你可以在击键之间完成这项工作。 我忘记提到了，当然你需要想出一些机制来阻止UI线程，而所有这些分析如果分析碰巧需要比两个击键之间的时间更长的时间。 C＃5的新“asynchronous/等待”function应该有所帮助。 （我可以从个人的经验告诉你：注意任务和取消令牌的扩散，如果你不小心，就有可能进入成千上万取消待处理任务的状态，而且速度不是很快 。 ）
现在你已经有了一个语法分析，你需要build立一个语义分析器 。 既然你只是在做IntelliSense，它不需要是一个特别复杂的语义分析器。 （我们的语义分析器必须做一个适当的分析，从正确的程序生成代码，并纠正不正确程序的错误分析。）但是，当然，它也必须对破坏的程序进行良好的语义分析，这大大增加了复杂性。
我的build议是首先构build一个“顶级”语义分析器，再次使用一个不变的模型，可以将源代码types的声明从编辑状态保存到编辑状态。 顶级分析器处理任何不是语句或expression式的types：types声明，指令，名称空间，方法声明，构造函数，析构函数等等。 当编译器生成元数据时，构成程序“形状”的东西。
元数据！ 我忘记了元数据。 你需要一个元数据阅读器。 您需要能够在引用库中types的expression式上生成IntelliSense。 我build议使用CCI库作为元数据阅读器，而不是reflection。 既然你只是在做IntelliSense，显然你不需要元数据编写器。
无论如何，一旦你有一个顶级的语义分析器，那么你可以编写一个语句和expression式语义分析器来分析给定语句中expression式的types。 特别注意名称查找和重载parsingalgorithm。 方法types推断将特别棘手， 尤其是在LINQ查询中 。
一旦你掌握了所有这些，一个智能感应引擎应该很容易; 只需在当前光标位置处计算expression式的types并适当地显示一个下拉列表。
要创造我自己的同一个标准有多难？
好吧，我们有一个团队，把它叫做十个人，这可能要花五年时间才能把整个事情从头到尾地完成。 但是我们还有很多工作要做，而不仅仅是智能感知引擎。 这可能只有40％的工作。 哦，还有一半的人在VB上工作，现在我想到了。 但是这些人在做这类工作的时候大概也有五，十年的经验，所以他们比以前从未这样做的速度要快。
所以我们假设应该花费大约十到二十年的全职工作时间，单独工作，为C＃构build一个Roslyn级质量的IntelliSense引擎，可以在两次击键之间的时间内对大型程序进行可接受的接近正确的分析。
如果你需要首先做博士学习，那显然。
或者，你可以简单地使用Roslyn，因为这是它的目的 。 这可能需要几个小时的时间，但是你自己并没有得到乐趣。 这很有趣！
您可以在这里下载预览版：
这是微软通常会产生很好结果的领域 – 微软开发者工具真的很棒。 而且，他们的开发工具的销售和Windows的销售有一个明显的商业优势，就是具有最好的智能感，所以微软在他的奇妙的详细答案中提供了Eric所描述的那种资源。 不过，我认为值得指出一些事情：
-
您的客户实际上可能并不需要Microsoft实施提供的所有function。 微软的解决scheme可能是过度devise的， 你需要提供给你的客户/用户的function。 除非实际上实现了一个与Visual Studio竞争的通用编码环境，否则很可能您的预期使用方面会简化问题，或者让您对Microsoft感觉的解决scheme作出妥协他们不能做。 微软可能会花费资源减less已经在数百毫秒内测量的响应时间。 这可能不是你需要做的事情。 微软花费时间为其他人提供一个用于代码分析的API。 这可能不是你的计划的一部分。 优先考虑你的function，并决定你和你的客户看起来像什么“够好”，然后估算实现这个function的成本。
-
除了承担实际需求的明显成本之外，如果您没有在团队中工作，微软也会承担一些可能不明显的成本。 与团队有很大的沟通成本。 实际上，让五个聪明的人花费更长的时间来制作一个解决scheme比一个聪明的人生产同等的解决scheme要容易得多。 微软招聘实践和组织结构的一些方面使得这种情况更有可能。 如果你雇佣了一群有自负的聪明人，然后授权他们所有人做出决定，那么你也可以得到5％更好的解决scheme，花费500％。 对于微软来说，这个5％更好的解决scheme可能是有利可图的，但对于一个小公司来说，这可能是致命的。
-
从1人解决scheme到5人解决scheme增加了成本，但这只是团队内部的开发成本。 微软有单独的团队致力于（粗略）devise，开发和testing，即使是单一function。 跨越这些边界的同伴之间的项目相关沟通比每个学科中的更高的摩擦力。 这不仅增加了个人之间的沟通成本，而且也增加了团队规模。 更重要的是，由于它不是一个由12人组成的团队，而是由5人组成的3人团队，所以上行沟通成本是3倍。 微软select承担的更多成本可能不会转化为其他公司的类似成本。
我的意思不是要把微软描述成一个低效率的公司。 我的观点是，微软对从招聘，到团队组织，到devise和实施的所有事情做出了大量的决定，这些决定从盈利能力和风险的假设开始，并不适用于非微软的公司。
在智力方面，对这个问题有多种思考方式。 微软正在生产一种非常通用的，可重用的解决scheme，它不仅解决了智能感知问题，还针对代码分析的代码导航，重构和各种其他用途。 如果您的唯一目标是让开发人员无需input太多内容便可轻松input代码，则无需以同样的方式进行操作。 针对该function不需要花费多年的努力，如果您不只是提供API，而且实际上也控制了用户界面，那么您可以做的各种各样有创意的事情。
