У меня утро!

Попробуйте сформулировать, что делает ваша фича или подсистема. Сделайте это письменно, на хорошем русском языке и Вы, возможно, увидите некоторые проблемы в архитектуре. Возможно, Вы увидите и некоторые достоинства Вашей реализации! Но то, что Вы увидите что-то, о чем раньше не думали - это факт.

Не спрашивайте меня ничего, я пишу!

Я сказал сегодня, что не могу вспомнить, чем именно примечателен некий персонаж из пьесы, которую мы читали на английском на прошлой неделе. Отчасти это была правда, отчасти я надеялся на сочувствие, говоря, что у меня в голову загружен code completion и потребуется некоторое время чтобы освободить немного ресурсов для других задач. Но сочувствия я не нашел. Оказалось, что по мнению Н., мой мозг не обладает должной эластичностью и это качество мне необходимо развивать. Черт возьми, я этого совсем не ожидал! Действительно ли, погружаясь с головой в решение некоторой проблемы, какой бы сложной она не казалась, мы убиваем способность мыслить шире? Возможно ли, без потери эффективности, научиться мгновенно переключаться между разными задачами? 

Я не знаю ответ, но code completion дописал. Осталось сделать так, чтобы он заработал. Или взглянем шире... нужен ли нам code completion?      

двигаю гору code completion

На этой неделе, уходя домой, я каждый день прикреплял к стенке бумажку с количеством некомпилирующихся файлов. В последний раз написал 19. А в течение недели это число временами превышало 100.
Теперь я знаю, как делается code completion, а точнее как он будет делаться, когда все взлетит. Вот некоторые предварительные итоги.
Теперь в решарпере 4 вида code completion: basic, automatic, import и smart.  И здесь у нас первое достижение - ничто не мешает сделать новый пятый вид, если кто-то придумает что он будет делать. Кстати, почему бы не сделать дважды умный или дважды импортирующий code completion? В коде такая гибкость выражается не только открытым множеством значений видов code completion, но и декларативным стилем проверок этих значений.
Автоматический code completion является обособленным видом, так как, в отличие от его родственников, он связан с некоторой сессией, время жизни которой определяется довольно сложно и зависит от печати кода, показаных lookup окошек и асинхронного построителя синтаксического дерева. Опять же, сейчас стало понятно, что управление этой сессией надо выносить в отдельную компоненту.
Теперь немного о дизайне. Программном.
Все просто: есть два набора компонент. Первый набор отвечает за создание контекста. Обычно на каждый язык приходится по одному такому контексту. Сложность контекста определяется серьезностью намерений реализовать хороший и быстрый code completion. Сейчас в c# контекст сложный, а в некоторых языках тривиальный. Но это мы исправим.
Имея набор контекстов, мы берем второй набор компонент - правила добавления и изменения списка completion item-ов. Каждое правило состоит из следующих стадий: подготовка, добавление новых элементов, редактирование списка элементов с возможностью удаления существующих и добавлением новых, декорация или изменение атрибутов элементов, определение стиля показа lookup окошка и опций автоматического применения. Все стадии выполняются последовательно для всех правил преобразования.
Некоторый примеры стадий:
1. С подготовкой все понятно.
2. Добавление ключевых слов или live template item-ов.
3. Собственно, замена ключевых слов на омонимичный live template item-ы.
4. Замена методов со скобочками на методы без скобочек в месте, где ожидается делегат.
5. Тоже нечего сказать.
Итого, мы имеем расширяемый по технологиям, изменяемый в пределах одной технологии и, к тому же, быстро работающий code completion. Правильно?