- Tính năng gỡ lỗi được hơn 2.000 nhà phát triển yêu cầu cuối cùng đã được triển khai trong Zed
- Trình gỡ lỗi được thiết kế xoay quanh tốc độ, sự quen thuộc và khả năng cấu hình
- Hỗ trợ các ngôn ngữ phổ biến như Rust, C/C++, JavaScript, Go, Python cùng hỗ trợ mở rộng dựa trên Debug Adapter Protocol (DAP)
- Hệ thống LOCATORS trực quan giúp gỡ lỗi dễ dàng trên hầu hết dự án mà không cần cấu hình riêng
- Kiến trúc tách biệt giữa UI và lớp dữ liệu tạo nền tảng mạnh mẽ cho gỡ lỗi cộng tác và khả năng mở rộng
Ra mắt trình gỡ lỗi của Zed
- Theo yêu cầu của hơn 2.000 nhà phát triển, trình soạn thảo Zed đã chính thức bổ sung tính năng gỡ lỗi. Đây là một bước tiến rất quan trọng trên con đường hướng tới Zed 1.0
Mục tiêu chính
- Tốc độ: mang lại khả năng chuyển đổi ngữ cảnh nhanh và trải nghiệm gỡ lỗi hiệu quả
- Sự quen thuộc: hài hòa với ngôn ngữ thiết kế của Zed, đồng thời hỗ trợ đầy đủ các tính năng được mong đợi trong luồng làm việc gỡ lỗi điển hình
- Khả năng cấu hình: người dùng có thể tự do tùy chỉnh UI, key binding, cấu hình gỡ lỗi và nhiều thành phần khác
Hỗ trợ ngôn ngữ và mở rộng
- Hỗ trợ sẵn các ngôn ngữ chính như Rust, C/C++, JavaScript, Go, Python
- Có thể tích hợp với mọi debug adapter triển khai Debug Adapter Protocol (DAP)
- Có thể dễ dàng bổ sung thêm nhiều ngôn ngữ và tính năng gỡ lỗi đa dạng hơn thông qua hệ thống mở rộng
Thiết lập gỡ lỗi đơn giản
- Giới thiệu một hệ thống mới tên là LOCATORS để chuyển cấu hình build thành cấu hình gỡ lỗi
- Sau khi viết build task một lần trong
tasks.json, có thể tham chiếu nó trong debug.json hoặc dùng tính năng cấu hình tự động của Zed
- Zed tự động chạy locator từ các tệp thực thi tích hợp sẵn hoặc do Language Server cung cấp
- Trong đa số trường hợp, có thể dùng ngay mà không cần cấu hình gỡ lỗi riêng
- Hiện đã hỗ trợ locator cho Cargo, Python, JavaScript và Go (sẽ bổ sung thêm ngôn ngữ khác)
Tính năng của phiên gỡ lỗi
- Có thể dễ dàng kiểm tra trạng thái chương trình như thread, biến, breakpoint, call stack ngay trong Zed
- Bảng điều khiển trình gỡ lỗi có thể tùy biến hoàn toàn, cho phép kéo thả và sắp xếp tab hoặc di chuyển panel tự do
- Cũng hỗ trợ gỡ lỗi theo hướng ưu tiên bàn phím, cho phép điều hướng mã, bật/tắt breakpoint và chuyển giữa các phiên mà không cần chuột
Kiến trúc có khả năng mở rộng cao
- Để hỗ trợ gỡ lỗi cho nhiều ngôn ngữ, môi trường cộng tác, khả năng mở rộng cũng như việc cache và quản lý dữ liệu hiệu quả, Zed đã thiết kế kiến trúc 2 lớp
- Lớp dữ liệu: giao tiếp trực tiếp với debug adapter, duy trì trạng thái phiên, cache phản hồi và quản lý việc vô hiệu hóa dữ liệu cũ
- Lớp UI: chỉ yêu cầu dữ liệu cần thiết và tập trung vào việc render giao diện
- Nhờ sự tách biệt này, việc triển khai tính năng gỡ lỗi cộng tác (multiplayer) trở nên dễ dàng hơn và cũng giúp tiết kiệm băng thông mạng đáng kể
Áp dụng API mở rộng và DAP
- Có hơn 70 implementation DAP khác nhau, nên thay vì hỗ trợ mặc định tất cả, Zed đã mở rộng API mở rộng của Zed để cho phép tích hợp trình gỡ lỗi
- Có thể mở rộng hỗ trợ DAP bằng cách tự định nghĩa schema, triển khai logic tải xuống và chạy adapter, chèn giá trị mặc định cho cấu hình gỡ lỗi, cũng như liên kết tự động với locator
- Tương tự cách mở rộng LSP (Language Server Protocol), nhà phát triển có thể dễ dàng tích hợp debug adapter riêng của mình vào Zed
Hỗ trợ giá trị biến inline
- Tính năng hiển thị giá trị biến inline thuộc về LSP chứ không phải DAP, nên chỉ có thể cung cấp theo cách hiện có khi cả DAP và LSP đều được liên kết
- Các cách đối sánh đơn giản như biểu thức chính quy có độ chính xác thấp do các vấn đề về scope, comment và nhiều yếu tố khác
- Zed sử dụng Tree-sitter để nhận diện chính xác các biến trong scope của đoạn mã đang chạy
- Có thể hỗ trợ theo từng ngôn ngữ thông qua tệp
.scm mà không cần tích hợp LSP riêng
- Tại thời điểm ra mắt đã hỗ trợ Python, Rust và Go, và dự kiến sẽ bổ sung thêm nhiều ngôn ngữ khác sau này
- Zed là trình soạn thảo do những người tạo ra Tree-sitter xây dựng
Kế hoạch sắp tới
- Các view mới: dự kiến bổ sung các tính năng nâng cao như watch list, memory view, disassembly view và stack trace
- Cấu hình tự động: mục tiêu mở rộng hỗ trợ cấu hình tự động cho nhiều ngôn ngữ và hệ thống build hơn
- Hoàn thiện và mở rộng: sẽ tiếp nhận phản hồi qua Discord, GitHub và tích cực cải tiến
Phụ lục
- Có thể sử dụng Zed trên macOS và Linux
- Đang tuyển dụng nhà phát triển (nếu quan tâm hãy xem trang chính thức)
2 bình luận
Có ai dùng Zed bằng Java không nhỉ...? haha
Ý kiến trên Hacker News
Tôi rất vui khi thấy việc phát triển trình gỡ lỗi đang được tiến hành. Đây chính là tính năng chính khiến tôi chưa thể chuyển hẳn sang Zed. Tuy vậy, để nói là “đã đến mức đó rồi” thì vẫn còn thiếu. Việc chưa có cửa sổ watch, thiếu chế độ xem stack trace và không thấy nhắc đến data breakpoint khiến tôi xem đây vẫn là giai đoạn beta. Tôi biết các tính năng đó rồi sẽ được bổ sung vào một lúc nào đó, nhưng những gì hiện có bây giờ vẫn chưa đủ để đáp ứng 97% các phiên debug của tôi. Tôi cũng muốn phần công bố nhắc rõ hơn về hỗ trợ nhiều phiên debug đồng thời và kế hoạch debug đa luồng. Đặc biệt, tôi tò mò về những ý tưởng hay cho debug đa luồng như RemedyBG, chẳng hạn “đóng băng” một luồng cụ thể hoặc cho chỉ một luồng chạy ở chế độ “solo” thôi
Chào Laserbeam, tôi là người đã phát triển trình gỡ lỗi và cũng là tác giả của bài viết đó. Chế độ xem stack trace cơ bản đã được hỗ trợ rồi. Sắp tới sẽ có stack trace view trong hệ thống multi-buffer, và ngay lúc này trong phiên debug bạn cũng có thể mở rộng call stack trong multi-buffer bằng hành động “show stack trace” để xem từng frame. Tuy nhiên, nó vẫn chưa đạt chất lượng cao theo tiêu chuẩn của Zed nên chúng tôi chưa quảng bá công khai. PR cho tính năng watch biến/biểu thức cũng dự kiến sẽ được merge trong vài ngày tới. Tính năng thì đã xong, nhưng chúng tôi hơi thận trọng với việc đưa vào một tính năng chưa được kiểm thử đầy đủ khi ngày phát hành đã cận kề. Data breakpoint là ưu tiên quan trọng, nhưng trong một thời gian tới chúng tôi định tập trung vào phần cấu hình tự động, nên khó đưa ra mốc thời gian chính xác. Nhiều phiên và debug đa luồng cũng đã được hỗ trợ đồng thời; vẫn còn chỗ cần hoàn thiện thêm nhưng hỗ trợ cơ bản thì đã có
Bài blog có nhắc rằng các chế độ xem nâng cao đang được phát triển. Lần phát hành và công bố đầu tiên này tập trung vào việc xây nền tảng. Sau này sẽ bổ sung các chế độ xem nâng cao như watch list, memory view, disassembly view và stack trace view [liên kết liên quan]
Các phiên debug của tôi lúc nào cũng chỉ dùng breakpoint thông thường và stepping. Vì vậy với tôi như thế là đủ rồi
Tôi cũng đồng ý, nhưng nhìn vào tốc độ phát triển của đội ngũ Zed thì có cảm giác các tính năng đó sẽ sớm theo kịp thôi
Tôi chưa thử trình gỡ lỗi, nhưng với tôi thì tính năng Git cũng tạo cảm giác tương tự. Zed có các tính năng Git cơ bản, nhưng vẫn chưa đủ để thay thế toàn bộ workflow hiện tại của tôi. Tôi cũng mong phía Git tiếp tục được đầu tư phát triển
Zed thật sự là một trình soạn thảo rất ổn. Gần đây tôi đang chuyển từ neovim sang zed và mức độ hài lòng rất cao. Mọi thứ đều rất nhanh và vim binding cũng được tích hợp tốt. Chế độ agent cũng là một điểm tiện lợi. Hệ sinh thái extension vẫn còn thiếu so với VSCode, nhưng đã bao phủ đủ nhiều tác vụ mà tôi cần. Trình gỡ lỗi là thiếu sót lớn suốt thời gian qua, nên việc nó được bổ sung bây giờ thật sự rất đáng mừng
Tôi tò mò không biết vim binding của nó “giống vim thật” đến mức nào. Hầu hết các trình giả lập vim đều đủ giống, nhưng lại dở dở ương ương đến mức tôi thường xuyên bấm sai phím, và điều đó còn khó chịu hơn. Tôi từng thấy rằng dùng hẳn một editor không có cảm giác vim còn đỡ bực hơn việc ngón tay cứ liên tục “sai nhịp”
Tôi tò mò không biết tự động hoàn thành mã Rust trên Zed thế nào. Nếu có được môi trường “tab-tab-tab” thần kỳ như Windsurf hay Cursor, nơi mọi thứ được autocomplete tự nhiên, thì sẽ tuyệt lắm. Đặc biệt với TypeScript hay các ngôn ngữ script, kiểu autocomplete đó gần như là tự động hóa refactor luôn. IntelliJ/RustRover, kể cả khi dùng model của JetBrains hay Co-pilot, vẫn không theo kịp Cursor hay Windsurf. Tôi nghĩ là do đặc tính của Rust. 1) Liệu kiểu autocomplete tự nhiên như vậy giờ đã khả thi với Rust chưa, và Zed có làm được không? 2) So với Zed, Cursor, Windsurf, cũng như cách RustRover và JetBrains xử lý Rust AST, cảm giác sử dụng khác nhau như thế nào?
Zed tạo cảm giác như đã làm được điều mà Lapce, Helix và Neovim bấy lâu chưa làm được. Khoảng 2021~2022 tôi từng dùng Helix nhưng cuối cùng bỏ cuộc vì lỗi và thiếu tích hợp, nhất là gần như không có hỗ trợ PHP ở công ty cũ của tôi. Neovim thì là cái tôi thấy thoải mái nhất, nhưng nhiều plugin cộng đồng nổi tiếng lại theo phong cách rất cực đoan, còn plugin thay thế thì quá chậm. Việc phải cân nhắc quá nhiều lựa chọn chỉ để có được một môi trường ổn định thật sự rất mệt. Lapce thì chỉ giống như một “bản sao VSCode”, tôi không cảm nhận được điều gì đặc biệt. Tôi vẫn nghĩ nó chưa đạt tới mức có thể dùng làm daily driver. Ở điểm này, Zed đã trở thành editor tốt nhất chỉ trong thời gian ngắn, và dạo này tôi cảm thấy biết ơn nó mỗi ngày. Việc bổ sung debugger cũng thật sự đáng mừng
Phần giải thích “ở công ty cũ” cho hỗ trợ PHP thì thật ra cũng không cần thiết
Cách đánh giá là “bản sao VSCode” cũng là một góc nhìn thú vị. Một cách diễn giải khá vui về editor phổ biến nhất trong lịch sử loài người
Tôi thật sự ấn tượng khi thấy Zed đang dần phát triển thành một IDE hoàn thiện hơn, nhẹ hơn nhưng vẫn có nhiều tính năng. Theo tôi, DAP và LSP là những đổi mới tốt nhất từng xuất hiện trong công cụ lập trình suốt 10 năm qua
Ban đầu tôi có hứng thú với Zed, nhưng khi “AI” bắt đầu được tích hợp thì tôi mất hứng. Tôi đã quá mệt mỏi vì “AI” ở khắp mọi nơi. Cho đến khi có thứ gì đó tốt hơn, tôi vẫn định tiếp tục dùng Neovim, và có lẽ sự thay đổi đó chỉ đến sau khi “bong bóng AI” vỡ thôi
Zed là editor đầu tiên khiến tôi muốn thử dùng tính năng AI. Nhìn tổng thể thì nền tảng của nó rất chắc, và yếu tố AI cũng chỉ hiện diện cỡ như autocomplete trong các editor khác thôi. Nó tạo cảm giác kiểu “thứ bạn muốn không phải là AI mà là một editor tốt, nhanh; chúng tôi đã làm điều đó rồi và cũng thêm AI vào nữa”. Đối thủ thì lại cho cảm giác “chúng tôi lấy AI làm trung tâm, editor chỉ là phần ăn kèm”, còn Zed thì trọng tâm khác hẳn
Tôi tra thử neovim thì ngạc nhiên khi thấy nó còn được hai sản phẩm AI tài trợ. Chưa đến mức tự tích hợp AI trực tiếp, nhưng bây giờ ngày càng khó mà tránh hoàn toàn
Tôi chỉ đơn giản là tắt hết mọi tùy chọn liên quan đến AI rồi dùng. Nó là một editor khá ổn. Tôi vẫn phải quay sang VSCode để xử lý merge conflict, nhưng nhìn chung vẫn hài lòng
Tôi tò mò không biết các tính năng AI của Zed thực tế xâm lấn đến mức nào, và có thể tắt bằng cấu hình hay không
Khi dùng Zed hằng ngày thì tôi gần như không thấy AI làm phiền gì cả. Thỉnh thoảng nó có ích, nhưng tôi không dùng thường xuyên
Từ sau khi có hỗ trợ Linux, mỗi lần tôi đều kiểm tra xem đã hỗ trợ màn hình thông thường (LoDPI) chưa. Thật tiếc là đến giờ vẫn chưa có
Tình trạng này thật sự rất bực. Render chữ là nền tảng cơ bản của một code editor, mà có vẻ đội Zed chẳng có ai dùng màn hình thường (non-retina). Liên kết issue GitHub liên quan
Chỉ là giải pháp tạm, nhưng nếu cài BetterDisplay (công cụ miễn phí) và chuyển màn hình LoDPI sang HiDPI thì chất lượng render chữ sẽ ổn hơn
Tôi dùng hằng ngày trên màn hình laptop Linux 1920x1200 và không thấy có gì lạ cả
Không có hỗ trợ Windows, lại còn không hỗ trợ màn hình thường trên Linux, nên tôi tự hỏi liệu đây có phải thực chất là một công ty quá tập trung vào Mac hay không
Hiện tại tôi muốn chuyển từ Cursor sang Zed cho dự án Python dùng Pyright, nhưng mức tiêu thụ pin quá cao nên không thể biện minh được. Vấn đề này đã có trên GitHub rồi, nên việc đội ngũ không ưu tiên cao cho nó khiến tôi rất thất vọng
Tôi nghĩ Zed là ví dụ của phát triển sản phẩm đúng nghĩa. Thật tuyệt khi có một lựa chọn không phải là thêm một bản đóng gói lại của engine Chrome nữa
Thành thật mà nói tôi ngạc nhiên vì có những chỗ nó chậm. Khi chuyển file trong danh sách tab có độ trễ, và phản hồi khi gõ cũng chậm hơn cả Emacs (bật
lsp-mode) lẫn trình duyệt web. Nó cũng dùng nhiều hơn Emacs khoảng 60MiB bộ nhớ. Bù lại thì tốc độ khởi động thật sự rất nhanh. Trái với khẩu hiệu “editor nhanh”, nó lại còn chậm hơn cả Emacs Lisp + lõi C. Tôi xem qua kiến trúc plugin thì có vẻ chúng được biên dịch sang WASM và chạy trong VM. Không biết đó có phải nguyên nhân khôngTôi tò mò không biết bằng cách nào mà zed lại chậm hơn emacs với bạn được. Theo trải nghiệm của tôi, zed nhanh đến mức gần như không có độ trễ. Editing, lsp, chuyển file đều gần như tức thời. Ngược lại, emacs thì tôi đã nhiều lần bỏ cuộc vì vấn đề độ trễ (đặc biệt trong môi trường phát triển từ xa)
Về câu hỏi liệu plugin chạy trong WASM trên VM có làm chậm hay không, theo những plugin tôi đã xem thì chúng chỉ làm những việc như khởi chạy server, nên không liên quan trực tiếp đến phản hồi khi gõ. Tôi nghi GPU mới là nguyên nhân hợp lý hơn. GPU compositing rất dễ phát sinh độ trễ, lại còn có thể chồng chéo với render ở tầng OS. Tôi nhớ emacs cũng từng dùng mẹo bỏ qua event loop và tự cập nhật UI trực tiếp, dẫn đến một số vấn đề tương thích
Emacs có gói
dape, một debugger dựa trên DAP được thiết kế rất tốt. Liên kết liên quan Nó được thiết kế không có dependency, nên về sau có khả năng được đưa vào emacs mặc địnhCũng có thể là vấn đề ở pipeline render. Bạn đang dùng hệ điều hành nào vậy?
Điều tôi muốn nhắn đội Zed là hãy làm nhận diện ngôn ngữ C và C++ cho đúng. Hầu hết editor đều lặp lại sai lầm là đối xử C như C++ (C khác C++, không nên nhầm lẫn), và ngay cả khi đã chỉ định chuẩn C trong
compile_commands.json, chúng vẫn thường nhận nhầm sang C++ dù mã đó báo lỗi cú pháp C++. Chỉ cần nhận diện ngôn ngữ cho đúng thì đây sẽ là một editor rất tốt