为什么Windows上的Vim使用\ n进行搜索? [英] Why does Vim on windows use \n for searching?
问题描述
所以我要从
更改代码foo()
{
到
foo() {
，我注意到搜索模式要求我搜索\n，但是当我尝试将其替换为\n时，我得到了^@字符，而不得不替换为\r. /p>
对于我来说，用\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 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.
除非您已经处理过0x0或0xD文字字符，否则最好始终坚持使用\n进行搜索，并始终使用\r进行替换，这是一个很好的经验法则.
另请参阅:
:h /\n
:h /\r
:h s/\n
:h s/\r
:h s/\<CR>
So I was changing code from
foo()
{
to
foo() {
and I noticed that the searching pattern required me to search for \n, but when I tried to replace it with \n I got the ^@ character, and I had to instead replace with \r.
It seems strange to me that I search with \n and replace with \r, any idea why this might be?
For reference my solution was :%s/\n\s*{/ {\r/g
The syntax for the search part and replacement part are arbitrarily different. Some of the same codes are re-used to mean different things. Yeah, it's confusing.
| 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
When searching, depending on your platform, the 0xD may be hidden, considered part of "newline", so yeah... you can always return sanity to your files and force all of the carriage returns displayed by opening a file and doing:
:e ++ff=unix
Similarly when replacing, "break the line here" does different things depending on your platform. It might insert 0xA or 0xD 0xA etc.
In case this isn't all already bad enough:
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.
Unless dealing with literal 0x0 or 0xD characters, it's agood a rule of thumb to always stick with \n for search and \r for replacement, as you've probably figured out.
See also:
:h /\n
:h /\r
:h s/\n
:h s/\r
:h s/\<CR>
这篇关于为什么Windows上的Vim使用\ n进行搜索?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
