Jeśli mam następujący tekst:
foo
bar
Wybieram go wizualnie i kopiuję.
Tekst jest teraz przechowywany w rejestrze bez nazwy "i oto jego zawartość (wynik :reg "):
"" foo^Jbar^J
Zgodnie z tym wykresem wydaje się, że ^Jjest to notacja karetki dla przesuwania linii.
Jeśli chcę powielić rejestr nienazwany w arejestrze, wpisując: :let @a = @"
Oto jego zawartość (wynik :reg a):
"a foo^Jbar^J
Nie zmieniło się.
Jeśli teraz powielę go w rejestrze wyszukiwania, wpisując :let @/ = @", oto jego zawartość (wynik :reg /):
"/ foo^@bar^@
Zgodnie z poprzednim wykresem wydaje się, że ^@jest to znak karetki dla znaku Null.
Dlaczego wysuw wiersza jest automatycznie konwertowany na znak Null w rejestrze wyszukiwania (ale nie w arejestrze)?
Jeśli wstawię nienazwany rejestr w wierszu polecenia (lub w środku wyszukiwania po /), wpisując :<C-R>", oto co jest wstawiane:
:foo^Mbar^M
Ponownie, zgodnie z ostatnią tabelą, ^Mwydaje się być notacją karetki zwrotu powozu.
Dlaczego wiersz wiersza jest automatycznie przekształcany w wiersz powrotu karetki w wierszu polecenia?
Edytuj :
Zwykle można wstawić dosłowny znak kontrolny, wpisując:
<C-V><C-{character in caret notation}>
Na przykład możesz wstawić literał <C-R>, pisząc <C-V><C-R>.
Możesz to zrobić dla pozornie dowolnej postaci kontrolnej.
Zauważyłem jednak, że nie jestem w stanie wstawić dosłownego pliku LF do bufora lub wiersza poleceń, ponieważ jeśli napiszę: <C-V><C-J>wstawi ^@, zamiast znaku null ^J.
Czy z tego samego powodu LF jest konwertowany na NUL w rejestrze wyszukiwania?
Edycja 2 :
W :h key-notationmożemy przeczytać to:
<Nul> zero CTRL-@ 0 (stored as 10) <Nul>
<NL> linefeed CTRL-J 10 (used for <Nul>)
stored as 10Część na pierwszej linii, a used for <Nul>na drugiej linii może wskazywać, że istnieje jakiś rodzaj zachodzenia między LF i NUL, i że mogą być interpretowane jako samo. Ale nie mogą być tym samym, ponieważ po wykonaniu poprzedniego polecenia :let @/ = @", jeśli piszę nw trybie normalnym, aby przejść do następnego wystąpienia 2 linii fooi barzamiast uzyskania pozytywnego dopasowania, pojawia się następujący komunikat o błędzie:
E486: Pattern not found: foo^@bar^@
Poza tym ten link wydaje się wyjaśniać, że NUL oznacza koniec łańcucha, podczas gdy LF oznacza koniec linii w pliku tekstowym.
A jeśli NUL jest, stored as 10jak mówi pomoc, czyli taki sam kod jak dla LF, w jaki sposób Vim może rozróżnić 2?
Edycja 3 :
Być może LF i NUL są kodowane tym samym kodem dziesiętnym 10, jak mówi pomoc. A Vim robi różnicę między tymi 2 dzięki kontekstowi. Jeśli napotka znak, którego kod dziesiętny znajduje się 10w buforze lub dowolnym rejestrze, z wyjątkiem rejestrów wyszukiwania i poleceń, interpretuje go jako LF.
Ale w rejestrze wyszukiwania ( :reg /) interpretuje to jako NUL, ponieważ w kontekście wyszukiwania Vim szuka tylko ciągu znaków, w którym koncepcja end of line in a filenie ma sensu, ponieważ ciąg nie jest plikiem (co jest dziwne, ponieważ można nadal używasz atomu \nw szukanym wzorze, ale może to tylko funkcja silnika wyrażeń regularnych?). Więc automatycznie interpretuje 10jako NUL, ponieważ jest to najbliższa koncepcja ( end of string≈ end of line).
I w ten sam sposób, w wierszu poleceń / register register ( :reg :) interpretuje kod 10jako CR, ponieważ pojęcie end of line in a filetutaj nie ma sensu. Najbliższa koncepcja jest end of commandtaka, że Vim interpretuje 10jako CR, ponieważ uderzanie Enterjest sposobem na zakończenie / wykonanie polecenia, a CR jest tym samym co uderzanie Enter, ponieważ po wstawieniu dosłownego za pomocą <C-V><Enter>, ^Mwyświetla się.
Może interpretacja znaku, którego kod 10zmienia się zgodnie z kontekstem:
- koniec linii w buforze (
^J) - koniec ciągu w wyszukiwaniu (
^@) - koniec polecenia w wierszu polecenia (
^M)
someFunction(arg1, "")gdzie arg 2 to "" np. „pozycja między cudzysłowami, która jest dosłownie niczym -„ pusta ”. Może pojawić się wartość NULL, ponieważ została„ dodana ”przez podstawową implementację języka C, ponieważ rozgraniczała ciąg. Nie wiem jak byś to sprawdził - ale wydaje się, że to możliwa przyczyna.
\ri \nróżnice w:substitute .
NULLznaków jest spowodowane podstawową funkcją C, która obsługuje ciągi znaków. To objaśnienie, w jaki sposób C przetwarza ciągi, które łączysz, wyjaśnia, że wewnętrznie C rozgranicza ciągi za pomocąNULL.NULLs występują w tekście rzadko, co sprawia, że jest to dobry znak do tego celu. Konsekwencją tego jest to, że jeśli program C (vim) próbował przekazać „pusty” ciąg do wewnętrznej funkcji C