- ฟีเจอร์ การดีบัก ที่มีนักพัฒนากว่า 2,000 คนร้องขอ ถูกนำมาใช้งานใน Zed ในที่สุด
- ดีบักเกอร์ถูกออกแบบโดยเน้น ความเร็ว ความคุ้นเคย และการปรับแต่งได้
- รองรับภาษายอดนิยมอย่าง Rust, C/C++, JavaScript, Go, Python และส่วนขยายที่อิงตาม Debug Adapter Protocol (DAP)
- ระบบ LOCATORS ที่ใช้งานง่าย ช่วยให้ดีบักได้สะดวกในโปรเจกต์ส่วนใหญ่โดยแทบไม่ต้องตั้งค่าเพิ่มเติม
- สถาปัตยกรรมแบบ แยก UI และชั้นข้อมูล วางรากฐานที่แข็งแกร่งสำหรับการดีบักแบบทำงานร่วมกันและการขยายความสามารถ
การเปิดตัวดีบักเกอร์ของ Zed
- ตามคำขอของนักพัฒนากว่า 2,000 คน ได้มีการเพิ่มฟีเจอร์ การดีบัก อย่างเป็นทางการให้กับ Zed Editor ซึ่งนับเป็นความก้าวหน้าที่สำคัญมากสู่ Zed 1.0
เป้าหมายหลัก
- ความเร็ว: มอบการสลับบริบทที่รวดเร็วและประสบการณ์การดีบักที่มีประสิทธิภาพ
- ความคุ้นเคย: กลมกลืนกับภาษาการออกแบบของ Zed และรองรับทุกฟีเจอร์ที่คาดหวังจากลำดับการทำงานของดีบักเกอร์ทั่วไป
- การปรับแต่งได้: ผู้ใช้สามารถปรับแต่ง UI, คีย์ไบน์ดิง, การตั้งค่าดีบัก และอื่น ๆ ได้อย่างอิสระ
การรองรับภาษาและส่วนขยาย
- รองรับภาษาหลักอย่าง Rust, C/C++, JavaScript, Go, Python ได้โดยตรง
- สามารถเชื่อมต่อกับดีบักอะแดปเตอร์ทุกตัวที่รองรับ Debug Adapter Protocol (DAP)
- สามารถเพิ่มภาษาและฟีเจอร์ดีบักที่หลากหลายยิ่งขึ้นได้อย่างง่ายดายผ่านระบบส่วนขยาย
การตั้งค่าดีบักที่ง่ายขึ้น
- นำระบบใหม่ชื่อ LOCATORS มาใช้เพื่อแปลงการตั้งค่าการบิลด์ให้เป็นการตั้งค่าดีบัก
- หลังจากเขียนบิลด์ทาสก์ไว้ครั้งหนึ่งใน
tasks.json แล้ว สามารถอ้างอิงจาก debug.json หรือใช้ความสามารถตั้งค่าอัตโนมัติของ Zed ได้
- Zed จะรัน locators โดยอัตโนมัติจากไฟล์ที่รันได้ในตัวหรือจาก Language Server
- ในกรณีส่วนใหญ่ สามารถใช้งานได้ทันทีโดยไม่ต้องมีการตั้งค่าดีบักแยกต่างหาก
- ปัจจุบันรองรับ locator สำหรับ Cargo, Python, JavaScript และ Go (จะมีภาษาอื่นเพิ่มตามมา)
ความสามารถของเซสชันดีบัก
- สามารถตรวจสอบสถานะของโปรแกรม เช่น เธรด ตัวแปร เบรกพอยต์ และคอลสแต็ก ได้อย่างง่ายดายภายใน Zed
- แผงดีบักสามารถ ปรับแต่งได้อย่างเต็มที่ โดยลากและจัดเรียงแท็บ หรือย้ายแผงไปมาได้อย่างอิสระ
- รองรับการดีบักแบบเน้นคีย์บอร์ด ทำให้สามารถนำทางโค้ด สลับเบรกพอยต์ และย้ายระหว่างเซสชันได้โดยไม่ต้องใช้เมาส์
สถาปัตยกรรมที่ขยายได้สูง
- เพื่อรองรับการดีบักหลายภาษา สภาพแวดล้อมการทำงานร่วมกัน การรองรับส่วนขยาย และการแคช/จัดการข้อมูลอย่างมีประสิทธิภาพ จึงได้ออกแบบ สถาปัตยกรรม 2 ชั้น ขึ้นมา
- ชั้นข้อมูล: สื่อสารกับดีบักอะแดปเตอร์โดยตรง ดูแลสถานะเซสชัน แคชการตอบกลับ และจัดการการทำให้ข้อมูลเก่าหมดอายุ
- ชั้น UI: ขอเฉพาะข้อมูลที่จำเป็น และมุ่งเน้นการเรนเดอร์อินเทอร์เฟซ
- การแยกส่วนนี้ช่วยให้การพัฒนาฟีเจอร์ดีบักแบบทำงานร่วมกัน (multiplayer) ทำได้ง่ายขึ้น และยังช่วยประหยัดแบนด์วิดท์เครือข่ายได้มาก
การใช้ Extension API และ DAP
- มี DAP implementation มากกว่า 70 แบบ ดังนั้นแทนที่จะรองรับทุกอย่างในตัว Extension API ของ Zed จึงถูกขยายเพื่อให้สามารถผสานดีบักเกอร์เข้าไปได้
- สามารถขยายการรองรับ DAP ได้ด้วยการกำหนดสคีมาเอง สร้างตรรกะสำหรับดาวน์โหลดและรันอะแดปเตอร์ ใส่ค่าเริ่มต้นให้การตั้งค่าดีบัก และเชื่อมต่อกับ locator แบบอัตโนมัติ
- คล้ายกับแนวทางส่วนขยาย LSP (Language Server Protocol) นักพัฒนาสามารถผสานดีบักอะแดปเตอร์ของตนเองเข้ากับ Zed ได้อย่างง่ายดาย
การรองรับค่าอินไลน์ของตัวแปร
- ฟีเจอร์แสดงค่าอินไลน์ของตัวแปรเป็นส่วนของ LSP ไม่ใช่ DAP ดังนั้นจึงให้บริการด้วยวิธีเดิมได้ก็ต่อเมื่อมีทั้ง DAP และ LSP ทำงานร่วมกัน
- การจับคู่แบบง่ายด้วย regular expression มีความแม่นยำต่ำเพราะมีปัญหาเรื่องสโคป คอมเมนต์ และประเด็นอื่น ๆ
- ใช้ Tree-sitter เพื่อระบุตัวแปรภายในสโคปของโค้ดที่กำลังรันได้อย่างแม่นยำ
- รองรับรายภาษาได้ผ่านไฟล์
.scm โดยไม่ต้องพึ่งการเชื่อมต่อ LSP เพิ่มเติม
- ณ เวลาที่เปิดตัว รองรับ Python, Rust และ Go และมีแผนเพิ่มภาษาอื่นอีกในอนาคต
- Zed เป็นเอดิเตอร์ที่สร้างโดยผู้สร้าง Tree-sitter
แผนในอนาคต
- มุมมองใหม่: มีแผนเพิ่มฟีเจอร์ขั้นสูง เช่น watch list, memory view, disassembly view และ stack trace
- การตั้งค่าอัตโนมัติ: ตั้งเป้าขยายการรองรับการตั้งค่าอัตโนมัติให้ครอบคลุมภาษาและระบบบิลด์มากขึ้น
- การขัดเกลาและขยายต่อ: รับฟีดแบ็กผ่าน Discord, GitHub และมีความตั้งใจปรับปรุงอย่างต่อเนื่อง
ภาคผนวก
- สามารถใช้ Zed ได้บน macOS และ Linux
- กำลังเปิดรับสมัครนักพัฒนา (หากสนใจให้ดูที่เว็บไซต์ทางการ)
2 ความคิดเห็น
มีใครใช้ Zed กับ Java บ้างไหมครับ...? 555
ความคิดเห็นบน Hacker News
รู้สึกดีใจมากที่เห็นว่ากำลังพัฒนาดีบักเกอร์อยู่ นี่แหละคือฟีเจอร์หลักที่ขัดขวางไม่ให้ผมย้ายมาใช้ zed แบบเต็มตัวเสียที เพียงแต่ยังไม่ถึงขั้นเรียกว่า “พร้อมแล้ว” ยังขาด watch window, stack trace view และก็น่าเสียดายที่ไม่มีการพูดถึง data breakpoint เลย เลยยังมองว่าเป็นระดับเบต้าอยู่ ผมรู้ว่าฟีเจอร์เหล่านี้น่าจะถูกเพิ่มเข้ามาในสักวัน แต่สิ่งที่มีอยู่ตอนนี้ยังไม่พอสำหรับ 97% ของ debugging session ของผม อยากให้ในประกาศพูดให้ชัดเจนกว่านี้ด้วยว่าจะรองรับหลาย debugging session พร้อมกัน และมีแผนเรื่อง multithreaded debugging อย่างไร โดยเฉพาะไอเดียเจ๋ง ๆ แบบ RemedyBG อย่างการ ‘freeze’ บาง thread หรือปล่อยให้ตัวเดียววิ่งแบบ ‘solo’ ในการดีบักหลายเธรด
สวัสดี Laserbeam ผมเป็นคนพัฒนาดีบักเกอร์และเป็นคนเขียนโพสต์นั้นเอง ตอนนี้รองรับ stack trace view พื้นฐานแล้ว อีกไม่นานจะมี stack trace view ภายในระบบ multi-buffer ด้วย และตอนนี้ระหว่าง debugging session ก็สามารถขยาย call stack ใน multi-buffer เพื่อดูแต่ละเฟรมได้ผ่านแอ็กชัน “show stack trace” เพียงแต่มันยังไม่ถึงมาตรฐานคุณภาพสูงแบบ Zed เลยยังไม่ได้โปรโมตอย่างเปิดเผย ส่วน PR ของฟีเจอร์ watch variables/expressions ก็น่าจะ merge ภายในไม่กี่วัน ฟีเจอร์ทำเสร็จแล้ว แต่ช่วงใกล้ปล่อยเราระวังที่จะใส่สิ่งที่ยังทดสอบไม่พอเข้าไป Data breakpoint เป็นลำดับความสำคัญที่สูง แต่ช่วงนี้เราวางแผนจะโฟกัสเรื่องการตั้งค่าอัตโนมัติไปอีกสักพัก จึงยังบอกกำหนดการที่ชัดเจนไม่ได้ ส่วนหลาย session และ multithreaded debugging ก็รองรับอยู่แล้วเช่นกัน แม้ยังมีจุดที่ต้องเก็บงานเพิ่ม แต่มีการรองรับพื้นฐานแล้ว
ในบล็อกโพสต์มีพูดถึง advanced view ที่กำลังพัฒนาอยู่แล้ว การเปิดตัวและประกาศครั้งแรกนี้เน้นไปที่การวางรากฐาน ก่อนจะเพิ่ม advanced view อย่าง watch list, memory view, disassembly view และ stack trace view ต่อไป [ลิงก์ที่เกี่ยวข้อง]
debugging session ของผมมีแค่ breakpoint ปกติกับการ step เสมอ ดังนั้นสำหรับผมแค่นี้ก็เพียงพอแล้ว
ผมก็เห็นด้วย แต่ดูจากความเร็วในการพัฒนาของทีม Zed แล้ว มีลางสังหรณ์ว่าฟีเจอร์พวกนี้คงตามมาเร็ว ๆ นี้
ผมยังไม่ได้ลองดีบักเกอร์ แต่ในกรณีของผมมีความรู้สึกคล้ายกันกับฟีเจอร์ Git ตอนนี้ Zed มีฟีเจอร์ Git พื้นฐานแล้ว แต่ยังไม่พอจะมาแทน workflow เดิมทั้งหมดของผมได้ ก็หวังว่าทีมจะยังให้ความสำคัญกับการพัฒนา Git ต่อไป
Zed เป็นเอดิเตอร์ที่ดีมากจริง ๆ ช่วงนี้ผมกำลังย้ายจาก neovim มา zed และพอใจมาก ทุกอย่างเร็วมากและมีการรวม vim binding มาได้ดี โหมด agent ก็สะดวกด้วย ถึงระบบนิเวศของส่วนขยายจะยังสู้ VSCode ไม่ได้ แต่ก็ครอบคลุมงานที่ผมต้องใช้หลายอย่างได้เพียงพอ ดีบักเกอร์เป็นช่องโหว่ใหญ่ที่มีมานาน และตอนนี้มีเพิ่มเข้ามาแล้วก็ดีใจมาก
สงสัยว่า vim binding ให้ความรู้สึกเหมือน vim จริงแค่ไหน พวก vim emulator ส่วนใหญ่มักจะคล้ายพอสมควร แต่กลับก้ำกึ่งเกินไปจนกดคีย์พลาดบ่อยและยิ่งน่าหงุดหงิดกว่าเสียอีก ผมเคยรู้สึกว่าถ้าเป็นเอดิเตอร์ที่ไม่ได้ให้ฟีลแบบ vim ไปเลย กลับน่ารำคาญน้อยกว่าตอนนิ้วคอย ‘พลาด’ ตลอด
อยากรู้ว่าการ autocomplete โค้ด Rust บน Zed เป็นยังไง ถ้ามีสภาพแวดล้อมแบบมหัศจรรย์ที่กด “tab-tab-tab” แล้วทุกอย่าง autocomplete ได้ลื่นไหลเหมือน Windsurf หรือ Cursor ก็คงดีมาก โดยเฉพาะกับ TypeScript หรือภาษาสคริปต์ วิธี autocomplete แบบนี้ทำงานดีจนแทบเรียกว่าเป็นการรีแฟกเตอร์อัตโนมัติได้เลย IntelliJ/RustRover แม้จะใช้โมเดลของ JetBrains หรือ Co-pilot ก็ยังตามระดับ Cursor หรือ Windsurf ไม่ทัน ผมคิดว่าเป็นเพราะธรรมชาติของ Rust เอง 1) ตอนนี้ Rust ทำ autocomplete แบบลื่นไหลขนาดนั้นได้หรือยัง และ Zed ทำได้ไหม 2) ถ้าเทียบ Zed กับ Cursor, Windsurf แล้ว รวมถึงเทียบกับวิธีที่ RustRover และ JetBrains จัดการ Rust AST ด้วย มันให้ความรู้สึกอย่างไร
Zed ให้ความรู้สึกเหมือนทำสิ่งที่ Lapce, Helix และ Neovim ทำไม่สำเร็จมาตลอดเป็นจริงขึ้นมา ตอนที่ผมใช้ Helix ราวปี 2021~2022 ก็สุดท้ายต้องเลิกเพราะบั๊กและการผสานรวมที่ยังไม่พอ โดยเฉพาะแทบไม่มีการรองรับ PHP ที่บริษัทเก่าใช้ Neovim สะดวกที่สุดก็จริง แต่ปลั๊กอินชุมชนชื่อดังหลายตัวมีแนวทางที่แข็งมาก ส่วนปลั๊กอินทางเลือกก็ช้าเกินไป กว่าจะจัดสภาพแวดล้อมที่เสถียรได้ต้องชั่งใจตัวเลือกมากมายจนเหนื่อย Lapce ก็เหมือน “VSCode เวอร์ชันลอกแบบ” เฉย ๆ ไม่รู้สึกว่ามีอะไรพิเศษ และยังรู้สึกว่าไม่ถึงขั้นใช้เป็น daily driver ได้อยู่ดี ในแง่นั้น Zed กลายเป็นเอดิเตอร์ที่ดีที่สุดในเวลาอันสั้น และทุกวันนี้ผมรู้สึกขอบคุณอยู่ทุกวัน การมีดีบักเกอร์เพิ่มเข้ามาก็ยิ่งน่ายินดีมาก
คำอธิบายว่า (เพราะเป็นบริษัทเก่า) สำหรับการรองรับ PHP นั้นจริง ๆ ไม่จำเป็น
มุมมองที่เรียกมันว่า “VSCode เวอร์ชันลอกแบบ” ก็น่าสนใจดีนะ เป็นการตีความที่ชวนขำเกี่ยวกับเอดิเตอร์ที่ได้รับความนิยมมากที่สุดในประวัติศาสตร์มนุษย์
รู้สึกทึ่งที่ Zed กำลังค่อย ๆ พัฒนาเป็น IDE ที่สมบูรณ์ขึ้น เบา และมีฟีเจอร์หลากหลาย สำหรับผม DAP กับ LSP คือสุดยอดนวัตกรรมที่ดีที่สุดที่เกิดขึ้นกับเครื่องมือเขียนโปรแกรมในรอบ 10 ปีที่ผ่านมา
ตอนแรกผมสนใจ Zed แต่พอเริ่มมีการผสาน “AI” เข้ามา ความสนใจก็หายไป ผมเริ่มเหนื่อยกับ “AI” ที่มีอยู่เต็มไปหมด คงจะใช้ Neovim ต่อไปจนกว่าจะมีอะไรที่ดีกว่านี้ออกมา และการเปลี่ยนแปลงนั้นคงเกิดหลัง “ฟองสบู่ AI” แตกไปแล้ว
Zed เป็นเอดิเตอร์ตัวแรกที่ทำให้ผมอยากลองใช้ฟีเจอร์ AI โดยรวมมันมีพื้นฐานที่แข็งแรงมาก และกลิ่นอาย AI ก็มีอยู่แค่ประมาณ autocomplete แบบในเอดิเตอร์อื่น ๆ ผมรู้สึกถึงท่าทีประมาณว่า “สิ่งที่คุณต้องการไม่ใช่ AI แต่คือเอดิเตอร์ดี ๆ ที่เร็ว เราสร้างสิ่งนั้นแล้วและก็ใส่ฟีเจอร์ AI มาด้วย” คู่แข่งหลายเจ้าดูเหมือน “เราเอา AI เป็นตัวหลัก แล้วเอดิเตอร์เป็นแค่ของแถม” แต่ Zed มีจุดศูนย์กลางต่างออกไป
ผมเพิ่งไปดู neovim แล้วแปลกใจที่มันได้รับการสนับสนุนจากผลิตภัณฑ์ AI ถึงสองเจ้า แม้จะยังไม่ถึงขั้นผสาน AI โดยตรง แต่ตอนนี้เหมือนจะเลี่ยงมันได้ยากขึ้นเรื่อย ๆ แล้ว
ผมแค่ปิดตัวเลือกเกี่ยวกับ AI ทั้งหมดแล้วใช้งานอยู่ ก็เป็นเอดิเตอร์ที่ค่อนข้างดีนะ แม้ตอนนี้เวลาแก้ merge conflict ผมยังต้องกลับไปใช้ VSCode อยู่ แต่โดยรวมก็พอใจ
อยากรู้ว่าฟีเจอร์ AI ของ Zed รบกวนการใช้งานจริงมากแค่ไหน และปิดผ่านการตั้งค่าได้ไหม
ตอนใช้ Zed ตามปกติ ฟีเจอร์ AI ไม่ได้รบกวนเลย บางครั้งก็มีประโยชน์ แต่ผมไม่ได้ใช้บ่อย
ตั้งแต่มีการรองรับ Linux ผมก็คอยเช็กทุกครั้งว่ามีการรองรับจอปกติ (LoDPI) แล้วหรือยัง น่าเสียดายที่ยังไม่มี
น่าหงุดหงิดจริง ๆ การเรนเดอร์ข้อความเป็นพื้นฐานของ code editor แท้ ๆ แต่ดูเหมือนทีม Zed จะไม่มีใครใช้หน้าจอปกติ (non-retina) เลย ลิงก์ GitHub issue ที่เกี่ยวข้อง
เป็นวิธีแก้ชั่วคราว แต่ถ้าติดตั้ง BetterDisplay (เครื่องมือฟรี) แล้วเปลี่ยนจอ LoDPI ให้เป็น HiDPI การเรนเดอร์ข้อความจะดีขึ้นใช้ได้
ผมใช้ทุกวันบนหน้าจอโน้ตบุ๊ก Linux 1920x1200 และไม่เห็นมีอะไรแปลกเลย
ถ้ายังไม่รองรับ Windows และบน Linux ก็ยังไม่รองรับจอปกติ แบบนี้มันเป็นบริษัทที่โฟกัส Mac เป็นหลักหรือเปล่า
ตอนนี้ผมอยากย้ายจาก Cursor มาใช้ Zed กับโปรเจ็กต์ Python ที่ใช้ Pyright แต่การใช้แบตเตอรี่สูงเกินกว่าจะยอมรับได้ มี issue นี้อยู่บน GitHub แล้ว และก็น่าเสียดายมากที่ทีมไม่ได้ให้ลำดับความสำคัญสูงกับมัน
ผมคิดว่า Zed เป็นตัวอย่างของการพัฒนาผลิตภัณฑ์ที่แท้จริง เป็นตัวเลือกที่น่ายินดีมากเพราะไม่ใช่แค่การเอา Chromium engine มาห่อใหม่อีกรอบ
พูดตามตรง ผมแปลกใจที่มันมีจุดช้าบางอย่าง เวลาสลับไฟล์จากรายการแท็บมีดีเลย์ และการตอบสนองตอนพิมพ์ก็ช้ากว่า Emacs (เปิด lsp-mode) หรือแม้แต่เว็บเบราว์เซอร์ มันยังกินหน่วยความจำมากกว่า Emacs ราว 60MiB ด้วย แต่ความเร็วตอนเปิดโปรแกรมนั้นเร็วมาก พอมันช้ากว่าแกน Emacs Lisp + C ทั้งที่มีสโลแกนว่าเป็น ‘เอดิเตอร์ที่เร็ว’ ก็เลยน่าประหลาดใจ ผมลองดูโครงสร้างปลั๊กอินแล้วเหมือนมันถูกคอมไพล์เป็น WASM แล้วรันใน VM ไม่แน่ใจว่านั่นเป็นสาเหตุหรือเปล่า
อยากรู้เหมือนกันว่าทำยังไงถึงได้ Zed ที่ช้ากว่า emacs เพราะจากประสบการณ์ของผม zed เร็วแทบไม่มี latency ทั้งการแก้ไข, lsp และการสลับไฟล์ล้วนตอบสนองทันที ตรงกันข้าม emacs ต่างหากที่ผมมักเลิกใช้เพราะปัญหา latency (โดยเฉพาะในสภาพแวดล้อมพัฒนาแบบรีโมต)
สำหรับคำถามว่าปลั๊กอินรันเป็น WASM ใน VM แล้วทำให้ช้าหรือไม่ จากที่ผมเห็นปลั๊กอินที่มีอยู่ทำหน้าที่แค่พวกเปิดเซิร์ฟเวอร์เป็นหลัก จึงไม่น่าเกี่ยวโดยตรงกับการตอบสนองตอนพิมพ์ ผมกลับคิดว่าน่าจะเป็นเพราะการใช้ GPU มากกว่า การทำ GPU compositing ทำให้เกิดดีเลย์ได้ง่าย และอาจซ้อนทับกับการเรนเดอร์ของ OS อีกทีด้วย ผมจำได้ว่า emacs เองก็เคยใช้เทคนิคข้าม event loop แล้วอัปเดต UI โดยตรงจนเกิดปัญหาความเข้ากันได้เหมือนกัน
emacs มีแพ็กเกจชื่อ dape ซึ่งเป็นดีบักเกอร์แบบ DAP ที่ออกแบบมาดี ลิงก์ที่เกี่ยวข้อง มันถูกออกแบบให้ไม่มี dependency และอาจถูกนำเข้าไปอยู่ใน emacs หลักได้ในอนาคต
อาจเป็นปัญหาที่ rendering pipeline ก็ได้ อยากรู้ว่าคุณใช้ระบบปฏิบัติการอะไร
สิ่งที่ผมอยากขอทีม zed มากที่สุดตอนนี้คือช่วยทำ language detection ของ C และ C++ ให้ถูกต้องสักที เอดิเตอร์แทบทุกตัวชอบทำผิดด้วยการปฏิบัติกับ C เหมือนเป็น C++ (ทั้งที่ C ไม่ใช่ C++ และไม่ควรสับสนกัน) ต่อให้ระบุมาตรฐาน C ใน
compile_commands.jsonแล้ว หลายครั้งก็ยังมองโค้ดที่เป็น syntax error ของ C++ ว่าเป็น C อยู่ดี ถ้าทำ language detection ให้ถูกต้องได้ มันจะเป็นเอดิเตอร์ที่ดีมาก