- O recurso de depuração finalmente foi implementado no Zed após pedidos de mais de 2.000 desenvolvedores
- O debugger foi projetado com foco em velocidade, familiaridade e configurabilidade
- Há suporte para linguagens populares como Rust, C/C++, JavaScript, Go e Python, além de extensões baseadas no Debug Adapter Protocol (DAP)
- Com o sistema intuitivo de LOCATORS, é possível depurar a maioria dos projetos com facilidade, sem configuração separada
- A arquitetura separada entre UI e camada de dados estabelece uma base excelente para depuração colaborativa e extensibilidade
Lançamento do debugger do Zed
- O recurso oficial de depuração foi adicionado ao editor Zed em resposta aos pedidos de mais de 2.000 desenvolvedores. Este é um avanço muito importante no caminho rumo ao Zed 1.0
Objetivos principais
- Velocidade: oferecer transições rápidas de contexto e uma experiência eficiente de depuração
- Familiaridade: harmoniza com a linguagem de design do Zed e oferece todos os recursos esperados de um fluxo típico de debugger
- Configurabilidade: o usuário pode personalizar livremente UI, atalhos de teclado e configurações de depuração
Suporte a linguagens e extensões
- Suporte nativo a linguagens principais como Rust, C/C++, JavaScript, Go e Python
- Pode se integrar com qualquer adaptador de depuração que implemente o Debug Adapter Protocol (DAP)
- O sistema de extensões permite adicionar com facilidade uma variedade maior de linguagens e recursos de depuração
Configuração simples de depuração
- Foi introduzido um novo sistema chamado LOCATORS, que converte configurações de build em configurações de depuração
- Depois de definir uma tarefa de build em
tasks.json, é possível referenciá-la em debug.json ou usar o recurso de configuração automática do Zed
- O Zed executa automaticamente locators a partir de executáveis embutidos ou fornecidos pelo Language Server
- Na maioria dos casos, é possível usar imediatamente sem configuração extra de depuração
- No momento, há suporte de locator para Cargo, Python, JavaScript e Go (mais linguagens estão previstas)
Recursos das sessões de depuração
- Dentro do Zed, é possível verificar facilmente o estado do programa, incluindo threads, variáveis, breakpoints e call stack
- O painel do debugger é totalmente personalizável, permitindo arrastar e reordenar abas ou mover painéis livremente
- Também há suporte para depuração centrada no teclado, permitindo navegar pelo código, alternar breakpoints e mudar de sessão sem usar o mouse
Arquitetura altamente extensível
- Foi projetada uma arquitetura em duas camadas para permitir depuração em várias linguagens, ambientes colaborativos, suporte a extensões e cache/gerenciamento eficiente de dados
- Camada de dados: comunica-se diretamente com o adaptador de depuração, mantém o estado da sessão, armazena respostas em cache e gerencia a invalidação de dados antigos
- Camada de UI: solicita apenas os dados necessários e se concentra na renderização da interface
- Graças a essa separação, fica mais fácil implementar depuração colaborativa (multiplayer), além de aumentar a economia de largura de banda de rede
API de extensões e aplicação do DAP
- Como existem mais de 70 implementações diferentes de DAP, em vez de oferecer suporte nativo a todas, o Zed tornou possível a integração de debugger ao expandir a API de extensões do Zed
- É possível ampliar o suporte a DAP com definição direta de schema, implementação da lógica de download e execução de adaptadores, injeção de valores padrão em configurações de depuração, integração automática com locator etc.
- De forma semelhante ao modelo de extensões de LSP (Language Server Protocol), desenvolvedores podem integrar facilmente seus próprios adaptadores de depuração ao Zed
Suporte a valores inline de variáveis
- O recurso de exibir valores inline de variáveis pertence ao LSP, não ao DAP, então só pode ser oferecido da forma tradicional quando DAP e LSP estão ambos integrados
- Correspondências simples por expressões regulares têm baixa precisão devido a problemas com escopo, comentários etc.
- Com uso de Tree-sitter, a identificação de variáveis dentro do escopo do código em execução é feita com mais precisão
- É possível oferecer suporte por linguagem via arquivos
.scm, sem integração separada com LSP
- No lançamento, há suporte para Python, Rust e Go, com mais linguagens previstas depois
- O Zed é um editor criado pelos fundadores do Tree-sitter
Próximos planos
- Novas views: estão previstos recursos avançados como watch list, memory view, disassembly view e stack trace
- Configuração automática: o objetivo é expandir o suporte de configuração automática para mais linguagens e sistemas de build
- Refinamento e expansão: a equipe pretende receber feedback via Discord, GitHub etc. e melhorar ativamente o produto
Apêndice
- O Zed está disponível para macOS e Linux
- Estão contratando desenvolvedores (se tiver interesse, consulte o site oficial)
2 comentários
Será que tem alguém usando o Zed com Java...? haha
Comentários no Hacker News
Fico realmente feliz em ver que estão trabalhando em um depurador. Esse recurso é justamente o principal motivo que me impede de migrar completamente para o Zed. Dito isso, ainda falta um pouco para eu poder dizer “agora sim”. Sinto falta de uma janela de watch, da visualização de stack trace e de qualquer menção a data breakpoints, então ainda considero isso em beta. Sei que esses recursos devem ser adicionados em algum momento, mas o que existe hoje não é suficiente para cobrir 97% das minhas sessões de depuração. Também gostaria que o anúncio mencionasse com mais clareza suporte a várias sessões de depuração ao mesmo tempo e os planos para depuração multithread. Em especial, fiquei curioso sobre ideias interessantes para depuração multithread, como “congelar” uma thread específica ou deixar só uma rodando em modo “solo”, como no RemedyBG
Olá, Laserbeam, eu desenvolvi o depurador e sou o autor do post. Já temos suporte a uma visualização básica de stack trace. Em breve, uma visualização de stack trace dentro do sistema de múltiplos buffers será introduzida, e hoje já dá para expandir o call stack em um multi-buffer durante uma sessão de depuração com a ação “show stack trace” para ver cada frame. Só não divulgamos isso publicamente porque ainda não atinge o padrão de qualidade elevado do Zed. O PR para watch de variáveis/expressões também deve ser mergeado em poucos dias. A funcionalidade já está pronta, mas fiquei receoso de incluir algo que não tivesse sido suficientemente testado tão perto do lançamento. Data breakpoints são uma prioridade importante, mas por um tempo vamos focar em configuração automática, então é difícil dar uma previsão exata. Também já há suporte simultâneo para múltiplas sessões e depuração multithread; ainda há pontos a melhorar, mas o suporte básico existe
O post do blog menciona que visualizações avançadas estão em desenvolvimento. Este primeiro lançamento e anúncio estão focados em estabelecer a base. No futuro, devem ser adicionadas visualizações avançadas como lista de watch, memory view, disassembly view e stack trace view [link relacionado]
Minhas sessões de depuração sempre consistem apenas de breakpoints normais e stepping. Então, para mim, já é suficiente
Também concordo, mas vendo a velocidade com que a equipe do Zed desenvolve as coisas, tenho a sensação de que esses recursos devem chegar em breve
Ainda não usei o depurador, mas no meu caso sinto algo parecido por causa dos recursos de Git. O Zed já tem funções básicas de Git, mas ainda não é suficiente para substituir todo o meu workflow atual. Espero que continuem investindo no desenvolvimento dessa parte também
O Zed é realmente um editor muito bom. Recentemente venho migrando do neovim para o Zed e estou bastante satisfeito. Tudo é muito rápido e os bindings de vim estão bem integrados. O modo agente também é conveniente. Em comparação com o VSCode, o ecossistema de extensões ainda deixa a desejar, mas cobre bem muitas das tarefas de que preciso. O depurador era uma grande lacuna até agora, então fico muito feliz com essa adição
Fico curioso sobre o quanto os bindings de vim realmente parecem vim. A maioria dos emuladores de vim é parecida o bastante, mas ao mesmo tempo ambígua demais, então acabo errando teclas com frequência e isso é ainda mais frustrante. Às vezes tenho a sensação de que um editor que não parece nada com vim incomoda menos do que ficar com os dedos “errando” o tempo todo
Tenho curiosidade sobre como está o autocompletar para código Rust no Zed. Seria ótimo se existisse um ambiente mágico como Windsurf ou Cursor, em que tudo é completado de forma natural no estilo “tab-tab-tab”. Principalmente em TypeScript ou linguagens de script, esse tipo de autocompletar funciona quase como automação de refatoração. O IntelliJ/RustRover, mesmo usando modelos da JetBrains ou Co-pilot, não conseguiu chegar ao nível de Cursor ou Windsurf. Acho que isso tem a ver com a própria natureza do Rust. 1) Queria saber se esse tipo de autocompletar natural já passou a ser possível em Rust, e se funciona no Zed. 2) Também queria saber como isso se compara a Zed, Cursor e Windsurf, e ainda ao jeito como o RustRover e a JetBrains lidam com a AST do Rust
O Zed parece ter realizado o que Lapce, Helix e Neovim não conseguiram até agora. Quando usei o Helix por volta de 2021~2022, acabei desistindo por causa de bugs e falta de integração, e principalmente porque quase não havia suporte para PHP, que eu usava no emprego anterior. O Neovim foi o mais confortável, mas muitos plugins famosos da comunidade tinham um estilo muito rígido, enquanto os plugins alternativos eram lentos demais. Era cansativo ter que ponderar tantas opções só para montar um ambiente estável. O Lapce me pareceu apenas uma “cópia do VSCode”, e não senti nada de especial nele. Ainda acho que não está no nível de servir como editor principal no dia a dia. Nesse sentido, o Zed se tornou o melhor editor em pouco tempo, e ultimamente sinto gratidão por ele todos os dias. Também fico muito feliz com a adição do depurador
A explicação “que eu usava no emprego anterior” sobre o suporte a PHP nem era necessária
Também acho interessante chamar isso de “cópia do VSCode”. É uma interpretação divertida do editor mais popular da história da humanidade
Estou impressionado com o quanto o Zed está evoluindo para um IDE leve, cheio de recursos e cada vez mais completo. Na minha opinião, DAP e LSP são as melhores inovações que aconteceram nas ferramentas de programação na última década
No começo eu tinha interesse no Zed, mas fui perdendo a vontade conforme começaram a integrar “IA”. Cheguei a um ponto de cansaço com tanto “IA” por toda parte. Pretendo continuar usando Neovim até aparecer algo melhor, e acho que esse tipo de mudança só vai acontecer depois que a “bolha da IA” estourar
O Zed foi o primeiro editor que realmente me deu vontade de usar recursos de IA. No geral, ele passa uma sensação de base muito sólida, e a parte de IA existe mais no nível de autocompletar que se vê em outros editores. A impressão é algo como: “o que você quer não é IA, e sim um bom editor rápido; nós fizemos isso e também colocamos recursos de IA”. Já os concorrentes parecem transmitir a ideia de “nós somos IA em primeiro lugar e o editor é só um acompanhamento”, enquanto no Zed o foco é outro
Fui olhar o neovim e me surpreendi ao ver que ele até recebe patrocínio de dois produtos de IA. Não chega ao ponto de integrar IA diretamente, mas parece que está ficando cada vez mais difícil evitar isso completamente
Eu simplesmente deixo todas as opções relacionadas a IA desativadas. É um editor bem bom. Ainda preciso abrir o VSCode para resolver merge conflicts, mas no geral estou satisfeito
Fico curioso sobre o quanto os recursos de IA do Zed são realmente intrusivos e se podem ser desativados nas configurações
No uso normal do Zed, os recursos de IA não incomodam em nada. Às vezes são úteis, mas não costumo usá-los com frequência
Desde que saiu o suporte a Linux, fico sempre verificando se já adicionaram suporte a displays comuns (LoDPI). É frustrante que isso ainda não exista
É realmente uma situação irritante. Renderização de texto é algo básico para um editor de código, mas parece que ninguém da equipe do Zed usa telas comuns (non-retina). link para issue no GitHub
Como paliativo, se você instalar o BetterDisplay (ferramenta gratuita) e converter a tela LoDPI para HiDPI, a renderização de texto fica aceitável
Eu uso todos os dias em uma tela de notebook Linux 1920x1200 e não vejo problema algum
Sem suporte a Windows e, no Linux, sem suporte a telas comuns, isso não faz da empresa algo essencialmente centrado em Mac?
No momento, quero migrar do Cursor para o Zed em um projeto Python usando Pyright, mas o consumo de bateria está alto demais para justificar. Essa issue já existe no GitHub, e acho uma pena que a equipe não esteja tratando isso como prioridade mais alta
Acho que o Zed é um verdadeiro exemplo de desenvolvimento de produto. É muito bom ter uma opção que não seja apenas mais uma reembalagem do motor do Chrome
Sinceramente, fiquei surpreso porque há partes lentas. Há atraso ao trocar de arquivo pela lista de abas, e a resposta da digitação é mais lenta do que no Emacs (com lsp-mode ativado) ou até em um navegador web. Também usa cerca de 60 MiB a mais de memória que o Emacs. Em compensação, a inicialização é realmente rápida. Ao contrário do slogan de “editor rápido”, está mais lento até do que Emacs Lisp + núcleo em C. Dei uma olhada na estrutura de plugins e parece que eles são compilados em WASM e executados em uma VM. Fico curioso se esse é o motivo
Fico curioso para saber como o zed conseguiu ficar mais lento que o emacs. Na minha experiência, o zed é tão rápido que parece quase sem latência. Edição, lsp e troca de arquivos são instantâneos. Já o emacs, por outro lado, eu muitas vezes acabei abandonando justamente por problemas de latência, especialmente em ambientes de desenvolvimento remoto
Sobre a pergunta se os plugins ficam mais lentos por rodarem em WASM dentro de uma VM: os plugins que eu vi basicamente só fazem coisas como iniciar servidores, então isso não parece ter relação direta com a resposta da digitação. Eu chutaria que o problema está mais ligado ao uso de GPU. É fácil aparecer latência com composição por GPU, e isso ainda pode se sobrepor à renderização já feita pelo sistema operacional. Também lembro que o emacs usava truques para atualizar a UI diretamente, pulando partes do event loop, o que acabava causando problemas de compatibilidade
O emacs tem o pacote dape, um depurador bem projetado baseado em DAP. link relacionado Ele foi projetado sem dependências e pode acabar entrando no emacs padrão no futuro
Pode ser um problema no pipeline de renderização. Fico curioso sobre qual sistema operacional você está usando
O que eu gostaria de pedir à equipe do zed é detecção adequada de linguagem para C e C++. Todo editor repete o erro de tratar C como se fosse C++ (C é diferente de C++ e não deve ser confundido). Mesmo quando o
compile_commands.jsonespecifica o padrão de C, muitas vezes o editor reconhece como C++ só porque o código tem um erro de sintaxe típico de C++. Se a detecção de linguagem for corrigida, já será um editor muito bom