Итак, я менял код из
foo()
{
к
foo() {
и я заметил, что шаблон поиска потребовал от меня поиска \n, но когда я попытался заменить его на \n, я получил символ ^@, и мне пришлось заменить его на \r.
Мне кажется странным, что я ищу с \n и заменяю на \r любую идею, почему это может быть?
Для справки мое решение было :%s/\n\s*{/ {\r/g
Синтаксис для части поиска и замещающей части произвольно различен. Некоторые из тех же кодов повторно используются для обозначения разных вещей. Да, это сбивает с толку.
| How to type | In search, means: | In replacement, means:
----------------------------------------------------------------------------
\n | \n | End-of-line | <Nul> 0x0
^@ | CTRL-V CTRL-J | <Nul> 0x0 | <Nul> 0x0
\r | \r | Carriage return 0xD | "Break the line here"
^M | CTRL-Enter | Carriage return 0xD | "Break the line here"
\^M | \ CTRL-V CTRL-ENTER | \ + carriage return 0xD | Carriage return 0xD
При поиске в зависимости от вашей платформы 0xD может быть скрыта, считается частью "новой строки", поэтому да... вы всегда можете вернуть здравомыслие вашим файлам и принудительно отобразить все возвращаемые каретки, открыв файл и выполнение:
:e ++ff=unix
Аналогично при замене "разбить строку здесь" делает разные вещи в зависимости от вашей платформы. Он может вставлять 0xA или 0xD 0xA и т.д.
Если это еще не все, достаточно плохо:
Technical detail: *NL-used-for-Nul*
<Nul> characters in the file are stored as <NL> in memory. In the display
they are shown as "^@". The translation is done when reading and writing
files. To match a <Nul> with a search pattern you can just enter [email protected] or
"CTRL-V 000". This is probably just what you expect. Internally the
character is replaced with a <NL> in the search pattern. What is unusual is
that typing CTRL-V CTRL-J also inserts a <NL>, thus also searches for a <Nul>
in the file. {Vi cannot handle <Nul> characters in the file at all}
*CR-used-for-NL*
When 'fileformat' is "mac", <NL> characters in the file are stored as <CR>
characters internally. In the text they are shown as "^J". Otherwise this
works similar to the usage of <NL> for a <Nul>.
When working with expression evaluation, a <NL> character in the pattern
matches a <NL> in the string. The use of "\n" (backslash n) to match a <NL>
doesn't work there, it only works to match text in the buffer.
Если вы не имеете дело с буквальными символами 0x0 или 0xD, это правило позволяет всегда придерживаться \n для поиска и \r для замены, как вы, вероятно, выяснили.
См. также:
:h /\n
:h /\r
:h s/\n
:h s/\r
:h s/\<CR>
Я думаю, что ваша проблема связана с тем, что Unix-подобные операционные системы, такие как Linux, используют в качестве маркера конца строки newline (aka "linefeed" ) (0x0A), но Windows использует возврат каретки + новую строку (0x0D 0x0A), vim пытается сделать какое-то сопоставление, чтобы сделать двухбайтовый конец строки Windows похожим на один "конец строки".
В соответствующей заметке следующая команда, похоже, преобразует файл в стиле Unix в Windows один на машине Windows и преобразует файл в стиле Windows в Unix на компьютере Unix:
:%s/^V^M/^V^M/g
где ^V означает удерживать клавишу управления и нажимать кнопку V, а аналогично ^M означает удерживать клавишу управления и нажимать M.