วิธีใช้ Helix Editor เป็นตัวแก้ไขสำหรับพัฒนาบนเซิร์ฟเวอร์ระยะไกล

 (rushter.com)
7 คะแนน โดย GN⁺ 2025-10-14 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เหตุผลที่เลือก Helix เป็นตัวแก้ไขสำหรับพัฒนาบนเซิร์ฟเวอร์ระยะไกล คือสามารถใช้งานได้โดยไม่ต้องติดตั้งปลั๊กอินนับสิบแบบ Vim/Neovim และช่วยลดความเสี่ยงจากการโจมตีซัพพลายเชน
  • ผ่าน การตั้งค่าเชื่อมต่อกับ tmux เพื่อชดเชยความสามารถด้าน file explorer และ Git TUI ที่ Helix ยังขาดอยู่ โดยตั้งให้สามารถเรียกใช้ตัวจัดการไฟล์ yazi, lazygit และอื่น ๆ แบบป๊อปอัปได้
  • ย้าย คีย์ไบน์ดิงสไตล์ Vim มาใช้ เพื่อให้การเลือกบรรทัด การเลื่อนเคอร์เซอร์ การลบข้อความ ฯลฯ ทำงานคล้าย Vim และเปลี่ยนให้ ESC ใช้รีเซ็ตมัลติเคอร์เซอร์
  • เพิ่มข้อมูลอย่าง Git branch, encoding, position ลงใน statusline เพื่อเพิ่มประสิทธิภาพการทำงาน
  • ใช้ Tree-sitter injection เพื่อทำ syntax highlighting ให้กับ SQL query ภายใน Python/Go, code block ใน Markdown ฯลฯ ช่วยให้อ่านง่ายขึ้น
  • ใช้ การตั้งค่าขั้นสูง เช่น LSP, auto-save, color mode เพื่อเพิ่มประสิทธิภาพและปรับแต่งได้ละเอียด

ที่มาของการเลือก Helix

  • จากการเพิ่มขึ้นของ การโจมตีซัพพลายเชน และปัญหาการพึ่งพาปลั๊กอิน จึงเลือกใช้ Helix แทน Vim/Neovim เป็นตัวแก้ไขสำหรับพัฒนาบนเซิร์ฟเวอร์ระยะไกล
  • ข้อดีหลักคือ ใช้งานได้ด้วยความสามารถพื้นฐานที่มีมาให้ โดยไม่ต้องมีปลั๊กอินของ Neovim นับสิบตัว
  • หลังจากย้ายมาใช้ Helix ก็ได้ทำ การปรับแต่งการตั้งค่า เพื่อจำลอง ประสบการณ์แบบ Neovim ที่คุ้นเคยให้ได้มากที่สุด
  • นำมาแชร์เพื่อช่วยให้ผู้ใช้อื่นประหยัดเวลา

การตั้งค่า Tmux

  • ใช้ Tmux เป็น terminal multiplexer และเพิ่มคีย์ไบน์ดิงแบบกำหนดเองเพื่อแก้ปัญหา การไม่มี file manager และ Git TUI
  • Helix ไม่รองรับการแก้ไขไฟล์จาก file explorer ทำให้ไม่สะดวกเมื่อจำเป็นต้องสลับไปมาระหว่างหลายไฟล์อย่างรวดเร็ว
  • เพิ่ม binding ต่อไปนี้ในไฟล์ตั้งค่า Tmux
    • prefix - y: เรียก Yazi file manager เป็นหน้าต่างป๊อปอัป (ขนาด 95% ของหน้าจอ)
    • prefix - g: เรียก Lazygit เป็นหน้าต่างป๊อปอัป
    • prefix - e: เปิด ประวัติ output ของ Tmux ใน Helix เพื่อค้นหาและคัดลอก
  • prefix เริ่มต้นคือ Ctrl + b แต่เปลี่ยนมาใช้ Ctrl + \
  • มีประโยชน์กับงานที่เกี่ยวกับ output ในเทอร์มินัล โดยเฉพาะเวลาคัดลอก output ของ ClickHouse client (CSV/JSON) ไปยัง Slack
    • คัดลอกได้โดยตรงแทนการส่งออกเป็นไฟล์ ช่วยลดจำนวนขั้นตอน
    • แม้จะใช้เมาส์ได้ แต่การเลื่อนดูบัฟเฟอร์ของ Tmux ไม่สะดวก จึงจัดการผ่าน editor จะมีประสิทธิภาพกว่า
  • โดยทั่วไป Yazi และ Lazygit จะแสดงเป็น overlay อยู่เหนือ Helix editor

การย้ายคีย์ไบน์ดิงแบบ Vim

  • แม้จะคุ้นกับคีย์ไบน์ดิงของ Helix แล้ว แต่ก็ยังคง ย้าย Vim binding บางส่วน มาใช้
  • Binding ในโหมด Select
    • 0: ย้ายไปต้นบรรทัด
    • $: ย้ายไปท้ายบรรทัด
    • ^: ย้ายไปยังอักขระแรกที่ไม่ใช่ช่องว่าง
    • G: ย้ายไปท้ายไฟล์
    • D: เลือกจนถึงท้ายบรรทัดแล้วลบ จากนั้นสลับไปโหมด Normal
    • k/j: เลือกทั้งบรรทัดขึ้น/ลง (พฤติกรรมเริ่มต้นของ Helix เป็นการเลือกบางส่วน จึงไม่สะดวก)
  • Binding ในโหมด Normal
    • D: ลบข้อความทั้งหมดทางขวาของเคอร์เซอร์ (ย้ายมาจาก Vim เพราะ Helix ต้องกดหลายครั้งเกินไป)
    • V: สลับไปโหมด Select แล้วเลือกทั้งบรรทัด
    • ESC: รีเซ็ตมัลติเคอร์เซอร์ (ค่าเริ่มต้นของ Helix คือเครื่องหมายจุลภาค ซึ่งไม่สะดวก)
  • ไม่ชอบวิธีเลือกบรรทัดของ visual mode ใน Helix จึง เปลี่ยนให้เป็นสไตล์ Vim
    • ตั้งค่าให้เมื่อเลื่อนขึ้น/ลง จะเลือกทั้งบรรทัด

แถบสถานะที่ปรับปรุงแล้ว

  • แถบสถานะเริ่มต้นขาดข้อมูลสำคัญอย่าง Git branch ปัจจุบัน
  • องค์ประกอบของการตั้งค่าแถบสถานะ
    • ซ้าย: โหมด, spinner, version control, ชื่อไฟล์, สถานะอ่านอย่างเดียว, สถานะแก้ไขแล้ว
    • กลาง: ว่าง
    • ขวา: diagnostics, diagnostics ของ workspace, ตำแหน่ง, จำนวนบรรทัดทั้งหมด, เปอร์เซ็นต์ตำแหน่ง, file encoding, รูปแบบ line ending, file type, register, จำนวนที่เลือก
    • ตัวคั่น: ใช้อักขระ │
  • ทำให้ มองเห็นสถานะการทำงานได้ในพริบตา

คีย์ไบน์ดิงที่มีประโยชน์

  • คีย์ไบน์ดิงแบบกำหนดเองช่วย เพิ่มประสิทธิภาพการทำงานได้มาก แต่ใช้เวลาพอสมควรกว่าจะค้นพบ
  • ฟังก์ชันที่มีประโยชน์ที่สุดคือ reload file, toggle soft wrap, Git undo, Git blame, Git diff
  • รายการ custom binding ทั้งหมด
    • space - e - w: บันทึกบัฟเฟอร์ปัจจุบันเป็นไฟล์
    • space - e - c: ปิดบัฟเฟอร์ปัจจุบัน
    • space - e - x: ปิดบัฟเฟอร์อื่นทั้งหมด (มีประโยชน์เมื่อเปิดหลายสิบบัฟเฟอร์)
    • space - e - l: สลับการแสดง inlay type hint (มีประโยชน์ แต่ถ้าแสดงตลอดจะรบกวนสายตา)
    • + - f: format ไฟล์ปัจจุบัน
    • + - w: เรนเดอร์อักขระช่องว่าง (ใช้ตรวจดูอักขระที่มองไม่เห็นในเอกสาร)
    • + - W: ปิดการเรนเดอร์อักขระช่องว่าง
    • space - f - .: แสดง/ซ่อนไฟล์ที่ถูก Git ignore ใน file picker
    • space - f - r: reload ทุกไฟล์ (มีประโยชน์มากเพราะ Helix ยังไม่รองรับ auto reload ใช้สำหรับอัปเดตการเปลี่ยนแปลงจากภายนอกหรือ gutter หลัง commit)
    • space - f - x: undo การเปลี่ยนแปลง Git ที่ตำแหน่งเคอร์เซอร์ปัจจุบัน
    • space - f - w: แสดง Git blame ของบรรทัดปัจจุบัน
    • space - f - d: แสดง Git diff

การตั้งค่า editor

  • หลังใช้งานมา 6 เดือน จึงพบว่ามีฟังก์ชัน auto-save เมื่อสลับแท็บเทอร์มินัล
  • ฟีเจอร์ใหม่บางอย่างของ Helix ถูก ปิดไว้เป็นค่าเริ่มต้น เพื่อหลีกเลี่ยงไม่ให้ผู้ใช้เดิมเจอการเปลี่ยนแปลงที่ไม่คาดคิด
  • จึงต้องตรวจดูแต่ละตัวเลือกเองถึงจะพบฟีเจอร์ใหม่
  • ตัวเลือกการตั้งค่าหลัก
    • line-number = "relative": แสดงเลขบรรทัดแบบสัมพัทธ์
    • rulers = [120]: ตั้งค่า เส้นไกด์แนวตั้งแบบมองเห็นได้ (มีประโยชน์เมื่อจำกัดความยาวบรรทัดสูงสุดโดยไม่ใช้ auto format)
    • true-color = true: บังคับรองรับ true color
    • completion-replace = true: auto-complete จะแทนที่ทั้งคำ
    • trim-trailing-whitespace = true: ลบช่องว่างท้ายบรรทัด
    • color-modes = true: แยกการแสดงโหมดด้วยสี
    • rainbow-brackets = true: ใช้สีต่างกันกับวงเล็บซ้อนกัน (ฟีเจอร์ใหม่ ยังไม่ออกเป็น release อย่างเป็นทางการ)
    • editor.file-picker.hidden = false: แสดงไฟล์ซ่อน (dot files) ใน file picker
    • editor.indent-guides.render = true: เพิ่ม เส้นไกด์การย่อหน้าแบบมองเห็นได้
    • editor.inline-diagnostics.cursor-line = "warning": ปรับปรุงการแสดง diagnostics (ดูภาพหน้าจอประกอบ)
    • editor.auto-save.focus-lost = true: บันทึกอัตโนมัติเมื่อเสียโฟกัส (ต้องมีการรองรับจากเทอร์มินัล)
    • editor.auto-save.after-delay.enable = true: บันทึกอัตโนมัติหลังหน่วงเวลาที่กำหนด (ตั้งไว้ที่ 300 วินาที)

การปรับ LSP

  • เพิ่ม harper-ls LSP ให้กับทุกภาษา เพื่อทำ highlight ข้อผิดพลาดทางไวยากรณ์ในคอมเมนต์

Tree-sitter injection แบบกำหนดเอง

  • Helix อนุญาตให้กำหนด Tree-sitter injection แบบกำหนดเอง เพื่อทำ highlighting ภาษาหนึ่งภายในอีกภาษาหนึ่งได้
  • กรณีการใช้งาน
    • ทำ syntax highlighting ให้กับ SQL query ภายใน Python และ Go
    • ทำ highlighting ให้กับ YAML front matter และ code block ใน Markdown
    • ใช้กับการทำ highlighting ของ HTML snippet ได้เช่นกัน
  • อัปโหลด ไฟล์ตั้งค่าไว้บน GitHub เพื่อแชร์ custom injection และการตั้งค่า
  • Helix คือเทอร์มินัลเอดิเตอร์รุ่นใหม่ที่โดดเด่นด้าน การลดการใช้ปลั๊กอิน ความปลอดภัย และการปรับแต่งที่ตรงไปตรงมา

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

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

 
xguru 2025-10-14

นักพัฒนาที่ใช้ Vim มา 20 ปี เล่าประสบการณ์ ย้ายจาก Vim ไปใช้ Helix
 
GN⁺ 2025-10-14
ความคิดเห็นจาก Hacker News

  • ช่วงนี้กำลังจัดเซ็ตอัปเอดิเตอร์ใหม่อีกครั้ง ใช้ Emacs มา 20 ปี และ Vim ควบคู่มา 15 ปีแล้ว แต่ก็ยังเลือกไม่ได้ว่าจะเอาตัวไหนดี เป้าหมายคืออยากดูว่าจะทำเซ็ตอัปที่พร้อมใช้กับงานซอฟต์แวร์ Python ระดับองค์กรได้เร็วแค่ไหน รอบนี้โดยเฉพาะกำลังลองลดการพึ่งพาส่วนขยายจากบุคคลที่สามให้มากที่สุด และเหลือไว้เฉพาะฟังก์ชันที่จำเป็น ตอนนี้คิดว่าเซ็ตอัป Neovim ของตัวเองดีที่สุดเท่าที่เคยใช้มา แต่ก็ลงเอยด้วยการใช้ปลั๊กอินมากกว่าที่คาดไว้ ส่วนฝั่ง Emacs ยังอยู่ช่วงต้น ๆ แต่ก็น่าสนใจที่ตั้งแต่เวอร์ชัน 30 ขึ้นไป มันพัฒนาไปมากจนความจำเป็นในการใช้ปลั๊กอินภายนอกลดลงเยอะ เมื่อก่อนเคยใช้ lsp-mode แต่ตอนนี้พอใจกับ Eglot แล้ว completion preview mode แม้จะยังแทน corfu ได้ไม่หมด แต่ก็ถือว่าดีพอสมควร รายชื่อปลั๊กอินจำเป็นของ Emacs สำหรับฉันคือ Magit, Expreg(teeesitter expand region), Multiple cursors, dape(ดีบักที่ทำงานร่วมกับ Eglot) และคงจะเพิ่ม Consult กับ orderless ด้วย เซ็ตอัป Neovim ของฉันดูได้ที่นี่

    • nvim รุ่นใหม่ ๆ ก็กำลังลดความจำเป็นของปลั๊กอินลงเรื่อย ๆ เช่นกัน มีทั้งตัวจัดการปลั๊กอิน, diff viewer และ lsp ในตัว

    • คุณดูแลปลั๊กอิน nvim อยู่เยอะพอสมควรเลย! อาทิตย์ก่อนผมเพิ่งเขียนเซ็ตอัป nvim ใหม่โดยใช้ปลั๊กอินแค่ 4 ตัวรวม mini.nvim ด้วย รู้สึกเลยว่าพอใส่ปลั๊กอินเยอะ ๆ แล้วความเสถียรและความน่าเชื่อถือของ nvim ลดลงชัดเจน อิจฉาที่ฝั่ง Emacs ต้องใช้แค่ 2 ตัว และก็ดูเหมือนว่าจะเสถียรกว่ามาก เซ็ตอัปของผมดูได้ที่นี่

    • อยากรู้ว่าหลังจากใช้ไปหลายเดือนแล้ว คุณยังคิดอยู่ไหมว่ามันได้ประสบการณ์ใกล้เคียงกับเซ็ตอัปที่มีมาให้ของ Pycharm+IdeaVIM แน่นอนว่าการได้ปรับแต่งเองก็สนุก แต่ถ้าโฟกัสแค่เรื่องใช้ IDE ให้มีประสิทธิภาพ การทุ่มเวลาให้กับการตั้งค่า Neovim เยอะ ๆ มันก็ดูไม่ค่อยคุ้มเท่าไรไม่ใช่หรือ

    • Expreg(teeesitter expand region) ทำให้นึกถึง combobulate (ยังไม่เคยใช้ แต่ดูน่าสนใจมาก) เพียงแต่ Expreg ดูเรียบง่ายและเบากว่ามาก

    • อยากฟังประสบการณ์จากผู้ใช้ Emacs รุ่นเก๋าจริง ๆ มาก ว่าเทียบกับ Helix/Vim แล้วเป็นยังไง คนที่เพิ่งลอง Helix/Vim มักจะบอกว่าดี แต่ดูเหมือนจะยังไม่รู้คุณค่าที่แท้จริงของการใช้ Emacs มานาน ๆ เอาจริง ๆ คีย์สไตล์ Vim กับระบบโหมดต่าง ๆ ก็ดูจะถูกรวมเข้ากับเอดิเตอร์สมัยใหม่ได้ดีกว่า แต่พอลองใช้จริง ผมกลับไม่มีความอดทนพอจะรอให้มือชิน อยากฟังเรื่องราวการย้ายค่ายจากผู้ใช้ Emacs สาย hardcore จริง ๆ

  • ฉันเป็นคนที่ย้ายจาก Emacs → VS Code → Helix จนถึงตอนนี้ก็พยายามเรียนรู้คีย์ไบน์ดิงเดิมให้มากที่สุด และใช้งานให้มีประสิทธิภาพโดยแทบไม่แตะการตั้งค่าเลย การจำทุกอย่างที่ Helix ทำได้มันยาก เลยลองทำ deskmat สำหรับวางบนโต๊ะโดยพิมพ์คีย์ต่าง ๆ ลงไป น่าจะต้องลองพิมพ์ใช้งานจริงก่อนถึงจะรู้ว่าช่วยได้แค่ไหน deskmat ของฉันดูได้ที่นี่

    • อยากรู้ว่าใช้ Emacs มานานแค่ไหน

  • ผมใช้ Emacs เป็นตัวหลักมาตลอด 10 ปีที่ผ่านมา และก่อนหน้านั้นใช้ Sublime Text สำหรับการแก้ไฟล์ง่าย ๆ หรือบนเซิร์ฟเวอร์ระยะไกลก็มีใช้ Vim บ้างเป็นครั้งคราว แต่ไม่เคยรู้สึกว่าจำเป็นต้องใช้ Vim เพียงอย่างเดียวแบบเต็มตัว ผมสร้างโมดูลและฟังก์ชันของตัวเองใน Emacs เพื่อให้ได้สภาพแวดล้อมที่เข้ามือ พอเดือนก่อนลองใช้ Helix ก็รู้สึกว่าเริ่มต้นได้ง่ายอย่างน่าประหลาด แม้แต่การใช้งานพื้นฐาน—การย้ายตำแหน่ง, ค้นหา, วาง, สลับบัฟเฟอร์/หน้าต่าง—ก็ปรับตัวได้เร็ว ผมไม่ค่อยรู้ประวัติของ Helix เท่าไร แต่ดีไซน์มันยอดเยี่ยมมาก การค้นหาแบบ global ดีมาก การเชื่อมกับ lsp ก็ทำงานได้ลงตัว และยังเร็วมากจริง ๆ ความรู้สึกที่ว่าค่าเริ่มต้นต่าง ๆ ถูกกำหนดมาอย่างสม่ำเสมอและใช้งานได้จริงนั้นสบายมาก ผมตั้งใจจะใช้มันต่อไปเรื่อย ๆ เพื่อให้คุ้นเคยขึ้น แม้เอดิเตอร์หลักจะยังเป็น Emacs แต่ Helix เร็วมากจนคิดว่าน่าจะกลายเป็นเอดิเตอร์หลักสำหรับงานเขียนโค้ดได้

  • ผมเพิ่งเริ่มใช้ Helix และมีข้อเสียอยู่สองอย่างที่รู้สึกได้ชัด

    • มันยึด modal editing เป็นแกนหลัก แต่ Vim ทำให้ใช้ muscle memory เดิมได้แทบทุกที่ (โหมด Vim มีอยู่เกือบทุกที่ มีส่วนขยายอย่าง Vimium เยอะ และถ้าเป็นสภาพแวดล้อม ssh ก็มักจะมี Vim อยู่แทบแน่นอน)
    • Helix เน้นความเรียบง่ายเลยไม่มี terminal integration และก็ไม่ได้เปิดให้ขยายด้วยปลั๊กอินมากนัก (แม้แต่ฟังก์ชัน lint ก็รองรับแค่แบบอิง lsp) ซึ่งพอรวมกันแล้วก็ดูเหมือนว่าต้องไปประกอบเซ็ตอัปชั้นบนเองต่างหาก เลยเห็นว่ามีข้อจำกัดอยู่ (ต้องอาศัย tmux อะไรแบบนั้น) ไม่ได้จะตำหนิข้อเสียพวกนี้ แต่อยากรู้ว่ามีจุดแข็งอะไรที่มากพอจะชดเชยได้

    • ผมไม่ค่อยเข้าใจว่าทำไม LSP ถึงเป็นข้อเสีย ความรู้สึกคือ LSP รันเป็นโปรเซสแยก ซึ่งกลับดีต่อการ sandbox ปลั๊กอินด้วยซ้ำ จริง ๆ แล้วอาจทำงานได้ดีกว่าปลั๊กอินของเอดิเตอร์แบบดั้งเดิมเสียอีก ส่วนเรื่องไม่มี tmux integration ผมเองแม้จะใช้ Emacs เป็นหลัก แต่แทบไม่เคยใช้ terminal ภายในเลย จึงไม่รู้สึกอะไร ถ้าแค่ย้าย muscle memory แล้วได้เอดิเตอร์ที่เร็วและเขียนด้วย rust สำหรับผมก็ถือว่าน่าเลือกมากพอแล้ว

    • มีคนชอบบอกว่า motion ของ Vim ใช้เป็น muscle memory ได้ทุกที่ แต่ในความเป็นจริงแทบไม่มีนักพัฒนาคนไหนอยากใช้สภาพแวดล้อม Vim เปล่า ๆ แบบไม่มีปลั๊กอินหรือการตั้งค่าเลย คนส่วนใหญ่อยากได้เอดิเตอร์ที่ปรับสภาพแวดล้อมและฟีเจอร์ให้ตรงใจตัวเองอย่างละเอียด ข้อยกเว้นก็อาจมีแค่คนที่ ssh เข้าเครื่องหลายเครื่องจริง ๆ และจำเป็นต้องใช้สภาพแวดล้อมเอดิเตอร์พื้นฐานเท่านั้น เรื่องที่บอกว่า Helix เรียบง่ายและขยายด้วยปลั๊กอินได้น้อยนั้น เดิมที Helix ตั้งใจจะเป็นเอดิเตอร์แบบ all-in-one แต่ชุมชนไม่ต้องการแบบนั้น จึงกำลังพัฒนาระบบปลั๊กอินอยู่ แม้ยังไม่รวมในรีลีสหลัก แต่ใน branch แยกก็มีปลั๊กอินหลายตัวที่สร้างและใช้งานกันแล้ว ผมคิดว่าการเลื่อนรีลีสออกไปจนกว่าระบบปลั๊กอินจะเสถียรพอนั้นเป็นการตัดสินใจที่ถูกต้อง จุดแข็งที่สุดของ Helix คือมันแก้ UX ที่ยังอึดอัดใน vi/vim/neovim ได้ กล่าวคือมันสลับลำดับการทำงาน ทำให้ดูสิ่งที่เปลี่ยนไปก่อน commit ได้ง่าย ลดผลข้างเคียงที่ไม่ได้ตั้งใจ

  • ระดับการตั้งค่าแบบนี้ ผมว่ากลับไปใช้ vim ตรง ๆ น่าจะดีกว่า เหมือนกำลังพยายามจำลองฟังก์ชันของ vim ใน Helix และ Helix เองก็มี dependency ภายในเยอะเหมือนกัน (แค่ไม่เห็นบนผิวหน้าแบบ nvim) เซ็ตอัป vim8 ของผมคงความเรียบง่ายมาเกิน 8 ปีแล้ว เหตุผลที่ใช้ vim8 ก็เพราะมันเป็นเวอร์ชันที่มีอยู่ในดิสโทร LTS ปลั๊กอินที่โหลดอัตโนมัติมีแค่ตัวเดียว (vim-tmux-navigator เอาไว้ย้ายระหว่างหน้าต่างแยกของ vim กับ tmux ได้ง่าย) ผมตรวจโค้ดแล้วและก็ไม่อัปเดตมันด้วย ส่วนปลั๊กอินแบบ "เลือกใช้" อีกสองตัว จะเปิดเฉพาะเวลาจำเป็นผ่านตัวจัดการแพ็กเกจในตัวของ vim ด้วย :packadd! เท่านั้น ใช้แค่ ale(lsp, diagnostics, auto format ตอนบันทึก) กับ vim-fugitive(git integration) โดย ale ไม่มี dependency ส่วน vim-fugitive ก็แค่ติดตั้งครั้งเดียวแล้วใช้ได้เลย เหตุผลที่ไม่โหลดปลั๊กอินอัตโนมัติก็เพราะปกติ vim ใช้เพื่อแก้ไขอย่างรวดเร็วเป็นหลัก และจะเปิด git/lsp เฉพาะตอนทำโปรเจกต์ระยะยาวเท่านั้น ปลั๊กอินที่ไม่จำเป็นก็ไม่ต้องใช้ก็ได้

    • ผมเองก็ชอบ modern Neovim เลยทำแพ็กเกจ Python ตัวหนึ่งขึ้นมาเพื่อแก้ปัญหานี้ (โดยเฉพาะสำหรับคนที่อยู่ใน ecosystem ของ python อยู่แล้ว หรือใช้ uv, pipx) ตอนนี้ติดตั้ง Neovim รุ่นล่าสุดได้ด้วย uv tool install binwheels-neovim หรือ pipx install binwheels-neovim และใช้งานได้ทันทีบน Windows, macOS, Linux แพ็กเกจนี้เป็น wrapper ของรีลีสทางการของ Neovim โดยใช้ uv หรือ pipx ดึงไบนารีให้ตรงกับระบบปฏิบัติการ/สถาปัตยกรรม สำหรับ Linux ต้องการรองรับ GLIBC ที่เก่ากว่ารีลีสทางการ ก็เลย build แยกและแจกให้ ดูข้อมูลเพิ่มได้ที่ PyPI, Github หลัก, บันทึกการ build

    • Helix มีพื้นที่เสี่ยงต่อ supply chain attack เล็กมากเมื่อเทียบกับ nvim+ปลั๊กอินต่าง ๆ เพราะ Helix ดูแลรวมอยู่ในตัวมันเอง ขณะที่ nvim มี vendor แยกตามปลั๊กอิน จึงปลอดภัยกว่ามาก อีกทั้ง Helix ยังออกรุ่นอย่างช้าและรอบคอบ ทำให้แม้มีช่องโหว่ก็มีโอกาสกลายเป็นปัญหาใหญ่ได้น้อย

    • โมเดลการแก้ไขข้อความของ Helix เหนือกว่ามาก

  • ถ้าต้องการ TUI ตอนใช้ Helix ก็สงสัยเหมือนกันว่าทำไมไม่ใช้ neovim ไปเลย ผมชอบค่าเริ่มต้นของ Helix นะ แต่พอถึงจุดหนึ่งที่ต้องเริ่มเปลี่ยนอะไรบางอย่าง ก็รู้สึกว่ามันเริ่มยุ่งขึ้นเรื่อย ๆ แล้วถ้าต้องการ 'ประสบการณ์แบบ IDE เต็มรูปแบบ' ใน Helix ก็ไม่ค่อยเข้าใจเหมือนกันว่าทำไมจะไม่ใช้ Zed, VSC หรือ JetBrains IDE ไปเลย ถ้าผมต้องการอะไรเรียบง่ายก็จะใช้ nvim แต่ถ้าต้องการฟังก์ชันมากขึ้นก็เปิด WebStorm หรือไม่ก็ใช้สิ่งนั้นร่วมกับเพื่อนร่วมงานเวลาต้องหาบางอย่าง

    • เวลาทำงานผ่าน ssh บนอุปกรณ์สเปกต่ำ helix เปิดแทบจะทันที ถ้าจะประกอบความสามารถใกล้เคียงกันใน nvim มันจะช้าลง และมีต้นทุนในการดูแลการตั้งค่ากับอัปเดตปลั๊กอินสูงขึ้น อีกอย่างผมรู้ rust เลยสามารถช่วยแก้บั๊กได้ด้วย ผมไม่รู้ภาษาในตระกูล c จึงชอบโปรเจกต์โอเพนซอร์สที่เขียนด้วยภาษาที่ตัวเองรู้ ผมเป็นคนเขียนโค้ดเป็นงานอดิเรกที่ใช้ n/vim มา 12 ปี แล้วเพิ่งย้ายมา helix ใน 2 ปีหลัง จริง ๆ ก็ยังมีหลายอย่างใน nvim ที่คิดถึงและบางอย่างก็ดูเป็นธรรมชาติกว่า แต่ helix มัน "เปิดแล้วใช้ได้เลย" จริง ๆ และความสบายแบบนั้นชนะทุกอย่าง

    • ตลอดไม่กี่ปีที่ผ่านมา ผมเคยลองใช้ neovim, helix, emacs, nano อย่างละช่วงหนึ่ง และประสบการณ์แบบ out-of-the-box ของ helix นั้นดีที่สุดแบบทิ้งห่าง ค่าเริ่มต้นตั้งมาได้ดีมาก และมีวิธีช่วยเหลือตามบริบทกับ hint ที่ยอดเยี่ยม ทำให้ไม่จำเป็นต้องจำคำสั่งที่ใช้บ่อยทั้งหมด และคำสั่งที่ใช้นาน ๆ ครั้งก็หาเจอได้ง่าย อีกอย่างหนึ่งคือในหัวของผม ลำดับการทำงานของคำสั่งใน helix มันดูเป็นธรรมชาติกว่า vim เอดิเตอร์ยุคนี้อย่าง nvim/spacemacs มีอุปสรรคเรื่องปลั๊กอิน/การตั้งค่าสูงเกินไป แม้ ecosystem ของปลั๊กอินจะทำให้ทำสิ่งที่ helix ยังทำไม่ได้ในตอนนี้ได้ (เช่น emacs สามารถใช้ภาษาในตระกูล lisp ไหนก็ได้แบบ IDE แต่ helix ยังโหลด repl ไม่ได้) แต่นั่นก็หมายความว่าไม่ใช่แค่ต้องเรียนรู้ตัวเอดิเตอร์เอง ยังต้องเรียนรู้ปลั๊กอินอีกมากมายด้วย และพอค้นหาข้อมูล คำตอบก็สับสนเพราะต่างกันไปตามเวอร์ชัน/ชุดการตั้งค่า สุดท้ายเวลาจะเริ่มใหม่ก็มักต้องเชื่อคำแนะนำของคนอื่น หรือไม่ก็เสียเวลาเพิ่มไปกับการลองเองและเรียนรู้เอง Helix เป็นโปรเจกต์ใหม่ จึงไม่มีภาระจากการตัดสินใจสมัยเก่า และสามารถเลือกการตัดสินใจรวมถึงค่าเริ่มต้นที่เข้ากับรูปแบบการพัฒนาสมัยใหม่ได้ ถึงจะไม่สมบูรณ์แบบ แต่ถ้าจะให้แนะนำอะไรสักตัวสำหรับคนเริ่มต้นกับ TUI ที่อยากได้ของที่ใช้ได้ทันทีและเริ่มได้ง่ายโดยไม่ต้องตั้งค่า ผมก็อยากแนะนำ helix

    • hx ทั้งเริ่มต้นและทำงานได้เร็ว แถมยังสวยอีกด้วย ค่าเริ่มต้นก็น่าพอใจมากจนผมแก้นิดหน่อยก็พอ และต่างจาก emacs/neovim ที่ผมมักจมอยู่กับ endless improvement loop, hx ให้ความรู้สึกว่ามันมีจุดจบให้ถึง TUI ก็ทำงานได้ดีบนเซิร์ฟเวอร์ระยะไกลด้วย ทำให้ผมใช้สภาพแวดล้อมเดียวกันได้ทั้งบน mac, linux และเซิร์ฟเวอร์ (เอดิเตอร์อื่นก็ทำได้เหมือนกัน แต่ hx ก็รองรับได้ดี) lsp ที่ต้องใช้ก็รองรับครบ แม้การตั้งค่า languages.toml จะยุ่งนิดหน่อย แต่เอดิเตอร์อื่น ๆ ก็ไม่ต่างกัน

    • ผมชอบการตั้งค่าที่เรียบง่าย และชอบ selection-first editing model ด้วย มีเอกสารอ้างอิงเกี่ยวกับเรื่องนี้อยู่ที่นี่ พอคุยกับคนที่ปรับตัวกับ Vim ยาก ก็เลยรู้สึกว่าจริง ๆ แล้วผมน่าจะคุ้นกับโมเดลแบบ Helix ที่ "เลือกก่อน" มาตั้งแต่แรก การทำงานแบบ Vim ที่ไม่เห็นข้อความเป้าหมายก่อน (คือเห็นขอบเขตที่ได้รับผลหลังสั่งคำสั่งแล้ว) สำหรับผมนั้นปรับตัวยาก

    • การเลือกเอดิเตอร์ไม่ใช่การตัดสินใจที่มีเหตุผลล้วน ๆ มากนัก แต่มีปัจจัยทางจิตวิทยาอย่างรสนิยม ความสดใหม่ หรือความสนุก เข้ามาเกี่ยวมากกว่าเยอะ

  • เพิ่งรู้จักคำสั่ง :reset-diff-change เป็นครั้งแรก ปกติผมใช้แค่ checkout -p ใน git มาตลอด แต่ทำจากใน Helix ได้เลยสะดวกกว่ามาก

  • ผมลองใช้ Helix และฝึกปรับตัวอย่างจริงจังจนตอนนี้ใช้ได้คล่องแล้ว แต่กลับค้นพบว่า "workflow แบบย้อนลำดับ" นี้ แม้จะเรียนรู้ง่ายและทำให้พัฒนาได้ง่าย ทว่าพอใช้จริงกลับช้าลง สุดท้ายเลยกลับไปใช้ Vim แล้วก็ Zed(Vim mode) อีกครั้ง

  • วันนี้เพิ่งลอง Helix ครั้งแรก มันเป็นเอดิเตอร์ที่ออกแบบมาดีมากจริง ๆ แต่ก็ยังเสียดายที่ไม่มีคีย์ลัดทำงานเร็วแบบ Vim อย่าง y2$, dw

    • จริง ๆ ไม่ได้ไม่มีคีย์ลัดนะ แค่ y2$ ใช้เป็น 2xy และ dw ใช้เป็น wd

  • ผมยังหาวิธีลบบรรทัดปัจจุบันใน Helix แบบรวมบรรทัดว่างด้วยไม่เจอเลย "xd" จะลบหนึ่งบรรทัดถ้าเป็นบรรทัดที่ไม่ว่าง แต่ถ้าเป็นบรรทัดว่างจะกลายเป็นลบสองบรรทัดพร้อมกัน

    • x คือเลือกบรรทัดปัจจุบัน และถ้าเลือกอยู่แล้วจะขยายไปยังบรรทัดถัดไป ส่วน X คือขยายการเลือกไปยังขอบเขตของบรรทัด (line-wise selection) ใช้ X ได้เลย

    • ถ้าเป็นบรรทัดว่าง ก็ใช้แค่ "d"

    • แอบน่ารำคาญอยู่เหมือนกัน ผมเองก็ใช้ trivial fork ที่เปลี่ยนพฤติกรรมของ x บนบรรทัดว่างให้ต่างออกไป รายละเอียดดูได้ในPR นี้