¿Por qué Vim en Windows usa \ n para buscar?

Question

Así que estaba cambiando código de

foo() 
{ 

a

foo() { 

y me di cuenta de que el patrón de búsqueda me obligó a buscar \n, pero cuando traté de reemplazarlo con \n me dieron el ^@ personaje, y tuve que reemplazarlo por \r.

Me parece extraño buscar con \n y reemplazar con \r, ¿alguna idea de por qué esto podría ser?

Como referencia mi solución fue :%s/\n\s*{/ {\r/g

Answer 1

la sintaxis de la parte de búsqueda y la pieza de repuesto son arbitrariamente diferente. Algunos de los mismos códigos se vuelven a usar para significar cosas diferentes. Sí, es confuso.

| 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 

Durante la búsqueda, dependiendo de la plataforma, la 0xD puede estar oculto parte, considerado de "salto de línea", así que sí ... siempre se puede devolver la cordura a sus archivos y obligar a todos los retornos de carro mostrados por abrir un archivo y hacer:

:e ++ff=unix 

De forma similar, cuando se reemplaza, "romper la línea aquí" hace cosas diferentes dependiendo de su plataforma. Se podría insertar 0xA o 0xD 0xA etc.

En caso de que esto no es todo ya bastante malo:

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 CTRL-@ 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. 

A no ser que se trata de literales o 0x00xD caracteres, es claramente la perfecta regla general a pegarse siempre con \n para la búsqueda y \r para el reemplazo, como probablemente haya averiguado.

Consulte también:

:h /\n 
:h /\r 
:h s/\n 
:h s/\r 
:h s/\<CR> 

Answer 2

Creo que su problema es debido al hecho de que los sistemas operativos tipo Unix como Linux utilizan la nueva línea (también conocido como "salto de línea") (0x0A) como el fin de línea, pero Windows usa carriage return + newline (0x0D 0x0A). vim está tratando de hacer algún tipo de mapeo para hacer que el final de línea de dos bytes de Windows se vea como un solo "final de línea".

En una nota relacionada, el siguiente comando parece convertir un archivo de estilo de Unix a Windows uno en una máquina Windows, y convertir un archivo de estilo de Windows para Unix uno en una máquina Unix:

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

donde ^V medios de mantenimiento de la tecla de control y pulse el V, y de manera similar ^M significa mantener pulsada la tecla de control y pulse M.