Какие есть альтернативы регулярным выражениям для подсветки синтаксиса?

Question

При редактировании этого и того в Vim я часто обнаруживаю, что его подсветка синтаксиса (для некоторых типов файлов) имеет некоторые недостатки. Я не могу вспомнить ни одного примера в данный момент, но кто-то наверняка будет. Обычно он состоит из строк, плохо выделенных в некоторых случаях, некоторых вещей с арифметическими и логическими операторами, а также нескольких других мелких вещей.

Теперь vim использует регулярные выражения для такого рода вещей (свой собственный вкус).

Однако я начал сталкиваться с редакторами, которые, на первый взгляд, имеют улучшенную подсветку синтаксиса. Я всегда думал, что регулярные выражения - это путь для такого рода вещей.

Так что мне интересно, у этих редакторов лучше написаны регулярные выражения, или они позаботятся об этом каким-то другим способом? Какие ? Как осуществляется подсветка синтаксиса, когда вы хотите, чтобы он был «стабильным»? И, на ваш взгляд, какой редактор позаботился о нем лучше всего (на ваш выбор) и как он это сделал (по языку)?

Edit-1: Например, редакторы, такие как Emacs, Notepad2, Notepad ++, Visual Studio - знаете ли вы, какой механизм они используют для синхронизации. высоко.

Answer 1

Мысль о том, что вы хотите использовать вместо регулярных выражений для подсветки синтаксиса, сразу приходит в голову: парсинг . У регулярных выражений есть много преимуществ, но, как мы видим из выделения vim, существуют ограничения. (Если вы ищете темы об использовании регулярных выражений для анализа XML, вы найдете обширный материал о том, почему регулярные выражения не могут делать то, что делают анализаторы.)

Поскольку мы хотим, чтобы подсветка синтаксиса соответствовала синтаксической структуре языка, которую регулярные выражения могут только приблизить, вам необходимо выполнить некоторый уровень реального синтаксического анализа, чтобы выйти за пределы возможностей регулярных выражений. Я думаю, что простой лексер рекурсивного спуска отлично подойдет для большинства языков.

Answer 2

Некоторые языки программирования имеют формальное определение / спецификацию, написанную в Форма Бэкуса-Наура . Все ^*) языки программирования могут быть описаны в нем. Все, что вам тогда нужно, это какой-то синтаксический анализатор для обозначения.

^{*) не проверено}

Например, определение BNF C - это «всего пять страниц».

Answer 3

Если вам нужна точная подсветка, вам нужно настоящее программирование, а не регулярные выражения. RegExs редко являются ответом на что-либо, кроме тривиальных задач. Чтобы сделать выделение лучше, вам нужно написать простой парсер. Анализ обычно состоит из отдельных компонентов, каждый из которых может что-то делать, например, идентифицировать и использовать строку или числовой литерал в кавычках. Если указанный компонент при взгляде на данный курсор не может использовать то, что находится под ним, он ничего не делает. Отсюда вы можете легко и просто разобрать или выделить.

Учитывая что-то вроде

статическое поле int = 123;

• Первый macher пропустил бы пробел перед "static". Соответствие ключевого слова, литерала и т. Д. Ничего не сделает, потому что обработка пробелов - это не их дело.

• Ключевое слово, совпадающее при нахождении над «статическим», будет использовать это. Поскольку «s» не является цифрой, буквальное совпадение ничего не делает. Шкипер пробелов ничего не делает, потому что «s» не является пробелом.

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

Этот подход является гибким в том смысле, что он обрабатывает синтаксически некорректные фрагменты, а также легко расширяет и повторно использует отдельные средства сопоставления для поддержки выделения других языков ...

Answer 4

Я предлагаю использовать RE для подсветки синтаксиса. Если он не работает должным образом, то ваш RE не достаточно мощный или достаточно сложный :-) Это одна из тех областей, где сияют RE.

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

У меня никогда не было проблем с Vim с основными языками, и у меня никогда не было необходимости использовать странные эзотерические языки, так что это отлично подходит для моих целей.