Подсветка синтаксиса - самый эффективный и профессиональный способ

Question

Вопрос:
Я хочу код для: подсветки синтаксиса (языков программирования)
Язык: C # или сборка x86 (желательно C #)
Платформа: Windows
Квалификация: возможна наиболее эффективная реализация / наиболее профессионально / как крупные корпорации, такие как Microsoft, делают это
Перефразировано: как реализовать подсветку синтаксиса в C # для Windows наиболее эффективным способом, известным в настоящее время?


Разработка (не стесняйтесь - не нужно отвечать на вопрос:)):
Я не хочу просто какого-либо способа его реализации - я уже видел несколько.
Я хотел бы знать, как Microsoft делает это так хорошо в Visual Studio (в зависимости от версии).

Люди продолжают изобретать велосипед, когда дело доходит до подсветки синтаксиса. Я не понимаю почему.
Считается ли это очень сложной проблемой? Я видел реализации, которые только выделяют то, что в данный момент отображается на экране, я думаю, что это путь ... (он использовал какой-то умный API, чтобы узнать, какие строки текстового поля действительно отображались).
Я также видел реализации, использующие RichTextBox, и я думаю, что это , а не . может быть, лучше (может быть, я где-то видел - сомневаюсь, что сам подумаю)
Кроме того, я слышал, что некоторые люди реализуют его с помощью AST точно так же, как был бы закодирован компилятор (я думаю, это лексер) - я надеюсь, что это излишне - я не считаю это эффективным (необразованное предположение)

Если это действительно сложная проблема, то как большой корпус всегда делает это правильно? Например, я никогда не слышал о способе нарушения подсветки синтаксиса в Visual Studio.
Но любой другой инструмент, который реализует это, делает это плохо или хуже, чем большие парни.
Какой официальный «это лучший способ, а другой - менее эффективный»?

У меня действительно нет никаких доказательств того, что путь Microsoft лучше, но, видя, что они, вероятно, знают о Windows API больше, чем кто-либо другой, я предполагаю, что есть лучший способ его реализации (я бы хотел ошибиться - представьте себе, я могу сказать, что моя реализация подсветки синтаксиса лучше, чем у MS!)

Извините за несвязную разработку.
Также заранее прошу прощения за любые фальшивки - это мой первый вопрос.

Answer 1

Я не думаю, что есть "это лучший способ, а любой другой способ менее эффективен" способ сделать это. На самом деле я не думаю, что эффективность является основной проблемой. Скорее сложность есть. Хорошая подсветка синтаксиса основана на хорошем парсере. Пока вы можете анализировать код, вы можете выделить любую его часть так, как вам нравится. Но что происходит тогда, когда код плохо сформирован? Многие средства подсветки синтаксиса просто выделяют ключевые слова и несколько блочных структур, чтобы решить эту проблему. Делая это, они могут использовать простые регулярные выражения вместо полноценного синтаксического, устойчивого к ошибкам синтаксического анализатора (что есть в Visual Studio).

Answer 2

Лучшим способом, вероятно, является повторное использование чего-либо существующего, например ScintillaNET .

Answer 3

Как и в любом другом коде .... редко существует "лучший" способ. Есть несколько способов сделать что-то, и у каждого из них есть свои преимущества и недостатки.

Тем не менее, некоторая форма шаблона интерпретатора , вероятно, является наиболее распространенным способом. Согласно Книга GoF :

Шаблон интерпретатора широко используется в компиляторах, реализованных с объектно-ориентированные языки, как Компиляторы Smalltalk есть. SPECTalk использует шаблон для интерпретации описания форматов входных файлов. Инструментарий для решения ограничений QOCA использует его для оценки ограничений.

В разделе о применимости также говорится об ограничениях

• Грамматик прост. Для сложных грамматик иерархия классов для грамматик становится большим и неуправляемым. Такие инструменты, как генераторы парсера лучшая альтернатива в таких случаях
• эффективность не является критической проблемой. Самый эффективный переводчики обычно не реализуется путем интерпретации разбора деревья непосредственно, но сначала переводя их в другую форму. Например, регулярные выражения часто превращается в конечные автоматы. Но даже тогда переводчик может быть осуществляется переводчиком шаблон, поэтому шаблон по-прежнему применимо.

Понимая это, теперь вы должны знать, почему лучше предварительно скомпилировать ваш многократно используемый RegEx, прежде чем выполнять с ним много совпадений. Если вы этого не сделаете, ему придется каждый раз выполнять оба этапа (преобразование, интерпретации), а не создавать конечный автомат один раз и применять его несколько раз.

Специально для типа интерпретации, который вы описываете, Microsoft предоставляет пространство имен Microsoft.VisualStudio и все его мощные функции в составе Visual Studio SDK . Вы также можете посмотреть System.CodeDOM для динамической генерации и компиляции кода.