我还没有遇到过基于用户环境提供的 API 的“知识”提供代码完成建议的 emacs 模式。对于很多人来说,这是一个阻止他们在使用丰富/大型/笨拙(根据需要删除)API 时尝试使用 Emacs 或 VIM 的问题。
但是我想知道这在日常工作中会出现多少问题。我一直在使用带有C# 模式的 Emacs来编写大量 C# 代码。我也倾向于运行 dabbrev-mode 或 pabbrev-mode,它倾向于处理我倾向于使用的更常见的函数和变量名。让我永远感到羞耻的是,我不得不承认我倾向于在 MSDN 网站上打开一个浏览器来查找其余部分——那些我不经常使用的 API,以至于我记不住。您的同事可能想要研究的另一个潜在帮手是冰柱,这也可能是朝着正确方向迈出的一步。然而,这些库都不会提供像 Visual Studio IDE 那样的完整支持。在使用更高效的编辑器时,我会将此视为权衡的一部分。
顺便说一句,如果您的同事在一个团队中工作,并且从事同一项目的其他成员正在使用 Visual Studio,则 MSBuild 可能会提供比 Nant 更好的在 VS 之外构建的解决方案,因为 MSBuild 读取 VS 使用的相同解决方案和项目文件(事实上 VS2008 中的很多构建工作都是由 MSBuild 处理的)。语法与 Nant 相距不远,并且添加了社区任务(这为您提供了 NUnit 集成等),它将确保每个人都使用非常相似的机制来构建可执行文件。