Почему Vim в Windows использует \ n для поиска?

Поэтому я менял код с

foo()
{

в

foo() {

и я заметил, что шаблон поиска требовал от меня поиска\n, но когда я попытался заменить его на\n Я получил^@ характер, и мне пришлось вместо этого заменить\r.

Мне кажется странным, что я ищу с\n и заменить на\rЛюбая идея, почему это может быть?

Для справки мое решение было:%s/\n\s*{/ {\r/g

 tzenes30 сент. 2010 г., 20:50
@ Пол, я чувствую, что это связанная проблема. Например, он показывает одну вещь, ищет другую и пишет третью.
 Paul Tomblin30 сент. 2010 г., 20:33
Вы думаете это странно? Я использовал для решения проблемы возврата каретки / перевода строки при переходе между Unix и Windows.:%s/^V^M/^V^M/g

Ответы на вопрос(2)

что ваша проблема связана с тем фактом, что Unix-подобные операционные системы, такие как Linux, используют символ новой строки (он же «перевод строки)) (0x0A) в качестве маркера конца строки, но Windows использует возврат каретки + перевод строки (0x0D 0x0A). vim пытается сделать какое-то отображение, чтобы двухбайтовый конец строки в Windows выглядел как один «конец строки».

В соответствующем примечании следующая команда, по-видимому, преобразует файл в стиле Unix в файл Windows на компьютере с Windows и преобразует файл в стиле Windows в файл Unix на компьютере с Unix:

:%s/^V^M/^V^M/g

где^V означает удерживать клавишу управления и нажать клавишу V, и аналогично^M значит, удерживайте клавишу управления и нажмите M.

 tzenes30 сент. 2010 г., 21:46
Я знаком с различиями в новых строках; меня интересует то, почему Vim, кажется, частично маскирует это, и какие правила он использует для этого.
Решение Вопроса

ся. Некоторые из одних и тех же кодов используются для обозначения разных вещей. Да, это сбивает с толку.

    | 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>

Ваш ответ на вопрос