ประสบการณ์หลังย้ายจาก Vim ไปใช้ Helix

 (jvns.ca)
11 คะแนน โดย GN⁺ 2025-10-11 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักพัฒนาที่ใช้ Vim มานาน 20 ปีได้แชร์ประสบการณ์หลังเปลี่ยนมาใช้ Helix editor เป็นเวลา 3 เดือน
  • จุดที่น่าสนใจของ Helix คือรองรับ Language Server (LSP) มาให้ในตัวโดยไม่ต้องตั้งค่าซับซ้อน
  • โดยเฉพาะเมื่อเทียบกับ Vim/Neovim แล้ว ฟีเจอร์อย่าง การค้นหาที่ทรงพลังกว่าและ multi-cursor ได้รับการปรับปรุง ทำให้ดูบริบทในหลายไฟล์และแก้ไขทีเดียวหลายจุดได้สะดวก
  • เวลากดคีย์จะมี quick reference popup ช่วยให้ใช้งานคีย์ลัดได้โดยไม่ลืม
  • แม้จะมี ข้อไม่สะดวกบางอย่าง เช่น ไม่รองรับการสร้าง Markdown list อัตโนมัติ ไม่มี persistent undo และมีอาการแครชประมาณสัปดาห์ละครั้ง แต่โดยรวมก็เป็นประสบการณ์ใช้งานที่น่าพอใจ
  • การฝึกกล้ามเนื้อความจำจาก Vim ที่สั่งสมมา 20 ปีใหม่อีกครั้งกลับง่ายกว่าที่คิด และการเรียนรู้ "วิธีแบบ Helix" โดยไม่พยายามบังคับให้เหมือน Vim มีประสิทธิภาพกว่ามาก

เหตุผลที่เปลี่ยนมาใช้ Helix

  • จุดเริ่มต้นที่ทำให้หันมาใช้ Helix คืออยากใช้ ความสามารถด้านการทำงานร่วมกับ Language Server ได้อย่างง่ายดาย
    • ใน Vim/Neovim การตั้งค่า language server ค่อนข้างซับซ้อน แต่ Helix สามารถใช้งาน go to definition หรือ rename symbol ได้ทันทีโดยไม่ต้องตั้งค่าเพิ่ม
    • เดิมทีต้องคอยดูแลปลั๊กอินจำนวนมากและไฟล์ตั้งค่าหลายชุด แต่ Helix ลดภาระนี้ลงด้วยการรองรับมาให้ในตัว

ข้อดีหลักของ Helix

  • ระบบค้นหาที่ยอดเยี่ยม
    • เมื่อค้นหาสตริงทั้งทั้ง repository ผลลัพธ์จะแสดงใน หน้าต่างพรีวิว ทำให้ เลื่อนดูไฟล์ที่ตรงกันพร้อมเห็นโค้ดรอบข้างได้
    • ต่างจากปลั๊กอิน ripgrep ของ Vim ที่ให้ผลลัพธ์พร้อม บริบทที่สมบูรณ์กว่า จึงตัดสินใจได้เร็ว
  • ฟีเจอร์อ้างอิงคีย์ลัดอย่างรวดเร็ว
    • เมื่อกดปุ่ม g จะมีรายการคำสั่งที่ใช้งานได้แสดงใน ป๊อปอัปช่วยเหลือ ทำให้เข้าใจได้ง่าย
    • แม้เป็นคีย์ลัดที่ไม่ได้ใช้บ่อยก็ตรวจสอบได้ง่าย จึงมี learning curve ที่ไม่ชันมาก

ความแตกต่างระหว่าง Vim กับ Helix

  • ฟีเจอร์ mark ใช้การติดตามประวัติการย้ายเคอร์เซอร์ด้วย Ctrl+O, Ctrl+I แทน ma, 'a
  • ใช้การแก้ไขแบบ multi-cursor เป็นหลักแทน macro
    • เวลาปรับแก้ทั้งเอกสาร ใช้ % เพื่อเลือกทั้งหมด → s เพื่อเลือกด้วย regex → จากนั้นแก้ไขหลายจุดพร้อมกันตามต้องการ
    • multi-cursor สะดวกกว่าการต้องเขียน macro ทุกครั้งมาก
  • แทนที่จะใช้ tab จะใช้ buffer switcher ผ่าน space + b เพื่อสลับได้อย่างรวดเร็ว

จุดที่ไม่สะดวกของ Helix

  • ฟีเจอร์ text reflow มีประสิทธิภาพด้อยกว่า gq ของ Vim
    • และเข้ากับลิสต์ได้ไม่ดีนัก
  • ไม่รองรับ การสร้าง Markdown list อัตโนมัติ
    • กด "Enter" ที่ท้ายรายการแล้วลิสต์จะไม่ต่อให้อัตโนมัติ
    • มีทางแก้บางส่วนสำหรับ bullet list แต่ยังไม่มีสำหรับ numbered list
  • ยังไม่มี persistent undo
    • ใน Vim ใช้ undofile เพื่อย้อนการเปลี่ยนแปลงได้แม้ปิดโปรแกรมไปแล้ว แต่ Helix ยังไม่มีฟีเจอร์นี้
  • ไม่รองรับ การรีโหลดไฟล์อัตโนมัติ
    • หลังไฟล์บนดิสก์ถูกแก้ไข ต้องสั่ง :reload-all (:ra<tab>) ด้วยตนเอง
  • มีแครชเป็นครั้งคราว
    • ประมาณสัปดาห์ละครั้ง และอาจเกี่ยวข้องกับการแก้ไข Markdown จำนวนมาก
    • แต่เปิดใหม่ได้ทันทีจึงไม่ใช่ปัญหาใหญ่
  • ถึงอย่างนั้นก็ยัง ใช้งาน Helix ต่อไป

กระบวนการเปลี่ยนผ่านและประสบการณ์การเรียนรู้

  • เดิมทีผู้เขียนกังวลว่าการฝึกกล้ามเนื้อความจำจาก Vim ที่สะสมมา 20 ปีใหม่จะ ยากมาก
  • ระหว่างวันหยุดจึงเริ่มใช้ Helix กับ side project และ ผ่านไป 1-2 สัปดาห์ก็ไม่รู้สึกสับสนอีกต่อไป
  • ตอนแรกพยายามบังคับให้คีย์ลัดคล้าย Vim แต่ไม่สำเร็จ และพบว่าการเรียนรู้ "วิธีแบบ Helix" ง่ายกว่ามาก
  • ยังมีบางจุดที่ทำให้สับสนอยู่
    • w ใน Vim กับ w ใน Helix ให้นิยามคำว่า "word" ไม่เหมือนกัน (Helix นับรวมช่องว่างหลังคำ ส่วน Vim ไม่นับ)

สภาพแวดล้อมการแก้ไขแบบ terminal

  • เนื่องจากตลอดหลายปีที่ผ่านมาใช้ vim/neovim เวอร์ชัน GUI เป็นหลัก การกลับมา ใช้ editor ใน terminal จึงต้องปรับตัวเล็กน้อย
  • workflow ที่ลงตัวในที่สุดคือ
    • ใช้หน้าต่าง terminal แยกกันสำหรับแต่ละโปรเจกต์ และทุกแท็บในหน้าต่างนั้นใช้ working directory เดียวกัน
    • วางแท็บ Helix เป็นแท็บแรกของหน้าต่าง terminal
  • วิธีนี้ทำให้จัดการหลายโปรเจกต์แบบขนานได้สะดวก และอาจดีกว่า workflow เดิมด้วยซ้ำ

การตั้งค่า

  • เมื่อเทียบกับการตั้งค่า Neovim ที่ยาวหลายร้อยบรรทัด ผู้เขียนคงไว้เพียง การตั้งค่าที่เรียบง่ายมาก
    • โดยหลักแล้วตั้งค่าแค่คีย์ลัด 4 รายการ
  • รายละเอียดการตั้งค่าหลัก
    • ธีม: solarized_light
    • ตั้งค่า yank register เริ่มต้นเป็น + เพื่อซิงก์กับ system clipboard
    • ตั้ง # เป็นคีย์ลัดสำหรับสลับคอมเมนต์ (เพราะไม่ชอบค่าเริ่มต้น Ctrl+C)
    • remap ^ และ $ ให้ย้ายไปต้น/ท้ายบรรทัด (เพราะไม่อยากเรียนรู้วิธีอื่น)
    • ตั้ง <space>l เป็น :reflow (เพราะเขียนข้อความเยอะจึงต้อง reflow บ่อย และคิดถึงคีย์ลัด gq ของ Vim)
  • ใช้ไฟล์ตั้งค่า languages.toml แยกสำหรับกำหนดค่าตามภาษา
    • สำหรับ Python: ใช้ตัวจัดรูปแบบ black, language server เป็น pyright และปิด auto format

บทสรุป: ความประทับใจหลังใช้ 3 เดือน

  • 3 เดือนยังไม่ใช่ช่วงเวลาที่ยาวนัก และก็ยัง มีโอกาสที่จะกลับไปใช้ Vim ในอนาคต
    • ก่อนหน้านี้เคยย้ายไปใช้ nix แล้วกลับมา Homebrew หลัง 8 เดือน (แม้กระนั้นก็ยังใช้ NixOS ดูแลเซิร์ฟเวอร์เครื่องหนึ่งอยู่และพอใจมาก)
  • Helix ยังไม่ใช่เครื่องมือที่สมบูรณ์ แต่มีทิศทางชัดเจนในฐานะ "editor ที่แทบไม่ต้องตั้งค่า"
  • ด้วยความเรียบง่ายและฟีเจอร์ที่มีมาให้ในตัว จึงมีศักยภาพระยะยาวในการ ทดแทน Vim
  • อย่างไรก็ตาม จะใช้งานต่อเนื่องได้มากน้อยเพียงใดยังขึ้นอยู่กับ การปรับปรุงเสถียรภาพและการเพิ่มฟีเจอร์ ในอนาคต

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2025-10-11
ความเห็นจาก Hacker News
  • บางครั้งเอดิเตอร์ก็แครชจาก segfault ประมาณสัปดาห์ละครั้ง แต่ก็ไม่ได้ใส่ใจมาก แนวคิดเรื่องการสูญหายของข้อมูลแบบ "แค่เปิดใหม่ก็พอ" นี่น่าสนใจดี แต่ Helix ไม่มี persistent undo ดังนั้นถึงจะเปิดใหม่ก็ไม่ได้กลับไปยังสถานะเดิม
    ใช้ Vim/Neovim มานานมาก ทั้งเคยปรับแต่ง config เองและใช้ config ที่คนอื่นทำไว้ แต่ถึงจะชอบ Vim มาก ก็ยังรู้สึกว่าเสน่ห์ของ Helix คือใช้งานได้ทันทีโดยแทบไม่ต้องตั้งค่าอะไรเพิ่ม
    แต่ก็รู้สึกว่า config ของ Helix เองค่อนข้างดิบมาก เลยคิดจริง ๆ ว่าถ้าใช้ Vim มาสักไม่กี่ปีก็น่าจะจำลองสภาพแวดล้อมที่ได้จาก Helix ได้อยู่แล้ว และอยากจะบอกว่าถ้าทำแบบนั้นก็ไม่ต้องตกนรกกับการตั้งค่าอีกต่อไป
    ชอบมากที่มีป๊อปอัปช่วยเหลือบอกเส้นทางหรือคีย์ไบน์ที่ควรใช้ ปกติไม่ได้ใช้ฟีเจอร์อย่าง "ไปยังคำนิยาม" หรือ "ไปยังรีเฟอเรนซ์" บ่อย เลยลืมคีย์ลัดง่าย ถ้ามีป๊อปอัปตามบริบทแบบนี้ใช้กันแพร่หลายก็คงดีมาก และถ้ามันฉลาดพอที่จะโผล่มาเฉพาะตอนที่เราลังเลก่อนกดคีย์ ก็น่าจะมีประโยชน์มากจริง ๆ
    • ถ้าทุกแอปมีป๊อปอัปช่วยเหลือตามบริบทเวลาต้องใช้คีย์ไบน์ซับซ้อน ๆ น่าจะสะดวกมาก โดยเฉพาะถ้าแสดงอย่างฉลาดเฉพาะตอนที่อินพุตหยุดชะงักก็จะยิ่งดี
      ใช้ Vim/Neovim มา 20 ปี แต่เพิ่งติดตั้งปลั๊กอิน which-key เมื่อ 6 เดือนก่อน และใช้งานได้มีประโยชน์มาก
      which-key.nvim GitHub
    • เหมือนจะพลาดบริบทของปัญหาการตั้งค่าใน Vim ไป
      ผมพยายามอยู่เรื่อย ๆ ที่จะตั้งค่า language server หลักให้เข้าที่เข้าทางอย่างเหมาะสม (เช่น ให้ "ไปยังคำนิยาม" ใช้งานได้) แต่รู้สึกว่ามันยากเกินไปที่จะทำสภาพแวดล้อมใน Vim หรือ Neovim ให้ใช้งานได้สบาย
    • เห็นด้วยว่าเซ็ตอัปใน Vim จำลองได้ แต่จุดที่สะดวกมากของ Helix คือสามารถติดตั้งบนเซิร์ฟเวอร์แล้วใช้งานได้ทันที
      ไม่ต้องวุ่นวายกับการย้าย config ของ Vim และ dependency ที่เกี่ยวข้อง ทำให้สภาพแวดล้อมการพัฒนาพกพาได้มากขึ้นมาก (แม้จะยังไม่เทียบเท่าเซ็ตอัป Vim ที่ซับซ้อน)
    • เห็นด้วยกับฟีเจอร์ป๊อปอัปช่วยเหลือ 100% ถ้ามีฟีเจอร์แบบนี้ในหลาย ๆ ที่จะช่วยได้มากจริง ๆ
      โดยเฉพาะพอเห็นคำอธิบายกับภาพหน้าจอในบทความนี้ก็ยิ่งอยากได้ฟีเจอร์นี้มาก
      ถ้าป๊อปอัปโผล่มาอย่างฉลาดด้วยเงื่อนไขอย่าง timeout ก็จะยอดเยี่ยม เพราะตอนที่ไม่ต้องการก็ไม่ถูกรบกวน และตอนที่ลังเลก็จะได้รับคำแนะนำอัตโนมัติ
    • ใช้ Helix แทบทุกวันมา 3 ปีแล้ว แต่เจออาการล่มจาก segfault น้อยมาก จัดว่าแทบไม่มีเลย
  • ตอนนี้ติด Helix มากและใช้กับงานพัฒนาทั้งหมด
    ก่อนหน้านี้ใช้ neovim กับ VS Code เป็นหลัก แต่ Helix เข้ามาเติมช่องว่างเฉพาะทางได้พอดี
    • ดีไซน์สวยมาก (ใส่ใจรายละเอียดเยอะ)
    • ประสิทธิภาพเร็ว (ไม่เคยรู้สึกว่าช้า)
    • คีย์ไบน์เริ่มต้นออกแบบตามหลักสรีรศาสตร์และเข้ามือมาก
    • ติดตั้งแล้วใช้ได้เลยโดยไม่ต้องตั้งค่า
      ขี้เกียจตั้งค่า neovim หรือใช้ vim ต่อไป เลยต้องการอะไรกลาง ๆ ระหว่าง VS Code กับ nvim แล้ว Helix ก็ตอบโจทย์พอดี
      ถ้าเป็นคนที่เชี่ยวชาญ vimscript จริง ๆ อาจจะลังเลอีกแบบ แต่ผมไม่ใช่ เลยพอดีมาก
      ไม่ได้อยากให้ Helix modular มากขึ้นหรือทำงานแบบ UNIX มากกว่านี้ ขอให้เป็นแบบตอนนี้ก็พอ
      ตอนนี้มี ecosystem ของเครื่องมือหลากหลายอยู่แล้ว และยังใช้งานร่วมกับ Claude Code ได้ด้วย (รีเฟรชบัฟเฟอร์เพื่อให้เห็นการแก้ไขใหม่)
      มันเป็นหนึ่งในเอดิเตอร์ที่ดีที่สุดจนผมเริ่มสนับสนุนโครงการรายเดือนแล้ว
      ถ้าจะหวังการพัฒนาต่อไป สิ่งที่ยังขาดที่สุดคือความสามารถในการเรนเดอร์ภาพหรือสูตรคณิตศาสตร์ในเอดิเตอร์เอง หวังว่าส่วนนี้จะทำได้ผ่านปลั๊กอินอย่าง Kitty terminal protocol หรือ sixel
      อยากใช้มันกับงานโน้ต/บล็อกในไฟล์ Markdown โดยเฉพาะ
      ขอให้ Helix ไปได้สวย
    • แอปแบบ Helix ที่ติดตั้งแล้วใช้งานได้เลยทำให้อุ่นใจมาก เพราะกังวลเรื่อง supply chain attack น้อยลง
      VSCode หรือ (neo)vim ต้องดึงปลั๊กอินมาจากหลายแหล่ง เลยรู้สึกไม่สบายใจเสมอ
    • ถ้าต้องการอะไรตรงกลางระหว่าง nvim กับ vscode ก็สงสัยว่าใช้ vim plugin บน vscode ตรง ๆ ไม่ได้หรือ
    • ผมชอบ helix แต่ก็ยังไม่ถึงกับจะเลิกใช้ nvim
      แม้จะไม่ใช่นักพัฒนา Lua แต่ LLM ก็ช่วยตั้งค่าหรือแก้ config ของ nvim ได้มาก
      เหตุผลใหญ่ที่สุดที่ย้ายมาลอง helix คือการตั้งค่า LSP/ลินต์ที่ทำได้ดีมาก
    • เห็นว่าคำว่า "ผู้เชี่ยวชาญ vimscript" อาจไม่ตรงนัก เพราะจริง ๆ neovim ทุกวันนี้ก็ควรใช้ Lua แล้วไม่ใช่หรือ
  • ลองย้ายจาก neovim ไป helix อยู่หลายสัปดาห์ แต่จดไว้เพราะยังมีฟีเจอร์จำเป็นที่ยังไม่ถูกทำ
    • code action อัตโนมัติตอนบันทึก (เช่น เพิ่ม Go import): PR #6486
    • fuzzy search ที่เชื่อมกับ file picker แบบ telescope+rg: PR #11285
    • อัปเดตบัฟเฟอร์อัตโนมัติเมื่อไฟล์บนดิสก์มีการเปลี่ยนแปลง: อิสซู #1125
    • ฟีเจอร์ file tree browser: ถูกปฏิเสธในฐานะส่วนหนึ่งของระบบปลั๊กอิน และยังไม่ถูกทำ PR #5768 นอกจากนี้ก็ยังมีเรื่องเล็ก ๆ น้อย ๆ ที่พอทนได้ คิดว่าอีก 1-2 ปีค่อยกลับมาลองใหม่
    • ผมใช้ Helix โดย build จาก HEAD ผ่าน homebrew บ่อย ๆ เลยแปลกใจที่บอกว่า Julia ทำให้แครชบ่อย
      ขอแชร์บางอย่างเกี่ยวกับฟีเจอร์ที่ merge แล้วใน HEAD —

      code action ตอนบันทึก: แก้ได้ด้วย hook ตอนบันทึก (ใช้ได้กับ Go) แต่อาจยากกับภาษาอื่น
      fuzzy search: มีในตัวมานานมากแล้ว และเพิ่งมีการ rework ล่าสุดจนดีขึ้นมาก
      อัปเดตบัฟเฟอร์อัตโนมัติ: เป็นฟีเจอร์ที่จำเป็นมาก เพราะผมมักปล่อยเอดิเตอร์ไว้เบื้องหลังอยู่เรื่อย ๆ
      file tree: ใน HEAD ใช้ Space+e/E เพื่อเปิดตัวสำรวจแบบลำดับชั้นได้ เป็นของที่เพิ่มเข้ามาค่อนข้างใหม่

    • file explorer ที่ลิงก์ไว้หยุดไปแล้ว แต่ตัวสำรวจสไตล์ vim-telescope ถูกรวมเข้า Helix ไปเมื่อต้นปีนี้
      เพราะมี file picker ในตัวที่อิงกับ fuzzy search อยู่แล้ว ตัวสำรวจไฟล์แบบทั่วไปเลยไม่ได้เพิ่มประโยชน์มากนัก
    • ผมก็พยายามย้ายจาก neovim ไป helix เหมือนกัน แต่เพราะ muscle memory ของคำสั่ง vim ที่ใช้มาหลายสิบปี ความผิดพลาดเล็ก ๆ เลยสะสมจนถอดใจเร็วมาก
      เคยลองปลั๊กอินคีย์ไบน์แบบ vim สำหรับ Helix ด้วย แต่ตรงกันแค่บางส่วน เลยยิ่งผิดหวัง
    • เสียดายที่เวลามีโปรแกรมภายนอก (templ, sqlc ฯลฯ) มาแก้ไฟล์ Helix ไม่ตรวจจับแล้ว reload ไฟล์ให้อัตโนมัติ
      อยากรู้ว่าผู้ใช้ Helix ที่ชำนาญแก้กันอย่างไร
  • เหตุผลหลักที่หันมาใช้ Helix มาจากกระบวนการตั้งค่า language server (LSP)
    เพราะการตั้งค่า language server ให้ใช้งานสบาย ๆ ใน Vim/Neovim กลายเป็นงานที่เหนื่อยเกินไป เลยย้ายมา Helix
    แต่ในช่วง 5 ปีที่ผ่านมา Neovim ก็มีดิสโทรแบบแบตเตอรี่มาครบที่ทำให้ตั้งค่าได้ง่ายมากแล้ว
    เห็นด้วยว่านักพัฒนาหลายคนไม่อยากเสียเวลาไปกับการดีบักเอดิเตอร์ และคิดว่านั่นคือเหตุผลที่ JetBrains ยังได้รับความนิยม
    เพียงแต่ส่วนที่บอกว่าผู้ใช้ Neovim มา 20 ปีแล้วยังไม่เคยตั้งสภาพแวดล้อม LSP ให้ลงตัว ฟังดูเข้าใจยากนิดหน่อย จนสงสัยว่านี่เป็นประสบการณ์จริงของผู้เขียนหรือไม่
    • มีกรณีที่ใช้ Vim มาเกิน 10 ปีโดยไม่เคยตั้งค่า LSP เลย
      สุดท้ายถึงอย่างนั้นก็ยังรู้สึกว่าง่ายกว่าถ้าใช้ IDE เต็มรูปแบบ เลยลังเลกับการติดตั้งและตั้งค่าอยู่เสมอ
    • ผมเองก็ใช้ vim → neovim มามากกว่า 20 ปี แต่พอ LSP พังแล้วคีย์ลัดใช้ไม่ได้ไปด้วย ก็มีอุปสรรคทางใจจนไม่อยากไล่หาสาเหตุแล้ว
      เลยรู้สึกว่าเรื่องของผู้เขียนน่าเห็นใจมาก
    • แปลกใจ เพราะผมไม่เคยลำบากกับการตั้งค่า LSP ทั้งใน og และ neovim
      ผมเองก็ตั้งค่าแบบน้อยที่สุด ใช้ค่อนข้าง barebones แต่ก็ไม่ได้ยาก และ Lua ก็รู้สึกตามหลักสรีรศาสตร์ดีกว่า vimscript มาก
      นั่นเป็นเหตุผลที่ยังใช้เครื่องมืออย่าง ALE ต่อไป
      ยังไงก็หวังว่าคนใช้ Helix จะมีความสุข
    • รู้สึกแปลกมาก ไม่ใช่ว่า Neovim มี LSP ในตัวมานานเกินสองปีแล้วหรือ
    • สังเกตได้ชัดว่าบริษัทขนาดกลางเริ่มทำมาตรฐานเครื่องมือรอบ vscode
      ถึงจะใช้เอดิเตอร์อื่นได้ แต่เกือบทุกอย่างทั้งการดีบักและการตั้งค่ามักอิง vscode เป็นหลัก จึงมักมีบรรยากาศว่าควรใช้ตามนั้น
      การตั้งค่า Neovim+treesitter+LSP ก็ลื่นไหลมากแล้ว แม้ในอดีตอาจยาก แต่ทุกวันนี้ไม่ใช่ประเด็นใหญ่
      ถ้าเหตุผลที่ไป Helix คือเรื่อง LSP ก็ยังสงสัยอยู่ ไม่แน่ใจว่าผู้เขียนมีปัญหากับ LSP จริงหรือเปล่า
  • โมเดล noun-verb (วัตถุ-การกระทำ) ของ Helix ตอนแรกดูสดใหม่ แต่พอใช้จริงกลับรู้สึกว่า verb-noun (การกระทำ-วัตถุ) เข้าท่ากว่ามาก
    ข้อเสียอย่างหนึ่งของแบบ noun-verb คือสั่งซ้ำ (.) ไม่ได้
    ใน Vim ทำซ้ำการกระทำได้อย่าง dd.., dap.. แต่โมเดล noun-verb ทำแบบนี้ได้ยาก
    ที่พื้นฐานกว่านั้นคือเจอปัญหาปุ่มไม่พอ
    การกระทำพื้นฐานเยอะเกินไปจนต้องใช้ปุ่ม Alt และก็ไม่มีโหมด normal/visual/insert แบบ vim มีแค่ visual/insert
    แม้แต่การแยก motion/วัตถุก็ไม่ชัดเจน จึงทำให้การแมปปุ่มยากขึ้นและปัญหาปุ่มไม่พอก็ยิ่งชัด
    • วิธีแบบ verb-noun ถึงขั้นเปลี่ยนวิธีคิดได้เลย
      รู้สึกว่ามันสอดคล้องกับกระบวนการคิดที่ต้องใช้ตอนเขียนโค้ดมากกว่า
  • ความเปลี่ยนแปลงที่ดีที่สุดของ nvim ในช่วงหลังคือ mini.nvim
    เป็นชุดปลั๊กอินของ echasnovski ที่ตอบโจทย์ความต้องการหลากหลาย พร้อมความสม่ำเสมอและเอกสารที่ดี
    ตั้งแต่ nvim 0.12 (nightly) เป็นต้นไป แค่ติดตั้ง mini.nvim กับ lspconfig ผ่านตัวจัดการปลั๊กอินในตัว (vim.pack) ก็พอแล้ว
  • ผมหยุดทึ่งไม่ได้เลยว่าการยอมละทิ้งเครื่องมือเอดิเตอร์ "ขั้นสูง" อย่าง lsp ไปเลยนั้นให้อิสระมากแค่ไหน
    ตอนนี้ใช้ neovim โดยไม่มีปลั๊กอิน ไม่มี autocomplete และไม่มีแม้แต่ syntax highlighting
    รู้สึกว่าการมีวินัยกับตัวเองผ่านวิธีแบบนี้ทำให้เขียนโค้ดได้ดีขึ้น
    อาจไม่เหมาะกับทุกคน แต่แนะนำว่าอย่างน้อยควรลองสักครั้ง
    • เห็นว่าถ้าอยู่ได้โดยไม่มีปลั๊กอินหรือ autocomplete ก็ว่าไปอย่าง แต่ถึงขั้นปิด syntax highlighting ด้วยก็ดูเหมือนทำให้ตัวเองลำบากเกินจำเป็น
    • ผมเองก็ยังไม่ได้เปลี่ยนเต็มตัว แต่ autocomplete ใน Emacs พังมา 1 ปีแล้วและก็ไม่ได้คิดถึงมันเท่าไร
      ไม่ใช้ code action หรือ goto definition ด้วย มีแค่ดู error แบบเรียลไทม์บ้าง แต่คอมไพเลอร์เร็วมากจนไม่ได้มีความหมายมาก
      เลยอยากปิด LSP ไปเลย รู้สึกว่าเมื่อเทียบกับ 20 ปีก่อน LSP ไม่ได้ยกระดับความสามารถในการเขียนโปรแกรมของผมอย่างมหาศาล
      ส่วนเรื่อง syntax highlighting ผมคิดว่าธีมสีฉูดฉาดกลับรบกวนสมาธิและไม่มีความหมาย
      ชอบธีมที่มีสีเดียวหรือสองสีเป็นหลัก และรู้สึกว่าไม่จำเป็นต้องแยกสีชื่อตัวแปรกับชื่อฟังก์ชันด้วยซ้ำ
    • เคยได้ยินว่า Mitchell Hashimoto ก็ทำงานได้ดีด้วยวิธีนี้ เลยยิ่งมั่นใจว่าต่อให้ไม่มี tooling สมัยใหม่ก็ยังทำงานได้มีประสิทธิภาพพอ
      แต่ก็ยังสงสัยว่าการต้องจำทุกอย่างเองจะทำให้ความเหนื่อยล้าสะสมหรือไม่ หรือวิธีนี้ช่วยให้เขียนโค้ดได้ดีขึ้นจริงหรือเปล่า
    • ผมเองเขียนโค้ดโดยไม่ใช้เครื่องมือช่วยใด ๆ เช่นกัน แต่จะเปิด syntax highlighting ตลอด
      สีเป็นข้อมูลอีกมิติหนึ่งที่ช่วยให้เห็นความผิดพลาดหรือ error ในโค้ดเด่นขึ้น และช่วยให้ไล่อ่านโค้ดได้เร็วขึ้น
    • ในโปรเจกต์ส่วนตัวผมใช้เซ็ตอัปมินิมัลแบบนี้
      แต่ไม่ได้สุดโต่งมาก ยังคงเปิด syntax highlighting และคง feedback เรื่อง syntax error ผ่าน LSP ไว้
      ไม่ใช้ autocomplete หรือการลิงก์เอกสารอัตโนมัติ
  • ถ้าอยากเรียนรู้ Helix ขอแนะนำเวอร์ชันรีนิวเอกสาร Helix ที่ทำโดย nic-revs
    helix-editor.vercel.app
    ดูง่ายกว่าเอกสารทางการมาก และมีทิป/ทริกเยอะ เลยช่วยบรรเทาจุดอ่อนของ Helix ได้ เช่น เรื่องไม่มีเทอร์มินัลในตัว รวมถึงช่วยเรื่องวิธีแก้ไขที่มีประสิทธิภาพและคีย์ไบน์ต่าง ๆ
    • ปกติผมอึดอัดกับการอ่านเอกสารทางการที่อ่านยากอยู่แล้ว ข้อมูลนี้ขอบคุณมากจริง ๆ
  • ฟีเจอร์เสริมที่มากเกินไปของดิสโทร Neovim กวนใจพอสมควร
    ถ้าเป็นผู้ใช้ vim มานาน ขอแนะนำ kickstart (โดยเฉพาะฟอร์กแบบ modular kickstart-modular.nvim)
    kickstart.nvim
    เป็นจุดเริ่มต้นแบบมินิมัลที่ยอดเยี่ยมมาก
    • ข้อดีของ kickstart คือทุกการตั้งค่าอยู่ในไฟล์เดียว
      แต่ไฟล์ค่อนข้างใหญ่ ผมเลยจัดการให้ง่ายขึ้นด้วยการใช้ fold marker เพื่อพับแต่ละส่วน
 
qdr7h 2025-10-13

แม้จะสนใจ helix อยู่เป็นพัก ๆ เพราะความสะดวกของการตั้งค่าอย่าง LSP และปลั๊กอิน แต่เพราะมือคุ้นกับ vi/vim มากเกินไป เลยเปลี่ยนได้ไม่ง่ายนัก