Является ли это изменение в файле окраски синтаксиса Vim хорошим или разрушительным? - PullRequest
Новая
       112

Является ли это изменение в файле окраски синтаксиса Vim хорошим или разрушительным?

0 голосов
/ 13 апреля 2020

Резюме

  • Я не спрашиваю ваше мнение о том, что предлагаемое изменение - хорошее, плохое, удивительное или что-то в этом роде.
  • Я просто прошу вашей помощи, чтобы ответить на этот вопрос: выполняет ли изменение, предложенное мной, для окраски синтаксиса комментариев break окраску синтаксиса для чего-то другого (ключевые слова, строки , синтаксические ошибки, ...)?
  • Вышеуказанный вопрос не основан на мнении, так как мое изменение либо нарушает, либо нет. Вот и все.

Исходный вопрос

Я создал выпуск # 5876 на странице Vim's GitHub, чтобы предложить изменить vim/runtime/syntax/sed.vim, но он не получил большое внимание, поэтому я рассматриваю возможность создания PR для изменения.

На самом деле, я создал проблему вместо PR, потому что я не совсем уверен, что изменение не разрушительно, отсюда и этот вопрос.

Проблема связана со строкой 20: 

syn match sedComment    "^\s*#.*$"

, из-за которой только «полные» комментарии окрашиваются как комментарии. Использование конечных комментариев, следующих за командой (например, разрешенной GNU sed), стимулирует некоторую раскраску красного фона (так как логика окраски синтаксиса считается ошибкой c, я думаю).

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

В этом отношении я заметил, что изменение этой строки на 

syn match sedComment    "\s*#.*$"

т.е. просто снятие якоря ^, кажется достаточно. Я также попытался протестировать его, поместив # в строку поиска и замены в сценарии sed, и это выглядит нормально.

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

Чтобы продемонстрировать, почему я не уверен в этом, возьмите этот однострочный sed скрипт 

s/aaa/bbb/#ccc

здесь # не окрашен как комментарий, а фон ccc красный (как ошибка?), Тогда как, просто добавив пробел, дайте правильную окраску: 

s/aaa/bbb/ #ccc

Поэтому я думаю, что мое редактирование работает (или, кажется, работает) из-за правил приоритета между несколькими директивами окраски синтаксиса (в отношении этого конкретного примера c с s/aaa/bbb/#ccc, я думаю, что # сразу после закрывающего разделителя команда s имеет значение в языке, но я не знаю, страница GNU Sed man ничего об этом не говорит).

Edit

Другой пример предложил в комментариях я Следующее, синтаксис окраски которого не нарушен предлагаемым изменением 

s/#if !defined(\([^)]*)/#ifndef \1/ # with or without this comment is fine

1 Ответ

0 голосов
/ 18 апреля 2020

Мои исследования

В конце концов я нашел время для изучения :h E410, и теперь у меня есть ответ.

Оттуда я прочитал, что 

Vim understands three types of syntax items:

1. Keyword
     [...] It will only match with a complete word [...]

2. Match
     This is a match with a single regexp pattern.

3. Region
     This starts at a match of the "start" regexp pattern and ends with a match with the
     "end" regexp pattern.  Any other text can appear in between.  A "skip" regexp
     pattern can be used to avoid matching the "end" pattern.

Поскольку строка, которую я собираюсь изменить, использует синтаксис 2.,

  • точка 1. не имеет значения,
  • точка 3. - это релевантно, так как в общем случае совпадение между тем, что syn match и syn region может совпадать.

(Кстати, я проверил, что syn region использует ленивое регулярное выражение, вероятно, \_.\{-} затем рассмотрим несколько примеров, чтобы найти соответствие между шаблонами регулярных выражений start и end.)

Затем из :h :syn-priority

3. An item that starts in an earlier position has priority over items that
   start in later positions.

Ответ

Следовательно, изменение 

syn match sedComment    "^\s*#.*$"

на 

syn match sedComment    "\s*#.*$"

не должно приводить к какой-либо синтаксической ошибке, причина в том, что если текст, соответствующий приведенному выше регулярному выражению, на самом деле это не комментарий (как, например, для команды s/#/hash/), тогда ему должен предшествовать некоторый синтаксис без комментариев, который будет соответствовать другим * 10 46 * / syn region групп. Поскольку это совпадение начинается раньше, когда группа sedComment начинает совпадать, первое имеет преимущество перед последним.

В заключение, если что-то уже не нарушено с sed.vim, предлагаемое изменение не приведет к неправильная окраска синтаксиса.

Дальнейшие наблюдения

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

Например, в следующей строке, что недопустимо, поскольку a не является допустимым флагом, a не получает Error окраска. 

s/x/y/a

Мое предлагаемое редактирование не решает эту ошибку.

По той же причине, поскольку некоторые другие правила синтаксиса потребляют 1 символ после третьего разделителя в команде подстановки, GNU- sed -правильный комментарий в следующей команде неправильно окрашен 

s/x/y/#hello
#     │└───┴─── colored as Error
#     └─ not colored

Раскраска будет неправильной даже для старой версии sed, которая не допускает трейлинг ком ments, так как окраска Error должна включать в себя #. Мое предлагаемое редактирование также не решает эту ошибку.

...