สถานะของเทอร์มินัลอีมูเลเตอร์ในปี 2025: แชมเปียนผู้ท่องไป
(jeffquast.com)- นำเสนอผลการประเมินปี 2025 ที่เปรียบเทียบเทอร์มินัลอีมูเลเตอร์หลักโดยใช้ ความแม่นยำในการรองรับ Unicode และ ประสิทธิภาพ เป็นเกณฑ์
- Ghostty เป็นเทอร์มินัลตัวใหม่ที่พัฒนาขึ้นด้วย Zig และทำคะแนนสูงสุด พร้อมทั้ง ใช้งานการจัดการ Unicode ที่แม่นยำ
- Kitty ได้คะแนนใกล้เคียงกับ Ghostty และเผยแพร่ อัลกอริทึมการแบ่งข้อความ เพื่อช่วยผลักดันการทำมาตรฐาน
- เทอร์มินัลจำนวนมากแสดงปัญหา ประสิทธิภาพตกต่ำ และ การรองรับ DEC Private Mode ไม่สอดคล้องกัน โดยเฉพาะเทอร์มินัลที่อิง VTE ซึ่งไม่มีความคืบหน้า
- การมาถึงของ โปรโตคอลข้อความความกว้างแปรผัน ชี้ให้เห็นความเป็นไปได้ในการ เพิ่มความอ่านง่าย ของหลายภาษา โดยก้าวข้ามข้อจำกัดของเซลล์ความกว้างเดี่ยว
- Errant Champions (เหล่าแชมเปียนผู้ท่องไป) : ผู้ท้าชิงอย่าง Ghostty และ Kitty ที่ไม่ยึดติดกับข้อกำหนดแบบดั้งเดิม แต่กลับมาออกแบบปัญหาความกว้างตัวอักษร การเรนเดอร์ และ Unicode ของเทอร์มินัลใหม่ตั้งแต่รากฐาน
เครื่องมือ ucs-detect และภาพรวมการทดสอบ
- เป็นงานต่อเนื่องจาก การทดลองเปรียบเทียบการรองรับ Unicode ที่เผยแพร่ในปี 2023 โดยเครื่องมือ
ucs-detectได้เพิ่มความสามารถในการตรวจจับ DEC Private Modes, กราฟิก sixel, ขนาดพิกเซล และ เวอร์ชันซอฟต์แวร์- เครื่องมือนี้จะส่งลำดับควบคุมตำแหน่งเคอร์เซอร์ และเปรียบเทียบการตอบสนองของเทอร์มินัลกับผลลัพธ์ของ Python wcwidth เพื่อบันทึกความไม่ตรงกัน
- การทดสอบนี้ใช้ตรวจสอบ ความแม่นยำของการคำนวณความกว้างอักขระ ของแต่ละเทอร์มินัล และแปลงผลลัพธ์เป็นค่าตัวเลขของคุณภาพการรองรับ Unicode
ปัญหาความกว้างอักขระ (The Width Problem)
- เทอร์มินัลมีข้อจำกัดเชิงโครงสร้างที่ต้องแสดงอักขระ Unicode หลากหลายชนิดภายใน กริดความกว้างคงที่
- อักขระประกอบ, ลำดับอีโมจิ, Zero-width joiner และสิ่งที่คล้ายกัน ทำให้การคาดเดาความกว้างอักขระล้มเหลวบ่อยครั้ง
- ความคลาดเคลื่อนเหล่านี้ทำให้เกิด ข้อผิดพลาดของตำแหน่งเคอร์เซอร์ และ เอาต์พุตเสียหาย รวมถึงทำให้ตำแหน่งป้อนข้อมูลบิดเบือนได้
- ผลการทดสอบช่วยระบุว่าเทอร์มินัลใดก่อปัญหาเหล่านี้น้อยที่สุด
Ghostty: ดาวรุ่งรายใหม่
- Ghostty เป็นเทอร์มินัลใหม่ที่เปิดตัวในปี 2025 และ พัฒนาขึ้นใหม่ทั้งหมดด้วยภาษา Zig
- ด้วยการรองรับ Unicode ที่ลงรายละเอียดอย่างจริงจัง จึงมีความแม่นยำสูงที่สุดและได้คะแนนสูงสุดในการทดสอบ
- ผู้พัฒนา Mitchell Hashimoto ได้ศึกษาหลักการพื้นฐานผ่านบทความ Grapheme Clusters and Terminal Emulators ในปี 2023
- libghostty ที่เพิ่งเปิดตัวใหม่อาจเป็นทางเลือกแทน libvte เดิม และมีศักยภาพในการมอบ รากฐานด้าน Unicode ที่แข็งแกร่ง ให้ระบบนิเวศของเทอร์มินัลในอนาคต
Kitty: แชมเปียนอีกราย
- Kitty ทำคะแนนได้เกือบเท่า Ghostty และได้เผยแพร่ อัลกอริทึมการแบ่งเซลล์ข้อความ
- อัลกอริทึมนี้สอดคล้องกับ ข้อกำหนดของ Python wcwidth และอิงกับการตีความมาตรฐาน Unicode
- มีเพียงสองเทอร์มินัลนี้เท่านั้นที่รองรับ Variation Selector 15 ได้อย่างถูกต้อง
- แม้ความสามารถนี้จะยังไม่ค่อยมีประโยชน์เชิงปฏิบัติมากนัก แต่มีแผนจะสะท้อนเข้าไปในมาตรฐานของ Python wcwidth ในอนาคต
สรุปการเปรียบเทียบประสิทธิภาพด้าน Unicode ของเทอร์มินัลอีมูเลเตอร์
- อันดับ 1 Ghostty, อันดับ 2 Foot, อันดับ 3 Kitty ครองกลุ่มบนสุด
- ทั้งสามเทอร์มินัลทำคะแนนสูงสุดในหัวข้อ ความแม่นยำของการจัดการ Unicode (WIDE/LANG/ZJW/VS16)
- Ghostty ได้ 100 คะแนนทุกหัวข้อ รวมเป็นคะแนนรวม 100 และ DEC Modes ก็เป็น enabled
- Kitty มีประสิทธิภาพช้ากว่าเล็กน้อย (Elapsed time 1748s) แต่ยังมีความแม่นยำระดับสูงสุด
- เทอร์มินัลที่อิง VTE (GNOME Terminal, Terminator, LXTerminal เป็นต้น) ยังคงอยู่กลุ่มล่าง
- ทั้งหมดได้ Final Scaled Score ไม่เกิน 5 คะแนน และใช้เวลาทดสอบ 8000~18000 วินาที ซึ่งช้ามาก
- ไม่มีการปรับปรุงจากปี 2023
- ในด้าน ประสิทธิภาพ (Elapsed time) นั้น Foot, WezTerm, tmux, Konsole ทำได้เร็ว (ต่ำกว่า 100 วินาที)
- iTerm2, Extraterm ใช้ CPU สูงและค่อนข้างช้ามาก (มากกว่า 4000 วินาที)
- การรองรับกราฟิก sixel มีเฉพาะบางตัวแม้อยู่ในกลุ่มบน
- Ghostty, Kitty, Konsole, contour รองรับ
- GNOME Terminal และสาย VTE ส่วนใหญ่ไม่รองรับ
- เทอร์มินัลที่รองรับ Variation Selector 15(VS15) ได้อย่างถูกต้องมีเพียง Ghostty และ Kitty เท่านั้น
- ในแง่ความสมบูรณ์ของการจัดการ Unicode ทั้งสองโครงการแทบจะโดดเด่นอยู่เพียงลำพัง
การวิเคราะห์ประสิทธิภาพ (The Long Road)
- เทอร์มินัลจำนวนมากมี ประสิทธิภาพที่ช้ามาก จนการทดสอบต้องใช้เวลาหลายชั่วโมงกว่าจะเสร็จ
- iTerm2 และ Extraterm ใช้ CPU มากเกินไป จึงต้องลดเวลาทดสอบลง
- GNOME Terminal และ เทอร์มินัลที่อิง VTE แม้ใช้ CPU ต่ำ แต่ก็ยังใช้เวลามากกว่า 5 ชั่วโมง
- Python wcwidth แม้จะเป็นภาษาระดับสูง ก็ยังมีความเร็วใกล้เคียงกับเทอร์มินัลส่วนใหญ่
- เพื่อเพิ่มประสิทธิภาพ มีการทดลองใช้ บิตเวกเตอร์, Bloom filter, LRU cache เป็นต้น แต่พบว่าการผสม binary search + LRU cache มีประสิทธิภาพสูงสุด
- LRU cache มีประโยชน์เมื่อประมวลผลชุดอักขระที่เกิดซ้ำ
- มีการพิจารณาการเพิ่ม โมดูล C ด้วย แต่ในตอนนี้การใช้งาน Python เพียงอย่างเดียวก็ให้ประสิทธิภาพได้เพียงพอ
กรณีพิเศษและปัญหาที่พบ (Tilting at Edges)
- Terminology ให้ผลลัพธ์ต่างกันทุกครั้งที่รัน จึงอาจมีความเป็นไปได้ว่ามีสถานะภายในเสียหาย
- iTerm2 รายงานว่า DEC Private Mode ทั้งหมด “รองรับแต่ปิดใช้งานอยู่”
- Konsole ไม่ตอบคำถามสอบถาม แต่บางโหมดก็รองรับเมื่อเปิดใช้งาน
- Contour ตอบกลับด้วยหมายเลขโหมดที่ผิด ทำให้ถูกแสดงเป็น “ไม่รองรับ” และในรีลีสเดือนธันวาคม 2024 ยังเกิด ข้อผิดพลาดการตั้งค่าปุ่ม ESC
- เทอร์มินัลที่อิง VTE/7600 ยังคงได้คะแนนต่ำเหมือนปี 2023
- การถกเถียงเรื่องการปรับปรุง Unicode ใน โครงการ libvte ถูกวิจารณ์อยู่มาก แต่ ประเด็นการรองรับลำดับ Emoji ถูกมองว่าเป็นสัญญาณของการปรับปรุงในปี 2026
เกี่ยวกับ Mode 2027
- Mode 2027 แยกเพียงว่าเทอร์มินัลรองรับ Unicode หรือไม่ด้วยค่า “รองรับ/ไม่รองรับ” แต่ไม่สามารถบอกระดับรายละเอียดของความสามารถได้
- ในทางปฏิบัติ วิธีที่แม่นยำกว่าคือการทดสอบฟีเจอร์และโค้ดพอยต์แต่ละรายการโดยตรงแบบ ucs-detect
ก้าวข้ามความกว้างคงที่ (Beyond Fixed Widths)
- โครงสร้างเซลล์ความกว้างคงที่ทำให้ ความอ่านง่าย ของหลายภาษาลดลง
- โปรโตคอลการปรับขนาดข้อความ (text sizing protocol) เป็นแนวทางใหม่เพื่อแก้ปัญหานี้
- Kovid Goyal ของ Kitty อธิบายด้วยตัวอย่างว่า “อยากเห็นหัวข้อในไฟล์ Markdown ให้ใหญ่ขึ้น”
- ความสามารถนี้ชี้ให้เห็นถึงศักยภาพในการ เพิ่มการเข้าถึง และ ปรับปรุงความอ่านง่ายของสคริปต์อักขระที่ซับซ้อน
- ตัวอย่างการเปรียบเทียบการแสดงผลภาษา Khün ระหว่าง Contour กับ โปรแกรมแก้ไข Kate แสดงให้เห็นว่าการเรนเดอร์แบบความกว้างแปรผันให้ผลที่ชัดเจนกว่า
- มีการเสนอว่า โหมดความกว้างแปรผัน ที่เปิดให้เอนจินฟอนต์เรนเดอร์ข้อความได้โดยไม่ถูกจำกัดต่อเซลล์ จะเป็นทิศทางการพัฒนาในอนาคต
- การนำ โปรโตคอลขนาดข้อความ มาใช้ถูกประเมินว่าเป็นความคืบหน้าในการแก้ปัญหาเหล่านี้
15 ความคิดเห็น
ขอแนะนำ wezterm
ผมใช้ xshell กับ iterm2 อยู่ครับ.. ดูเหมือนว่าคงต้องลองตัวอื่นบ้างแล้ว
บน Mac กับ Linux ผมใช้ ghostty บ่อยมาก แต่บน Windows ดูเหมือนว่า wezterm จะดีที่สุดครับ
ในฐานะผู้ใช้ Windows
ผมลงตัวกับ cygwin terminal (mintty) + mosh อย่างสมบูรณ์แล้ว เหมือนไม่มีอะไรที่ขาดเลย.
ผมก็แค่ใช้ Windows Terminal ครับ
สุดท้ายก็กลับไปใช้ Gnome terminal อยู่ดี...
ถ้า Ghostty หรือ Kitty รองรับ Windows ด้วยก็คงดีมากเลยครับ T_T
ถ้าปรับแต่ง config ดี ๆ WezTerm ก็ถือว่าค่อนข้างใช้ได้เลยครับ (รองรับ Windows)
https://th.news.hada.io/topic?id=9270
ดูเหมือนว่า tabby จะไม่ค่อยอยู่ในกระแสนะครับ.. คงต้องลองใช้ ghostty ดูสักครั้งแล้ว
อ้า ghostty ยังไม่มีสำหรับ Windows สินะ;
เพราะมีโปรแกรม LLM CLI ให้ใช้งาน ภาษาต่าง ๆ นอกเหนือจากภาษาอังกฤษก็น่าจะถูกใช้ในเทอร์มินัลมากขึ้น
เมื่อมองในแง่นั้น ผมคิดว่าการรองรับ Unicode ของเทอร์มินัลอีมูเลเตอร์เป็นเรื่องสำคัญมากจริง ๆ
ถ้า ghostty มีแค่ฟังก์ชัน cmd+f เข้ามาก็คงจะสมบูรณ์แบบแล้วครับ พอไม่มีแล้วแอบใช้งานไม่สะดวกอยู่เหมือนกัน
แล้วก็ในตอนที่ split ไว้ ผมไม่รู้ว่าจะจะแยกอันนี้ออกเป็นหน้าต่างแยกต่างหากยังไง มีใครพอทราบไหมครับ T_T
อย่ามองข้าม alacritty นะ~~~
ความเห็นจาก Hacker News
ได้ลองใช้ Windows Terminal เป็นครั้งแรกเพราะงานที่บริษัท
พอได้ใช้หลังจากพัฒนาบน Linux มาทั้งชีวิต ก็รู้สึกว่า Ctrl+C, Ctrl+V ทำงานได้ฉลาดมาก
ตอนที่ไม่มีการเลือกข้อความ มันจะเป็นการหยุดโปรเซส แต่ถ้ามีการเลือกอยู่ก็จะกลายเป็นการคัดลอก และการวางก็ใช้ Ctrl+V ได้ตรงๆ เลย สะดวกมาก
แค่เลือกข้อความก็ถือว่าคัดลอกแล้ว และสามารถวางในหน้าต่างอื่นด้วย ปุ่มเมาส์กลาง
สิ่งนี้เรียกว่า Primary Selection และทำงานแยกจากคลิปบอร์ดปกติ (Ctrl+C/V) โดยส่วนตัวคิดว่าวิธีนี้สะดวกกว่า
สิ่งที่น่าสนใจก็คือ โปรแกรมที่เรามักเรียกว่า “terminal emulator” กันนั้น แท้จริงแล้ว ไม่ได้จำลองเทอร์มินัลอย่างสมบูรณ์
แต่ตอนนี้ทำได้แล้ว ดูได้จาก วิธีจำลอง VT102 จริงด้วย MAME
มันทำงานบน WSL ได้ด้วย และสามารถเชื่อม
socatกับmameเพื่อใช้งานเหมือนฮาร์ดแวร์เทอร์มินัลจริงเมื่อก่อนเคยอยากลองสร้าง อีมูเลเตอร์ VT220 ระดับสูง ที่เพิ่มการควบคุมเมาส์หรือฟีเจอร์วางข้อความสำหรับ VT220 พอมาเห็นโพสต์นี้ก็ทำให้นึกเรื่องนั้นขึ้นมาอีกครั้ง
ดีใจที่ Konsole ของ KDE ได้อันดับสูง
แม้จะเป็นเทอร์มินัลที่มีมาหลายสิบปีแล้ว แต่ก็ยัง แข่งขันด้านประสิทธิภาพ กับเทอร์มินัลสมัยใหม่ได้สบาย
ปรับแต่งได้อิสระ และก็เร็วเพียงพอ
สิ่งที่ชอบมากเป็นพิเศษคือใน Dolphin สามารถคลิกขวาแล้วเปิด Konsole ที่โฟลเดอร์ปัจจุบันได้ทันที
ฟีเจอร์ scrollback แบบไม่จำกัด ก็มีประโยชน์มาก ล็อกเก่าๆ จะถูกสลับไปเก็บเป็นไฟล์อัตโนมัติแทนที่จะหายทิ้ง
ตั้งคีย์ลัดล้างทั้งหมดไว้ที่ Ctrl+Shift+X แล้วใช้บ่อยมาก
เอกสารที่เกี่ยวข้องมี
ในรายการไม่มี DECterm
ตามที่เห็นได้จาก เอกสารภาพรวมของ DECterm มันเคยให้ การจำลอง VT220 ที่ดีที่สุดบน X Window System
มีเทอร์มินัลน้อยมากที่รองรับโหมดอักขระ “double wide” หรือ “double high, double wide” ของ VT100 ตัวอักษรยักษ์พวกนั้นสนุกดีมาก
ใช้ Alacritty มาได้ดีอยู่พักใหญ่ แต่พอลอง Ghostty เมื่อไม่นานนี้ก็ประทับใจมาก
มันมี ตัวเลือกธีมในตัว ที่มีประโยชน์มากเวลาใช้งานหลายเครื่อง
โดยรวมแล้วดูเหมือนจะเป็นทางเลือกที่ดีกว่า Alacritty นักพัฒนาทำออกมาได้ดีจริงๆ
ถึงจะพอเลียนแบบด้วย tmux ได้ แต่ก็ไม่เหมือนกันทั้งหมด
ถ้า Ghostty เพิ่มการรองรับ Windows ได้ก็น่าจะสมบูรณ์แบบ
อยากให้เทอร์มินัลสามารถ สอบถามได้ว่าฟอนต์รองรับรายการอักขระบางชุดหรือไม่
ถ้าเป็นแบบนั้น โปรแกรม TUI จะสามารถใช้ยูนิโค้ดใหม่ๆ หรือ อักขระ Private Use (เช่น powerline, ไอคอน font-awesome) ได้ และถ้าไม่รองรับก็จะแสดงอักขระทดแทนโดยอัตโนมัติ
น่าเสียดายที่มีการพูดถึง Windows Terminal น้อยไปหน่อย
ถึงฝั่ง Linux จะมี ecosystem ที่หลากหลายกว่า แต่ตอนนี้ WT ก็อยู่สูงกว่าเทอร์มินัล Linux หลายตัวมาก
นี่เป็นเรื่องที่เมื่อ 10 ปีก่อนนึกไม่ถึงเลย
อีกอย่าง บางครั้งก็กลับไปดู วิดีโอนี้ อีก เพราะชอบที่มี easter egg ซ่อนชื่อผู้พัฒนาไว้
ทั้งแท็บ ธีม และการเปลี่ยนชื่อหน้าต่างทำได้ยอดเยี่ยม ทำให้ดูออกได้ทันทีว่าแต่ละหน้าต่างใช้ทำอะไร
เทอร์มินัล Foot ก็ยอดเยี่ยมเหมือนกัน
ถึงจะรองรับเฉพาะ Wayland แต่ก็ เบาและเปิดได้เร็ว มาก ใช้ทรัพยากรน้อยด้วย
Ghostty ก็ดี แต่แค่เปิดเทอร์มินัลว่างๆ หนึ่งหน้าต่างก็ใช้ หน่วยความจำมากกว่ากันเกิน 10 เท่า
เทอร์มินัลมาตรฐานของ macOS ได้ อันดับ 29 ในผลครั้งนี้
ถึงอย่างนั้น เวอร์ชันล่าสุด (macOS 26) ก็รองรับ Powerline และสี 24 บิตแล้ว
Kitty ฟีเจอร์ดีอยู่แล้ว แต่ก็ดีใจที่มีทางเลือกอย่าง Ghostty เกิดขึ้นมา เพราะผู้ดูแลหลักเป็นคนน่าสมเพชเหลือเกิน
สุดท้ายก็กลับมาใช้ iTerm2