Если у меня есть следующий текст:
foo
bar
Я визуально выбираю и копирую.
Текст теперь хранится в безымянном регистре, "и вот его содержимое (вывод :reg "):
"" foo^Jbar^J
В соответствии с этим графиком , кажется, что ^Jэто обозначение каретки для перевода строки.
Если я хочу дублировать безымянный регистр в aрегистре, набрав: :let @a = @"
Вот его содержимое (вывод :reg a):
"a foo^Jbar^J
Это не изменилось.
Если я теперь продублирую его в регистре поиска, набрав :let @/ = @", вот его содержимое (вывод :reg /):
"/ foo^@bar^@
Согласно предыдущему графику, это похоже ^@на символ каретки для нулевого символа.
Почему перевод строки автоматически преобразуется в нулевой символ в регистре поиска (но не в aрегистре)?
Если я вставляю безымянный регистр в командной строке (или в поиске после /), набрав :<C-R>", вот что вставлено:
:foo^Mbar^M
Опять же, в соответствии с последним графиком, ^Mпохоже, каретная нотация для возврата каретки.
Почему перевод строки автоматически преобразуется в возврат каретки в командной строке?
Редактировать :
Обычно вы можете вставить буквенный управляющий символ, набрав:
<C-V><C-{character in caret notation}>
Например, вы можете вставить в буквальном смысле <C-R>, набрав <C-V><C-R>.
Вы можете сделать это для, казалось бы, любого управляющего персонажа.
Однако я заметил, что я не могу вставить буквальный LF внутри буфера или в командной строке, потому что, если я наберу: <C-V><C-J>он вставляет ^@нулевой символ вместо ^J.
По той же причине LF преобразуется в NUL внутри регистра поиска?
Изменить 2 :
В :h key-notation, мы можем прочитать это:
<Nul> zero CTRL-@ 0 (stored as 10) <Nul>
<NL> linefeed CTRL-J 10 (used for <Nul>)
stored as 10Часть на первой линии и used for <Nul>на второй линии может свидетельствовать о том , что есть какая - то перекрытия между LF и NUL, и что они могут быть интерпретированы как то же самое. Но они не могут быть одинаковыми, потому что после выполнения предыдущей команды :let @/ = @", если я набираю текст nв обычном режиме, чтобы перейти к следующему вхождению из 2 строк, fooи barвместо получения положительного совпадения у меня появляется следующее сообщение об ошибке:
E486: Pattern not found: foo^@bar^@
Кроме того, эта ссылка, кажется, объясняет, что NUL обозначает конец строки, тогда как LF обозначает конец строки в текстовом файле.
И если NUL, stored as 10как говорится в справке, это тот же код, что и для LF, как Vim может сделать разницу между двумя?
Изменить 3 :
Возможно, LF и NUL кодируются с одним и тем же десятичным кодом 10, как говорится в справке. И Vim делает разницу между двумя благодаря контексту. Если он встречает символ, десятичный код которого находится 10в буфере или любом регистре, кроме регистров поиска и команд, он интерпретирует его как LF.
Но в search register ( :reg /) он интерпретирует его как NUL, потому что в контексте поиска Vim ищет только строку, в которой концепция end of line in a fileне имеет смысла, потому что строка не является файлом (что странно, поскольку вы можете по-прежнему использовать атом \nв искомом шаблоне, но, возможно, это только особенность движка регулярных выражений?). Таким образом, он автоматически интерпретируется 10как NUL, потому что это ближайшая концепция ( end of string≈ end of line).
И точно так же в командной строке / command register ( :reg :) он интерпретирует код 10как CR, потому что концепция end of line in a fileздесь не имеет смысла. Ближайшая концепция end of commandтак Vim толкует 10как CR, так как ударять Enterпуть до конца / выполнить команду и CR такой же , как удары Enter, так как при вставке буквального с <C-V><Enter>, ^Mотображаются.
Может быть, интерпретация символа, чей код 10меняется в зависимости от контекста:
- конец строки в буфере (
^J) - конец строки в поиске (
^@) - конец команды в командной строке (
^M)
someFunction(arg1, "")где arg 2 было, "" т. е. «элемент между кавычками, который буквально ничто -« пустой ». Может быть NULL, потому что он был« добавлен »базовой реализацией C, поскольку он ограничил строку. Я не знаю как бы вы проверили это - но это приходит на ум в качестве возможной причины
\rи \nразницу в:substitute .
NULLсимволов вызвано базовой функцией C, которая обрабатывает строки. Это объяснение того, как C обрабатывает строки, с которыми вы связались, объясняет, что внутренне C разделяет строки с помощьюNULL.NULLв тексте встречаются достаточно редко, что делает его хорошим персонажем для этой цели. Следствием этого является то, что если программа C (vim) пыталась передать «пустую» строку во внутреннюю функцию C