Bram Moolenaar และ Vim: วัฒนธรรมของเครื่องมือแก้ไขที่สร้างนิสัยให้กับนักพัฒนา

ทำไม Vim สำคัญมากกว่าแค่ตัวแก้ไขข้อความ

Bram Moolenaar สร้าง Vim ขึ้นมาเป็นเวอร์ชันที่ปรับปรุงจาก vi แบบคลาสสิก แต่เหตุผลที่ Vim ยืนยงมาหลายทศวรรษไม่ใช่แค่เรื่องเทคนิคเท่านั้น. Vim กลายเป็นวิธีการทำงานร่วมกัน—วิธีการเขียนและเปลี่ยนข้อความที่แพร่กระจายผ่านทีม บทเรียน และโครงการโอเพนซอร์ส หลังจากการจากไปของ Bram บทสักการะหลายชิ้นชี้ประเด็นนี้ตรง ๆ: Vim ไม่ได้เป็นแค่ซอฟต์แวร์ที่คนใช้ แต่มันเป็นสิ่งที่คน เรียนรู้ และนำติดตัวไปสู่การทำงานประจำ.

ว่า "วัฒนธรรมของเครื่องมือแก้ไข" หมายถึงอะไร

เมื่อคนพัฒนาเรียกสิ่งนี้ว่า “วัฒนธรรมของเครื่องมือแก้ไข” พวกเขากำลังพูดถึงมากกว่าแค่รสนิยม มันคือชุดนิสัยและบรรทัดฐานที่ก่อตัวรอบเครื่องมือ:

• ทางลัดที่คนคาดหวังให้คุณรู้
• ข้อปฏิบัติในการตั้งค่า (เช่น การแชร์ vimrc)
• คำศัพท์ในการพูดคุยเรื่องเวิร์กโฟลว์ ("คุณนำทางยังไง?", "คุณรีแฟกเตอร์ข้อความอย่างรวดเร็วอย่างไร?")
• พิธีกรรมการสอน: การดูคนแก้ไขและหยิบเทคนิคไปใช้

วัฒนธรรมนี้สำคัญเพราะมันรูปร่างพฤติกรรม สองคนเปิดไฟล์เดียวกันในตัวแก้ไขเดียวกันแต่เคลื่อนที่ต่างกันมาก — ไม่ใช่เพราะพรสวรรค์ แต่เพราะนิสัยที่ฝึกมา.

สิ่งที่คุณจะได้จากบทความนี้

นี่ไม่ใช่สารานุกรมของคำสั่ง แทนที่จะเป็นการอธิบายรูปแบบเวิร์กโฟลว์ที่ Vim ทำให้เป็นที่นิยม: วิธีที่ผู้คนสร้างขั้นตอนการแก้ไขที่ทำซ้ำได้ ลดแรงเสียดทานเมื่อทำการเปลี่ยนเล็ก ๆ และรักษาทิศทางเมื่อต้องทำงานในไฟล์ขนาดใหญ่.

คุณไม่จำเป็นต้องเป็น “คนนิยม Vim” และไม่ต้องมีพื้นฐานทางเทคนิคเพื่ออ่านตาม เราจะลดศัพท์เทคนิค อธิบายแนวคิดด้วยภาษาธรรมดา และเน้นว่าทำไมนิสัยเหล่านี้จึงสำคัญ—แม้คุณจะใช้ตัวแก้ไขอื่นในปัจจุบันก็ตาม.

เรื่องราวของ Bram Moolenaar และเส้นทางยาวของ Vim

Bram Moolenaar (1961–2023) แยกไม่ออกจากตัวตนของ Vim — ไม่ใช่เพราะ Vim เป็นโครงการคนเดียว แต่เพราะเขาเป็นผู้ดูแลที่มั่นคงซึ่งทำให้เครื่องมือที่ขับเคลื่อนด้วยอาสาสมัครยังคงมีเอกภาพมาหลายสิบปี.

ไทม์ไลน์สั้น ๆ: จากคลอนช์สู่เครื่องมือข้ามแพลตฟอร์ม

รากของ Vim มาจากประเพณีตัวแก้ไข vi. Bram เริ่มโครงการในปลายทศวรรษ 1980 ขณะทำงานบน Commodore Amiga ในตอนแรกเป็นการปรับปรุงตัวแก้ไขที่คล้าย vi. จากนั้น Vim เติบโตอย่างรวดเร็ว: การออกเวอร์ชันในต้นทศวรรษ 1990 ขยายฟีเจอร์และความพกพา และเมื่อ Unix, Windows และต่อมาคือ macOS และ Linux กลายเป็นสภาพแวดล้อมของนักพัฒนา Vim ก็ปรากฏตัวเกือบทุกที่.

การเข้าถึงข้ามแพลตฟอร์มแบบนั้นสำคัญ เครื่องมือที่ทำงานคล้ายกันทั้งบนเครื่องที่บ้าน ห้องปฏิบัติการมหาวิทยาลัย และเซิร์ฟเวอร์ที่ทำงาน ได้รับความไว้วางใจ — และความไว้วางใจนั้นช่วยให้ Vim กลายเป็นตัวเลือกเริ่มต้นที่อยู่ได้นานทั้งกับมืออาชีพและผู้ที่ชื่นชอบ.

Bram ในบทบาทผู้ดูแลและจุดยึดของชุมชน

โครงการโอเพนซอร์สมักล้มเหลวอย่างเงียบ ๆ เมื่อการประสานงานยากกว่าการเขียนโค้ด. ผลงานสำคัญของ Bram คือการดูแลรักษาเป็นงานฝีมือ: ตรวจแพตช์ นำทางการออกเวอร์ชัน รักษาคู่มือและพฤติกรรมให้สอดคล้อง และกำหนดบรรทัดฐานในการร่วมมือ หลายผู้ร่วมพัฒนาได้ปรับปรุง Vim แต่ความรู้สึกที่คุ้นเคยของตัวแก้ไขยังอยู่เพราะมีคนคอยทำให้ทั้งระบบสอดคล้อง.

Charityware แบบไม่มีเงื่อนไข

Vim ยังเป็นที่รู้จักในฐานะ “charityware.” แนวคิดโดยรวมง่าย: หากคุณพบว่า Vim มีประโยชน์ พิจารณาบริจาคเพื่อสนับสนุนการกุศลที่ Bram ส่งเสริม มันไม่ใช่กำแพงจ่ายเงินและไม่จำเป็นต้องใช้ตัวแก้ไข แต่เป็นการกระตุ้นอย่างสุภาพให้คืนกลับ—สัญญาณแรก ๆ ว่าวัฒนธรรมซอฟต์แวร์สามารถมีความเอื้อเฟื้อ ไม่ใช่แค่ประสิทธิภาพ.

เส้นทางยาวของ Vim ในท้ายที่สุดเป็นเรื่องของความต่อเนื่อง: ตัวแก้ไขที่ยังเกี่ยวข้องไม่ใช่เพราะตามเทรนด์ แต่เพราะพัฒนาอย่างระมัดระวัง พร้อมรักษาชุมชนและค่านิยมไว้.

การแก้ไขแบบมีโหมด: แนวคิดหลักที่เปลี่ยนพฤติกรรม

แนวคิดที่โดดเด่นที่สุดของ Vim คือ โหมด : คีย์ชุดเดียวกันทำหน้าที่ต่างกันขึ้นกับสิ่งที่คุณต้องการทำ ฟังดูแปลกจนกว่าคุณจะสังเกตว่า มันสะท้อนสิ่งที่คุณทำอยู่เสมอ—บางครั้งคุณกำลัง คิดเกี่ยวกับการเปลี่ยนแปลง และบางครั้งคุณกำลัง พิมพ์ข้อความใหม่.

สามโหมดที่คนส่วนใหญ่มักเจอก่อน

Normal mode สำหรับการกระทำแก้ไข: การย้าย การลบ การเปลี่ยน การค้นหา คุณไม่ได้ "เขียน" แต่นี่คือการสั่งการ

Insert mode สำหรับพิมพ์อักขระลงในเอกสาร—สิ่งที่ตัวแก้ไขส่วนใหญ่ถือเป็นค่าเริ่มต้น

Visual mode สำหรับการเลือกข้อความเพื่อกระทำ (ย่อหน้า, ลบ, เปลี่ยน, คัดลอก)

ตัวอย่างง่าย ๆ:

• ใน Normal mode กด dd เพื่อลบทั้งบรรทัด
• กด i เพื่อเข้าสู่ Insert mode และพิมพ์เนื้อหาใหม่
• กด Esc เพื่อกลับสู่ Normal mode
• กด v เพื่อเริ่ม Visual mode เลื่อนเพื่อเลือก แล้วกด d เพื่อลบที่เลือก

“การคิด” กับ “การพิมพ์” ช่วยลดแรงเสียดทาน

เมื่อทุกอย่างเป็นการพิมพ์ตลอดเวลา คุณมักจะผสมสองงานเข้าด้วยกัน: ประพันธ์คำกับสั่งการแก้ไข การแก้ไขแบบมีโหมดแยกงานเหล่านี้

ใน Normal mode มือของคุณจะไม่พลาดพิมพ์อักขระโดยไม่ได้ตั้งใจ คุณจะตั้งใจมากขึ้น: ฉันต้องการเปลี่ยนอะไร? ลบอันนี้ เปลี่ยนอันนั้น ย้ายไปตรงนั้น แล้วทำซ้ำ Insert mode กลายเป็นช่วงเวลาที่มุ่งมั่น: ตอนนี้ฉันกำลังเพิ่มข้อความ.

เมื่อเวลาผ่านไป มันอาจรู้สึกเหมือนคุณไม่ได้ต่อสู้กับตัวแก้ไขอีกต่อไป แต่เป็นการให้คำสั่งเล็ก ๆ ที่ชัดเจน.

ความสับสนของผู้เริ่มต้น—และการตีความที่ช่วยได้

จุดเจ็บปวดในช่วงแรกค่อนข้างคาดเดาได้:

• “ทำไมข้อความฉันหายไป?” (คุณอยู่ใน Normal mode และกดคำสั่งอย่าง x หรือ dd)
• “ทำไมมันไม่ยอมให้พิมพ์?” (คุณยังอยู่ใน Normal mode—กด i)
• “ทำไม Esc ถึงสำคัญนัก?” (มันคือการรีเซ็ตที่ชัดเจน: กลับไปเป็นการสั่งการแทนการแทรก)

ตีความโหมดเป็น สถานะของเจตนา. Normal mode ไม่ใช่ "ไม่ได้ทำงาน"—มันคือโหมดที่คุณแก้ไขอย่างมีจุดมุ่งหมาย นั่นคือสิ่งที่การแก้ไขแบบมีโหมดสอน: ทำการเปลี่ยนอย่างตั้งใจก่อน แล้วค่อยพิมพ์.

ความประกอบกัน: คำสั่งเล็ก ๆ ที่รวมเป็นพลัง

“พลังพิเศษ” ของ Vim ไม่ใช่เมนูขนาดยักษ์ แต่นิสัยที่คำสั่งเล็ก ๆ ประกอบกันได้ แทนที่จะจำทางลัดแยกเป็นทุกสถานการณ์ คุณเรียนบล็อกพื้นฐานไม่กี่อย่างแล้วรวมกัน.

กริยา + วัตถุ (อธิบายแบบง่าย)

คิดว่าการแก้ไขเป็น กริยาที่เอาไปใช้กับชิ้นของข้อความ.

• กริยา คือสิ่งที่คุณต้องการทำ: ลบ, เปลี่ยน, คัดลอก.
• วัตถุ คือวิธีชี้ไปที่ข้อความ: คำหนึ่งคำ, จนถึงท้ายบรรทัด, ข้างในอัญประกาศ.

ในศัพท์ของ Vim กริยาเป็น operators (เช่น d สำหรับลบ, c สำหรับเปลี่ยน) และวัตถุเป็น motions/text objects (เช่น w สำหรับคำ, ) สำหรับประโยค, i" สำหรับข้างในอัญประกาศ).

ตัวอย่างในชีวิตประจำวันที่สัมผัสได้ทันที

ไม่กี่การผสมผสานแสดงให้เห็นว่าทำไมวิธีนี้สำคัญ:

• เปลี่ยนคำ: cw — “change” + “word”. คุณไม่ต้องเลือกก่อน; คุณบอกเจตนา
• ลบข้างในอัญประกาศ: di\" — “delete” + “inside quotes”. ยังคงเครื่องหมายอัญประกาศไว้และลบเฉพาะเนื้อหา
• เลือกบล็อก: v แล้วตามด้วยอย่าง i{ — เลือกในโหมด visual + “ข้างในวงเล็บปีกกา” เพื่อคว้าสิ่งที่อยู่ในบล็อก { ... }

ประเด็นไม่ใช่การเก็บกลเม็ด แต่คือสร้างรูปแบบคิดที่คำสั่งทำนายได้.

ความมั่นใจเติบโตเร็วกว่าความเร็ว

ความประกอบกันให้รางวัลกับ ความแม่นยำและความสม่ำเสมอ เมื่อกริยาตัวเดียวใช้ได้กับวัตถุหลายอย่าง คุณจะเดาการแก้ไขน้อยลง ย้อนกลับน้อยลง และรู้สึกสงบเมื่อทำงานในไฟล์ที่ไม่คุ้นเคย ความเร็วจะตามมา—ไม่ใช่เพราะคุณพยายามเร็ว แต่เพราะคุณทำซ้ำวิธีคิดที่เชื่อถือได้เกี่ยวกับข้อความ.

การทำซ้ำ: จุด (dot), มาโคร และการค้นหาเป็นบล็อกของเวิร์กโฟลว์

หนึ่งในแนวคิดที่ใช้ได้จริงที่สุดของ Vim คือการทำให้การแก้ไขไม่ใช่การแสดงที่ทำครั้งเดียว ถ้าคุณอธิบายการแก้ไขได้ครั้งหนึ่ง คุณควรทำซ้ำได้—อย่างสม่ำเสมอ—ข้ามบรรทัดถัดไป ย่อหน้าถัดไป หรือไฟล์ถัดไป นี่คือที่ที่คำว่า “ความเร็ว” กลายเป็นเรื่องของการลดความเหนื่อยใจจากการตัดสินใจ

คำสั่งจุด: ทำซ้ำการเปลี่ยนแปลงล่าสุด

คำสั่งจุด (.) เล่นซ้ำการเปลี่ยนแปลงล่าสุดของคุณ ฟังดูเล็ก แต่กระตุ้นให้คุณทำการแก้ไขเป็นชิ้นที่สะอาดและทำซ้ำได้.

ตัวอย่าง: คุณเปลี่ยน foo เป็น foo() บนบรรทัดหนึ่งโดยการแทรกวงเล็บ ในการพบค่าต่อ ๆ ไป คุณมักจะย้ายเคอร์เซอร์ไปยังจุดที่ถูกต้องแล้วกด . แทนการทำการแทรกซ้ำทั้งหมด นิสัยคือ: ทำการแก้ไขครั้งแรกอย่างรอบคอบ แล้วทำซ้ำมัน.

มาโคร: บันทึก “สูตร” การแก้ไขสั้น ๆ

มาโครให้คุณบันทึกลำดับคีย์และเล่นซ้ำ มันเหมือนบอกว่า: “เมื่อเห็นรูปแบบนี้ ให้ทำขั้นตอนเหล่านี้” การใช้ที่ปลอดภัยและเรียบง่ายคือจัดรูปแบบรายการ:

• เพิ่ม - ที่จุดเริ่มต้นของหลายบรรทัด
• เติมคอมมาที่ท้ายกลุ่มบรรทัด

หลีกเลี่ยงการอัตโนมัติเกินไปเมื่อข้อความไม่สม่ำเสมอ หากแต่ละบรรทัดต้องการการตัดสินใจต่างกัน มาโครอาจสร้างข้อผิดพลาดอย่างรวดเร็วที่จับได้ยาก.

ค้นหาและแทนที่: ขยายความตั้งใจที่ชัดเจน

การค้นหาเป็นเครื่องมือการนำทางอยู่แล้ว; การแทนที่คือการค้นหา + การกระทำ คิดแบบง่าย ๆ: “หาสตริงนี้ แทนด้วยสตริงนั้น” เช่น เปลี่ยนชื่อ temp เป็น draft ในไฟล์ หากการเปลี่ยนอาจกระทบข้อความที่ไม่เกี่ยวข้อง ให้ยืนยันการแทนที่แต่ละครั้งแทนการทำแบบไม่ตรวจสอบ

ข้อสรุปที่ใหญ่กว่า: สร้างสูตรการทำซ้ำสำหรับการแก้ไขที่พบบ่อย เมื่อเวลาผ่านไป เวิร์กโฟลว์ของคุณจะกลายเป็นห้องสมุดของการเคลื่อนไหวเล็ก ๆ ที่เชื่อถือได้ แทนที่จะเป็นการแก้ไขแบบฉุกเฉินซ้ำไปซ้ำมา.

นิสัยแบบคีย์บอร์ดเป็นหลักและการรักษากระแสการทำงาน

สไตล์คีย์บอร์ดเป็นหลักของ Vim ไม่ใช่การทดสอบความบริสุทธิ์ และไม่ได้ทำให้ใครเป็น “นักพัฒนาที่ดีกว่า” จุดมุ่งหมายง่ายกว่า: ทุกครั้งที่คุณเอื้อมไปคว้าเมาส์หรือทัชแพด คุณทำลูปความสนใจเล็ก ๆ — มือออกจากตำแหน่ง เริ่มมองหาตำแหน่งเคอร์เซอร์ และสมองเปลี่ยนบริบทจาก “อะไร” เป็น “ที่ไหน.” การลดการขัดจังหวะเหล่านั้นช่วยให้คุณอยู่กับปัญหาที่กำลังแก้ได้ง่ายขึ้น.

การนำทางเป็นนิสัย ไม่ใช่กลเม็ด

Vim กระตุ้นให้คุณนำทางข้อความตามที่คุณคิด:

• ตามคำและประโยค (w, b, e, )), เมื่อคุณกำลังแต่งข้อความหรือชื่อตัวแปร
• ตามบรรทัดและคอลัมน์ (0, ^, $, gg, G), เมื่อโครงสร้างสำคัญ
• ตามสัญลักษณ์และรูปแบบ (/, ?, n, N), เมื่อคุณกำลังตามหาจุดประสงค์
• ตามไฟล์และตำแหน่ง (buffers, :e, :b, tags/LSP jumps), เมื่อการเปลี่ยนแปลงครอบคลุมโค้ดเบส

เมื่อเวลาผ่านไป “ไปยังสิ่งนั้น” กลายเป็นปฏิกิริยาอัตโนมัติเพราะไม่ต้องตัดสินใจย่อย ๆ ทุกครั้ง.

การปรับแต่งเล็ก ๆ ที่กลายเป็นความจำกล้ามเนื้อ

ประโยชน์จริงไม่ใช่การตัดวินาที แต่คือการเอาความลังเลออก ท่าทางเล็ก ๆ ที่ทำซ้ำได้—เช่น การเปลี่ยน "ข้างในอัญประกาศ" หรือการลบ "จนถึงจุลภาคถัดไป"—กลายเป็นทางลัดทางกายภาพสำหรับการแก้ไขที่พบบ่อย เมื่อรูปแบบเหล่านั้นตกตะกอนเป็นความทรงจำกล้ามเนื้อ คุณจะใช้พลังสมองน้อยลงในการควบคุมตัวแก้ไขและมุ่งที่การเลือกการเปลี่ยนแปลงที่ถูกต้องแทน.

การเข้าถึงและการยศาสตร์: ขึ้นกับแต่ละคน

เวิร์กโฟลว์ที่ขับเคลื่อนด้วยคีย์บอร์ดสามารถลดการเคลื่อนไหวของข้อมือสำหรับบางคน แต่ก็อาจเพิ่มภาระนิ้วสำหรับคนอื่น ผลประโยชน์ทางยศาสตร์เปลี่ยนไปตามบุคคล รูปแบบแป้นพิมพ์ และแม้แต่การเลือกคำสั่ง วัฒนธรรมการปรับแต่งของ Vim มีประโยชน์ตรงนี้: แม็ปปุ่มที่ไม่สะดวก ปรับจังหวะการใช้งาน และให้ความสำคัญกับความสบายเหนือหลักการ เป้าหมายคือการรักษาสมาธิอย่างยั่งยืน ไม่ใช่ความทนทาน.

วัฒนธรรมการตั้งค่า: vimrc, ปลั๊กอิน และค่าเริ่มต้นส่วนตัว

Vim ส่งเสริมความเป็นเจ้าของ แทนที่จะถือว่าตัวแก้ไขเป็นผลิตภัณฑ์ปิด มันมองเป็นโต๊ะเครื่องมือที่คุณปรับแต่งจนเข้ากับวิธีคิดของคุณ

vimrc คืออะไร (และทำไมคนถึงใส่ใจ)

vimrc คือไฟล์การตั้งค่า Vim ที่คุณกำหนดค่าเริ่มต้น: วิธีจัดแท็บ เส้นห่อบรรทัด สิ่งที่แถบสถานะแสดง ฯลฯ ตลอดเวลา นักพัฒนาหลายคนเก็บการตั้งค่าเหล่านี้ในระบบควบคุมเวอร์ชันเป็นส่วนหนึ่งของ “dotfiles” เพื่อให้ตัวแก้ไขคุ้นเคยได้บนเครื่องใดก็ได้

นี่ไม่ใช่แค่การปรับแต่งเพื่อความสวยงามเท่านั้น แต่เป็นบรรทัดฐานทางวัฒนธรรมเพราะค่าพื้นฐานเล็ก ๆ สะสม: จุดเสียดทานน้อยลง ความประหลาดใจน้อยลง และคำถาม "ทำไม Vim ทำแบบนี้?" น้อยลง

วิธีการตั้งค่าที่พอเหมาะ

วิธีที่ง่ายที่สุดจะได้การตั้งค่าที่ไม่เลอะคืออย่าติดตั้งปลั๊กอินสิบตัวก่อนเข้าใจปัญหา วิธีที่ดีกว่า:

• เริ่มจากสิ่งเล็ก ๆ: เปลี่ยนเฉพาะสิ่งที่รบกวนคุณจริง ๆ
• เขียนบันทึก: ใส่คอมเมนต์อธิบายว่าทำไมต้องมีการตั้งค่านั้น
• หลีกเลี่ยงความเยอะ: ถ้าไม่ได้ใช้สัปดาห์ละครั้ง ให้ตั้งคำถาม

ปฏิบัติต่อ vimrc เหมือนบันทึกเวิร์กช็อป ไม่ใช่ลิ้นชักของของไม่จำเป็น.

แผนที่คีย์และปลั๊กอิน อธิบายแบบง่าย

mapping คือทางลัด: กดชุดคีย์แล้ว Vim ทำชุดคำสั่งยาว ๆ ให้ แผนที่ที่ดีลดการทำซ้ำ; แผนที่ที่ไม่ดีทำให้รู้สึกไม่สอดคล้อง

plugin เพิ่มฟีเจอร์: ตัวค้นหาไฟล์, ตัวช่วย Git, การรองรับภาษา การใช้ปลั๊กอินดี แต่ก็เพิ่มความซับซ้อน เวลาเริ่มต้น และพฤติกรรมที่ต้องเรียนรู้

เกณฑ์พื้นฐานของ “Vim แบบมินิมัล”

ก่อนเพิ่มสิ่งเสริม เรียนรู้ค่าพื้นฐานบางอย่างให้ชิน:

• การเยื้องที่สมเหตุสมผล (spaces vs tabs)
• พฤติกรรมการค้นหาที่คุณชอบ (ไฮไลต์ กฎการแยกตัวพิมพ์ใหญ่/เล็ก)
• หมายเลขบรรทัดที่มองเห็นได้ (สัมบูรณ์หรือสัมพัทธ์)
• ธีมสีเรียบง่ายเพื่อการอ่าน

เมื่อฐานนี้เป็นธรรมชาติ ปลั๊กอินจะกลายเป็นการอัปเกรดโดยเจตนา — ไม่ใช่ตัวแทนการเรียนรู้ Vim.

การเรียนรู้และชุมชน: เอกสารช่วยเหลือตัวเอง คำแนะนำ และบรรทัดฐาน

วัฒนธรรมของ Vim ไม่ได้เริ่มจากปลั๊กอินหรือทางลัด แต่มาจากการเรียนรู้ Bram Moolenaar ให้ความสำคัญกับเอกสารเป็นส่วนหนึ่งของผลิตภัณฑ์ และทัศนคตินั้นกำหนดว่าผู้คนสอน Vim อย่างไร: ไม่ใช่ชุดความลับ แต่เป็นทักษะที่ขยายได้ทีละขั้น

ระบบช่วยเหลือเป็นการเรียนรู้แบบบริการตนเอง

:help ของ Vim ไม่ใช่ของรองรับ; มันคือแผนที่ มันให้รางวัลกับความอยากรู้อยากเห็นด้วยโครงสร้าง—หัวข้อ การอ้างอิงข้าม และตัวอย่างที่สมมติว่าคุณจะสำรวจ

นิสัยเล็ก ๆ เปลี่ยนจาก “ฉันติดปัญหา” เป็น “ฉันหาคำตอบได้”:

• :help {topic} (หรือ :h) เพื่อกระโดดไปยังแนวคิด เช่น :h motion หรือ :h visual-mode
• CTRL-] เพื่อตามลิงก์ใน help และ CTRL-T เพื่อย้อนกลับ
• :helpgrep {word} เพื่อค้นหาในเอกสารเมื่อคุณไม่รู้คำศัพท์ที่ถูกต้อง

แบบจำลองนี้ขยายได้: เมื่อตอนคุณเรียนรู้จะถามตัวแก้ไข คุณก็จะพึ่งพาการจำคำสั่งน้อยลง.

คำแนะนำและบรรทัดฐานการให้คำปรึกษา

การให้คำปรึกษาใน Vim มักเป็นการแทรกแซงเล็ก ๆ ที่เคารพ: แม็ปหนึ่งปุ่ม หนึ่งการเคลื่อนไหว หนึ่งการปรับเวิร์กโฟลว์ กฎที่ไม่เขียนคือ “เจอผู้คนที่จุดที่เขาอยู่” มักจะแชร์ทิปและพูดชัดว่า "ถ้าเครื่องมือของคุณใช้งานได้แล้ว ก็ไม่เป็นไร"

บรรทัดฐานอื่น ๆ ที่ใช้งานได้จริง:

• แชร์คำแนะนำที่ทำซ้ำได้ (รวมคำสั่งหรือการตั้งค่าน้อยที่สุด)
• เคารพการตั้งค่าที่แตกต่างกัน (เทอร์มินัล vs GUI, Vim มินิมัล vs Neovim หนัก ๆ)
• สอนแนวคิด ไม่ใช่การทดสอบความบริสุทธิ์

วิธีที่ข้อปฏิบัติแพร่กระจาย

ความรู้ Vim เดินทางผ่านสิ่งของน้ำหนักเบา: cheat sheets, พูดสั้น ๆ, เทมเพลต dotfile, และ repo "starter" ขนาดเล็ก ที่ดีที่สุดอธิบาย ทำไม นิสัยถึงช่วย ไม่ใช่แค่ พิมพ์อะไร.

ไม่ใช่ทุกคนต้องการความลึกเท่ากัน

บางคนต้องการ Vim แค่อาศัยทำการแก้ไขด่วนผ่าน SSH; บางคนสร้างสภาพแวดล้อมประจำวันรอบมัน วัฒนธรรมของ Vim ทำงานเมื่อมันยอมรับทั้งสองเป้าหมายว่าเป็นสิ่งถูกต้อง—และทำให้เส้นทางระหว่างกันสว่างพอ.

Vim ในการทำงานจริง: ตั้งแต่การแก้ไขด่วนจนถึงการพัฒนาเป็นประจำ

ชื่อเสียงของ Vim มักมาจาก "พลัง" แต่คุณค่าจริง ๆ ปรากฏในช่วงปกติ: ข้อความคอมมิตที่ต้องการความชัดเจน ไฟล์ config ใน production ที่ต้องแก้ปลอดภัย หรือการทำงานเป็นคู่ที่คุณต้องการให้การแก้ไขชัดเจนและอธิบายง่าย

เวิร์กโฟลว์ที่คุณจะใช้จริง

การเขียนคอมมิต: นักพัฒนาหลายคนตั้ง Git ให้เปิด Vim สำหรับข้อความคอมมิตและ interactive rebase. การแก้ไขแบบมีโหมดเหมาะเพราะคุณใช้เวลาส่วนใหญ่ในการอ่านและจัดเรียงข้อความ ไม่ใช่การแทรก Normal mode กลายเป็นโหมดทบทวน: กระโดดระหว่างประโยค ย้ายบรรทัด และแก้ไขเล็ก ๆ โดยไม่ต้องคว้าเมาส์

แก้ไขด่วนบนเซิร์ฟเวอร์: เมื่อคุณ SSH เข้าเครื่องและต้องแพตช์ config, Vim มักจะพร้อมอยู่ เป้าหมายไม่ใช่การปรับแต่งมากมาย—แต่เป็นความมั่นใจ: ค้นหาส่วนที่ถูกต้อง แก้แค่สิ่งที่ตั้งใจ บันทึก และออกอย่างสะอาด

การทำงานคู่: Vim อาจเข้ากันได้ดีกว่าที่คิดเพราะการกระทำชัดเจน การพูดว่า “ลบบทความนี้” หรือ “เปลี่ยนข้างในอัญประกาศ” แปลเป็นคำสั่งชัดเจน และคู่ของคุณเรียนรู้จากการสังเกต

การรวมกับเทอร์มินัล: เครื่องมือรอบตัวแก้ไข

Vim มักโดดเด่นเมื่อคุณมองเป็นเครื่องมือหนึ่งในห่วงโซ่ คุณสามารถค้นหาด้วย ripgrep/grep เปิดผล แล้วแก้ไขเป้าหมาย—โดยไม่ต้องเปลี่ยนตัวแก้ไขเป็น IDE เต็มรูปแบบ

ตัวอย่างลูปทั่วไปคือ: รันการค้นหาในเทอร์มินัล เปิดไฟล์ที่พบ แก้ไข แล้วรันทดสอบอีกครั้ง มันคือหลักการ “ทำสิ่งหนึ่งให้ดี” ที่ใช้ในงานประจำ: เทอร์มินัลค้นหา; Vim แก้; ตัวรันทดสอบยืนยัน.

เช็คลิสต์ตั้งค่าพื้นฐานสำหรับการใช้งานประจำ

• ตั้ง editor สำหรับ Git: git config --global core.editor "vim"
• เปิดพื้นฐาน: หมายเลขบรรทัด การเยื้องที่เหมาะสม และการไฮไลต์การค้นหา
• เรียนรู้การเคลื่อนที่/แก้ไขไม่กี่อย่างที่ใช้เป็นชั่วโมง (ค้นหา, เปลี่ยนคำ, เปลี่ยนข้างในตัวคั่น)
• เพิ่มการปรับปรุงคุณภาพชีวิตทีละอย่าง (เช่น ตัวค้นหาไฟล์หรือการคอมเมนต์)
• เก็บ vimrc เล็ก ๆ ที่อ่านง่ายเพื่อทำซ้ำได้ทุกที่

นั่นคือวิธีที่ Vim ขยายตัว: ไม่ใช่ด้วยการเพิ่มความซับซ้อน แต่ด้วยการทำให้การแก้ไขที่พบบ่อยเร็ว, ย้อนกลับได้ และสม่ำเสมอในทุกสภาพแวดล้อม.

การแลกเปลี่ยนและความเข้าใจผิด: มุมมองที่สมดุล

Vim มีข้อดีจริง ๆ แต่ก็สะสมตำนานบางอย่าง ความคิดเห็นดัง ๆ บางส่วนมาจากคนที่ลองมันแค่สุดสัปดาห์เดียว หรือจากแฟนที่ถือมันเป็นเหรียญตรา กรอบที่มีประโยชน์กว่าคือ: Vim คือชุดแนวคิดการปฏิสัมพันธ์ (โดยเฉพาะการแก้ไขแบบมีโหมด) ที่เข้ากับเวิร์กโฟลว์หลายแบบได้ แต่ไม่ใช่คำตอบที่ดีที่สุดสำหรับทุกคนหรือทุกทีมโดยอัตโนมัติ.

ข้อวิจารณ์ทั่วไป (และความจริงที่เป็น)

"เส้นโค้งการเรียนรู้ชันเกินไป"

จริงในช่วงแรกเพราะพื้นฐานต่าง: โหมด, operator + motion, และการเน้นกริยาในการแก้ไข มากกว่าปุ่มหรือเมนู เส้นโค้งเรียบลงถ้าคุณเรียนรู้แกนหลักเล็ก ๆ แล้วใช้ทุกวัน แต่ถ้าคุณเปิด Vim เป็นครั้งคราว ความทรงจำกล้ามเนื้อจะไม่เกิดขึ้น

"มันไม่ค้นพบได้ง่าย"

จริงบางส่วน. Vim ให้รางวัลกับการอ่าน :help แต่ส่วนติดต่อไม่ได้โฆษณาฟีเจอร์ตลอดเวลา การค้นพบอยู่—แต่ในที่ต่างออกไป: หัวข้อช่วยเหลือ แบบฝึกหัดในตัว และวัฒนธรรมการแบ่งปันแพตเทิร์นเล็ก ๆ

"Vim แต่ละตัวต่างกัน"

จริงเช่นกัน การตั้งค่าต่างกัน ปลั๊กอินเปลี่ยนพฤติกรรม และแม้แต่ค่าเริ่มต้นอาจต่างกันระหว่างสภาพแวดล้อม สิ่งนี้อาจน่าหงุดหงิดเมื่อทำงานคู่หรือข้ามเครื่อง ทีมมักแก้ด้วยค่าเริ่มต้นร่วมขั้นต่ำ (หรือตกลงใช้ “vanilla Vim”) แทนที่จะพยายามทำให้ทุกอย่างเหมือนกัน

เมื่อ Vim ไม่ใช่ตัวเลือกที่ดีที่สุด

Vim อาจไม่เหมาะเมื่อต้องใช้ IDE เฉพาะที่ทีมต้องการ เวลาเรียนรู้จำกัด หรือความต้องการด้านการเข้าถึงทำให้การใช้งานคีย์หนัก ๆ ไม่สะดวก ความชอบส่วนบุคคลก็สำคัญ: บางคนคิดได้ดีใน UI ที่มองเห็นพร้อมเครื่องมือรีแฟกเตอร์ที่ครบถ้วน และพวกเขาจะทำงานได้ดีที่สุดในสภาพแวดล้อมแบบนั้น

แนวทางที่เป็นประโยชน์คือเลือกเครื่องมือที่สนับสนุนงานที่คุณทำจริง ๆ: แก้ไขด่วนบน SSH, แก้ไขไฟล์ config, เขียนโค้ดตลอดวัน, หรือทำงานร่วมกันในสภาพแวดล้อมที่เป็นมาตรฐาน

หลีกเลี่ยงกับดักความสามารถในการเพิ่มขึ้น

กับดักสองอย่างล่อผู้เรียนที่มุ่งมั่น:

อันดับแรก การปรับแต่งไม่รู้จบ — ใช้เวลามากกว่าการเรียนรู้และใช้จริง. ประการที่สอง การสะสมทางลัด — รวบรวมคำสั่งโดยไม่สร้างนิสัยที่ทำซ้ำได้ หากคุณต้องการให้ Vim ทำให้เร็วขึ้น ให้มุ่งที่เวิร์กโฟลว์ที่คุณทำซ้ำทุกสัปดาห์ และอัตโนมัติเฉพาะสิ่งที่คุณระบุชื่อได้อย่างชัดเจน

กฎที่ดี: หากการเปลี่ยนแปลงไม่ได้ประหยัดเวลา หรือลดข้อผิดพลาดในสัปดาห์ถัดไป ให้เลื่อนมันออกไป

คำแนะนำที่สมดุล

Vim มีคุณค่ามากที่สุดเมื่อมันช่วยให้คุณรักษากระแสในการทำงาน แก้ไขด้วยเจตนา และสร้างรูปแบบที่ทำซ้ำได้ หากตัวแก้ไขอื่นทำสิ่งเหล่านั้นได้ดีกว่าสำหรับคุณ—หรือสำหรับทีมของคุณ—เลือกมันโดยไม่รู้สึกผิด เป้าหมายไม่ใช่การ “ใช้ Vim” แต่เป็นการผลิตงานที่ดีขึ้นด้วยแรงเสียดทานน้อยลง.

เส้นทางการเรียนรู้เชิงปฏิบัติ: สร้างนิสัย ไม่ใช่ท่องรายละเอียด

การเรียนรู้ Vim ติดแน่นเมื่อคุณถือมันเป็นการสร้างนิสัยเชิงปฏิบัติ ไม่ใช่การสะสมคำสั่งแปลก ๆ เป้าหมายคือรู้สึกสงบและสามารถแก้ไขได้ แม้ก่อนจะรู้สึกว่า "เร็ว".

แผนง่าย ๆ 2–4 สัปดาห์ (ฝึกวันละเล็กน้อย)

ใช้เวลา 10–15 นาทีต่อวัน และใช้ Vim ทำงานจริงสักอย่าง (แม้แต่เล็กน้อย). จดสิ่งที่รู้สึกติดขัดและสิ่งที่ลื่นขึ้น

สัปดาห์ 1: ความคุ้นเคยและความปลอดภัย

เน้นไม่ให้ติดค้าง ฝึกการเปิดไฟล์ บันทึก ออกจากโปรแกรม และ undo

สัปดาห์ 2: การนำทางและการค้นหา

เริ่มย้ายในจังหวะที่ใหญ่ขึ้นและใช้การค้นหาเพื่อไปยังที่ใดก็ได้อย่างรวดเร็ว

สัปดาห์ 3–4: เวิร์กโฟลว์การแก้ไข

เพิ่มชุดเล็ก ๆ ของ “แก้ไข + ทำซ้ำ”: เปลี่ยน/ลบ/ย้าย/ย้ายซ้ำด้วย ., และมาโครพื้นฐานสำหรับสิ่งที่คุณทำบ่อย

นิสัยเริ่มต้น (สิ่งที่คุณจะใช้จริง)

• ออกจากอย่างปลอดภัย: :w, :q, :wq, :q!, พร้อม u (undo) และ \u003cC-r\u003e (redo)
• เคลื่อนที่อย่างมีประสิทธิภาพ: w, b, e, 0, $, gg, G, และใช้งาน f{char} บ้าง
• ค้นหาอย่างมั่นใจ: /pattern, n / N, และ :%s/old/new/g (ลองก่อนโดยไม่ใส่ flags)

ไอเดียฝึกที่รู้สึกจริง

แก้ README: แก้หัวข้อ ย้ายบูลเล็ต และเขียนย่อหน้าใหม่โดยไม่คว้าเมาส์

รีแฟกเตอร์ไฟล์เล็ก ๆ: เปลี่ยนชื่อตัวแปรด้วยค้นหา+แทนที่ แยกบรรทัดบางส่วน และจัดเยื้องใหม่

จดบันทึกใน Vim: เขียนบันทึกสั้น ๆ ทุกวัน การทำซ้ำสร้างความคุ้นเคยเร็วกว่าการฝึกยาก ๆ

วัดสิ่งที่ถูกต้อง

ติดตาม ความคุ้นเคย (ความตื่นตระหนกน้อยลง) และ ความสม่ำเสมอ (การตัดสินใจเปลี่ยนบริบทน้อยลง) ไม่ใช่ความเร็วล้วน ๆ ถ้าคุณคาดการณ์ได้ว่าคำสั่งจะทำอะไร—และกู้คืนได้เมื่อผิด—คุณกำลังเรียนรู้สิ่งที่จะคงทน

มรดก: สิ่งที่ Vim สอนเกี่ยวกับงานฝีมือและชุมชน

มรดกของ Bram Moolenaar ไม่ได้มีเพียงการสร้างตัวแก้ไข Vim เท่านั้น แต่ยังเป็นตัวอย่างของการดูแลอย่างใจเย็น เป็นเวลาหลายทศวรรษเขาตรวจแพตช์ คัดสรรการออกเวอร์ชัน ตอบคำถาม และรักษา "ความรู้สึก" ที่ชัดเจนให้กับเครื่องมือ: มีประสิทธิภาพ สอดคล้อง และให้อภัยเมื่อคุณเรียนรู้ไวยากรณ์ของมัน ประเพณี "charityware" ของ Vim ยังสะท้อนค่านิยมของ Bram: ซอฟต์แวร์เป็นสินค้าสาธารณะ และการดูแลรักษาคืองานจริงที่สมควรได้รับความเอาใจใส่

งานฝีมือ: นิสัยเล็ก ๆ สะสมเป็นผล

Vim ให้รางวัลกับความใส่ใจในการกระทำเล็ก ๆ ที่ทำซ้ำได้ บทเรียนใหญ่ไม่ใช่คำสั่งเฉพาะ แต่เป็นแนวคิด: ลงทุนในนิสัยที่ลดแรงเสียดทาน ไม่กี่วินาทีที่ประหยัดในแต่ละครั้งอาจไม่มากนัก—จนกว่ามันจะกลายเป็นวิธีคิดปกติขณะที่คุณเขียนโค้ด โน้ต หรือเรียบเรียงงาน เมื่อเวลาผ่านไป ตัวแก้ไขจะไม่ใช่เครื่องมือที่คุณควบคุม แต่เป็นสื่อที่คุณทำงานผ่าน

น่าสนใจที่แนวคิด "เจตนาเป็นหลัก" นี้ถ่ายโอนสู่เวิร์กโฟลว์ใหม่ ๆ ได้ดีด้วย หากคุณสร้างซอฟต์แวร์ผ่านอินเทอร์เฟซแชท—เช่น วิธี vibe-coding ของ Koder.ai—นิสัยเดียวกันใช้ได้: ทำการเปลี่ยนแปลงเป็นคำสั่งที่ชัดเจน ทำซ้ำเป็นชิ้นเล็ก ๆ และพึ่งตาข่ายนิรภัย (เช่น snapshots และ rollback) แทนการแก้ไขครั้งใหญ่ที่เสี่ยง.

ชุมชน: เครื่องมืออยู่รอดเมื่อคนยังอยู่

Vim ยังสอนงานสังคม: เรียนรู้ในที่สาธารณะ แชร์ dotfiles อย่างคิดเป็น เขียนรายงานบั๊กชัดเจน และปฏิบัติต่อผู้มาใหม่ด้วยความอดทน บรรทัดฐานที่ดีทำให้เครื่องมือที่ยากเข้าถึงได้ง่ายขึ้น หากคุณอยากลงลึก แหล่งช่วยเหลือในตัวและทรัพยากรของชุมชนเป็นส่วนหนึ่งของผลิตภัณฑ์ ไม่ใช่ของเสริมนอกสุด

ก่อนปิดบทความนี้ ให้เลือกการเปลี่ยนแปลงเวิร์กโฟลว์หนึ่งอย่างที่คุณจะลองในสัปดาห์นี้: แม็ปปุ่มที่คุณมักเอื้อมถึง ฝึกรูปแบบการแก้ไขที่ทำซ้ำได้หนึ่งอย่าง หรือเขียนค่าเริ่มต้นเล็ก ๆ ลงใน vimrc ของคุณ

สุดท้าย โน้ตอย่างเคารพ: ชุมชนโอเพนซอร์สยังคงมีชีวิตเมื่อผู้ใช้กลายเป็นผู้สนับสนุน—ผ่านการบริจาค เอกสาร การส่งบั๊กอย่างระมัดระวัง การตรวจโค้ด หรือเพียงบอก "ขอบคุณ" มรดกของ Bram เตือนว่า คนที่ดูแลเครื่องมือของเราสำคัญไม่แพ้เครื่องมือเอง