А нельзя обрабатывать не весь текст, а только текущую строку или строки начиная с текущей, пока не «конец выражения» (ну и назад до начала так же)? Емаксовая подсветка по умолчанию так и делает (не перепарсивает файл от начала при редактировании). Правда, «фабричные» фонт-локи скомпилированы, да и пользовательские компилировать можно. А vimscripts, насколько я понимаю, не компилируется в принципе.
Можно, конечно. С выражениями так и делается. Но вот функции придётся самой решать, что обрабатывать, а что - нет.
Кстати, просмотрел всю тему, не увидел из твоих "претензий" ничего, что требовало бы функций. Всё это решается выражениями. Может, ты что-то просто не назвал?
Первая пара скриншотов: раскрасить символы начала и конца комментария одним цветом, а сам комментарий — другим. Тут не функция, а MATCH_ANCHORED скорее всего.
Третья пара скриншотов: раскрасить код макро-функции как функцию, а не как директиву.
Если ты знаешь, как эти варианты решить выражениями (желательно цензурными (: ), будет интересно, на эти выражения посмотреть.
Первая пара скриншотов: раскрасить символы начала и конца комментария одним цветом, а сам комментарий — другим. Тут не функция, а MATCH_ANCHORED скорее всего.
Это уже реализовано в дефолтной схеме синтаксиса C: текст комментария обозначен как cComment, а начало и конец - как cComentStart. Просто ниже cCommentStart переопределяется как синоним cComment, что можно убрать.
syn region cDefine start="^\s*\(%:\|#\)\s*\(define\|undef\)\>" skip="\\$" end="$" keepend contains=ALLBUT,@cPreProcGroup,@Spell
добавить альтернативный конец определения: вместо end="$" - end=")\s\|$
После этого макроопределение будет считаться завершившимся после закрывающей скобки и пробела, и дальнейший код будет подсвечиваться как обычно.
Первая пара скриншотов: раскрасить символы начала и конца комментария одним цветом, а сам комментарий — другим. Тут не функция, а MATCH_ANCHORED скорее всего.
Это уже реализовано в дефолтной схеме синтаксиса C: текст комментария обозначен как cComment, а начало и конец - как cComentStart. Просто ниже cCommentStart переопределяется как синоним cComment, что можно убрать.
Не смотрел как реализовано (честно говоря, не знаю, где смотреть, а искать лень, т.к. пока не особо надо), но как это реализовать _двумя_ выражениями, в общем-то, понятно и так. Не подумал о таком варианте.
syn region cDefine start="^\s*\(%:\|#\)\s*\(define\|undef\)\>" skip="\\$" end="$" keepend contains=ALLBUT,@cPreProcGroup,@Spell
добавить альтернативный конец определения: вместо end="$" - end=")\s\|$
После этого макроопределение будет считаться завершившимся после закрывающей скобки и пробела, и дальнейший код будет подсвечиваться как обычно.
Не годится для простых макросов, раскрывающихся в код. Впрочем, это решится, если решится следующий вопрос: можно ли само слово #define и имя макроса раскрасить в два разных цвета, а значение макроса не раскрашивать вообще (т.е. раскрасить по умолчанию)?
Не годится для простых макросов, раскрывающихся в код. Впрочем, это решится, если решится следующий вопрос: можно ли само слово #define и имя макроса раскрасить в два разных цвета, а значение макроса не раскрашивать вообще (т.е. раскрасить по умолчанию)?
Можно. "#define\s*" в качестве начала блока, "\s\|$" в качестве конца. Раскрашивать содержимое блока и его ограничители можно по-разному.
Вообще, на мой взгляд, функции нужны только тогда, когда хочется, чтобы подсветка _понимала_ язык. Например, подсвечивала одни и теже идентификаторы по-разному в зависимости от вывода ctags. В остальных случаях регекспов вполне достаточно.
Вообще, на мой взгляд, функции нужны только тогда, когда хочется, чтобы подсветка _понимала_ язык. Например, подсвечивала одни и теже идентификаторы по-разному в зависимости от вывода ctags. В остальных случаях регекспов вполне достаточно.
Если регекспы могут матчится на начало блока и конец блока, о чём ты писал чуть выше (а не на блок целиком), то вполне возможно. Это и есть приблизительный аналог MATCH_ANCHORED. А функции уже действительно для более сложных вещей, которые довольно редко бывают нужны.
А т.е. переделывать надо не шаблоны подсветки, а реализацию? Да, это скверно. И странно. Подсветка всё же достаточно важная вещь.
Так разве такое вообще где-то за исключением IDE для отдельных языков есть? В emacs, вроде, бы тоже font-lock по регулярным выражения подсвечивает (знаю только из google, сам не пользовался)? Это я просто размечтался немного.
Но то, что подсветку в vim стоит доработать, это факт. Она еще и имеет у меня тенденцию заглючить при фолдинге. Точно не воспроизведу, но как-то так: иногда (закономерности не улавливаю) в строке открывается комментарий, следующая строка — закрытый блок, внутри которого комментарий заканчивается… и все последующие строки подсвечены как комментарии. Раскрыл/закрыл — все нормализовалось. Хотя, быть может, я его готовить не умею, не знаю.
Это связано с длиной закрытого блока. Исправляется <C-o><C-l> (оно же <C-o>:redraw!<CR>). До того, как я додумался до этого решения, открывал-закрывал первые несколько блоков (особенно прикольно было, когда «первые несколько» — это порядка десятка).
Это связано с длиной закрытого блока. Исправляется <C-o><C-l> (оно же <C-o>:redraw!<CR>). До того, как я додумался до этого решения, открывал-закрывал первые несколько блоков (особенно прикольно было, когда «первые несколько» — это порядка десятка).
Спасибо. Буду использовать. Но в идеале, конечно, хотелось бы чтобы это исправлялось не :redraw!, а Моленаром в исходниках.
