ถ้าฉันมีข้อความต่อไปนี้:
foo
bar
ฉันเลือกและคัดลอก
ตอนนี้ข้อความถูกเก็บไว้ในการลงทะเบียนที่ไม่มีชื่อ"
และนี่คือเนื้อหา (ผลลัพธ์ของ:reg "
):
"" foo^Jbar^J
ตามแผนภูมินี้ดูเหมือนว่า^J
เครื่องหมายรูปหมวกสำหรับตัวดึงข้อมูลบรรทัด
หากฉันต้องการทำซ้ำทะเบียนที่ไม่มีชื่อในการa
ลงทะเบียนโดยพิมพ์: :let @a = @"
นี่คือเนื้อหา (output of :reg a
):
"a foo^Jbar^J
มันไม่เปลี่ยนแปลง
ถ้าตอนนี้ฉันทำซ้ำในทะเบียนการค้นหาโดยพิมพ์:let @/ = @"
นี่คือเนื้อหา (ผลลัพธ์ของ:reg /
):
"/ foo^@bar^@
ตามแผนภูมิก่อนหน้านี้ดูเหมือนว่า^@
เป็นเครื่องหมายรูปหมวกสำหรับอักขระ Null
เหตุใด Line Feed จึงถูกแปลงเป็นอักขระ Null ภายในรีจิสเตอร์การค้นหาโดยอัตโนมัติ (แต่ไม่ใช่a
รีจิสเตอร์)
ถ้าฉันแทรกการลงทะเบียนที่ไม่มีชื่อในบรรทัดคำสั่ง (หรือในการค้นหาหลังจาก/
) โดยพิมพ์:<C-R>"
นี่คือสิ่งที่ถูกแทรก:
:foo^Mbar^M
อีกครั้งตามแผนภูมิล่าสุด^M
ดูเหมือนจะเป็นเครื่องหมายรูปหมวกสำหรับ Carriage Return
เหตุใด Line Feed จึงถูกแปลงเป็น Carriage Return บนบรรทัดคำสั่งโดยอัตโนมัติ
แก้ไข :
โดยปกติคุณสามารถแทรกอักขระควบคุมตามตัวอักษรโดยพิมพ์:
<C-V><C-{character in caret notation}>
ตัวอย่างเช่นคุณสามารถแทรกตัวอักษรโดยการพิมพ์<C-R>
คุณสามารถทำได้เพื่อให้ดูเหมือนตัวควบคุมใด ๆ
แต่ฉันพบว่าฉันไม่สามารถแทรกตัวอักษร LF ภายในบัฟเฟอร์หรือในบรรทัดคำสั่งเพราะถ้าฉันพิมพ์: มันแทรกอักขระ null แทน
เป็นเพราะเหตุผลเดียวกันที่ LF ถูกแปลงเป็น NUL ภายในทะเบียนการค้นหาหรือไม่<C-V><C-R>
<C-V><C-J>
^@
^J
แก้ไข 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 สามารถสร้างความแตกต่างระหว่าง 2 ได้อย่างไร?
แก้ไข 3 :
บางทีรหัส LF และ NUL อาจมีรหัสทศนิยมเหมือนกัน10
ตามความช่วยเหลือ และเสียงเรียกเข้าทำให้ความแตกต่างระหว่าง 2 ต้องขอบคุณบริบท ถ้ามันตรงกับตัวละครที่มีรหัสทศนิยมอยู่10
ในบัฟเฟอร์หรือการลงทะเบียนใด ๆ ยกเว้นการค้นหาและคำสั่งการลงทะเบียนก็ตีความว่ามันเป็น LF
แต่ใน search register ( :reg /
) มันตีความว่าเป็น NUL เพราะในบริบทของการค้นหา Vim จะค้นหาเฉพาะสตริงที่แนวคิดของend of line in a file
ไม่สมเหตุสมผลเนื่องจากสตริงไม่ใช่ไฟล์ (ซึ่งแปลกเพราะคุณสามารถ ยังคงใช้อะตอม\n
ในรูปแบบการค้นหา แต่อาจเป็นเพียงคุณลักษณะของโปรแกรม regex หรือไม่) ดังนั้นจึงตีความโดยอัตโนมัติ10
ว่าเป็น NUL เพราะเป็นแนวคิดที่ใกล้ที่สุด ( end of string
≈ end of line
)
และในทำนองเดียวกันบนบรรทัดคำสั่ง / การลงทะเบียนคำสั่ง ( :reg :
) มันตีความรหัส10
เป็น CR เพราะแนวคิดของend of line in a file
ไม่เหมาะสมที่นี่ แนวคิดที่ใกล้ที่สุดคือend of command
เพื่อให้ตีความเป็นกลุ่ม10
เป็น CR เพราะชนEnter
เป็นวิธีที่จะสิ้นสุด / รันคำสั่งและ CR เป็นเช่นเดียวกับการกดปุ่มEnter
ตั้งแต่เมื่อคุณใส่หนึ่งตัวอักษรด้วย<C-V><Enter>
, ^M
จะปรากฏ
บางทีการตีความของตัวละครที่มีรหัสคือ10
การเปลี่ยนแปลงตามบริบท:
- จุดสิ้นสุดของบรรทัดในบัฟเฟอร์ (
^J
) - จุดสิ้นสุดของสตริงในการค้นหา (
^@
) - สิ้นสุดคำสั่งบนบรรทัดคำสั่ง (
^M
)
someFunction(arg1, "")
ที่ arg 2 คือ""
ie "รายการระหว่างเครื่องหมายคำพูดซึ่งไม่มีอะไรแท้จริง -" ว่าง "NULL สามารถปรากฏขึ้นได้เพราะมันเป็น" เพิ่ม "โดยการใช้งาน C พื้นฐานตามที่มันคั่นสตริงฉันไม่ทราบ คุณจะตรวจสอบสิ่งนี้ได้อย่างไร - แต่มันเป็นสาเหตุที่เป็นไปได้ในใจ
\r
และ\n
:substitute
ความแตกต่างใน
NULL
ตัวละครที่ไม่คาดคิดเกิดจากฟังก์ชั่น C พื้นฐานที่จัดการกับสตริง นี้คำอธิบายวิธี C กระบวนการสตริงที่คุณเชื่อมโยงกับอธิบายว่าภายใน C delimitsNULL
สตริงกับNULL
เกิดขึ้นน้อยมากในข้อความที่ทำให้ตัวละครดีสำหรับวัตถุประสงค์นี้ ผลที่ตามมาก็คือหากโปรแกรม C (vim) พยายามส่งสตริง "ว่าง" ลงในฟังก์ชัน C ภายใน