Microsoft Edit

 (github.com/microsoft)
3 pontos por GN⁺ 2025-06-26 | 1 comentários | Compartilhar no WhatsApp
  • Microsoft Edit é um editor para necessidades simples de edição, que presta homenagem ao clássico MS-DOS Editor enquanto oferece uma interface moderna e controles de entrada semelhantes aos do VS Code
  • O objetivo é oferecer um editor altamente acessível que seja fácil de usar até para usuários pouco familiarizados com o terminal
  • No Windows, pode ser instalado via WinGet; no macOS, via Homebrew; no Linux, quando a distribuição não oferece um binário ou quando se deseja compilar diretamente, pode ser instalado por um script de instalação
  • É construído em Rust, e a configuração com nightly Rust é recomendada por reduzir bastante o tamanho do binário e melhorar levemente o desempenho
  • Gestores de pacotes são orientados a recomendar o nome msedit em vez de edit devido à possibilidade de conflito no nome do executável, e a configuração da biblioteca ICU afeta os recursos de busca/substituição

Objetivo e natureza do Microsoft Edit

  • Edit tem como meta ser um “simple editor for simple needs”, um editor simples para necessidades simples
  • Ele presta homenagem ao clássico MS-DOS Editor, mas oferece uma interface moderna e controles de entrada semelhantes aos do VS Code
  • Busca ser um editor acessível, fácil de usar até para usuários pouco familiarizados com o terminal

Como instalar

  • Os binários podem ser baixados na página de Releases

  • Windows

    • A versão mais recente pode ser instalada com WinGet
    winget install Microsoft.Edit

  • Linux

    • Se a distribuição não fornecer um binário ou se você quiser compilar diretamente, é possível usar o script de instalação
    • Os requisitos são Rust, um compilador C, ICU, curl ou wget, e tar
    • A instalação padrão instala msedit em ~/.local/bin
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh
    • Com flags adicionais, --dev compila diretamente a partir do branch main, e --system instala em /usr/local/bin
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh -s -- --dev --system

  • macOS

    • A versão mais recente pode ser instalada com Homebrew
    brew install msedit

Forma de build

  • Para compilar, é necessário ter Rust instalado e clonar o repositório
  • Ao usar nightly Rust, faça o build de release com o comando abaixo 
    cargo build --release --config .cargo/release.toml
  • Ao usar stable Rust, recomenda-se definir a variável de ambiente RUSTC_BOOTSTRAP=1 e seguir as instruções de build com nightly
    • Esse método reduz bastante o tamanho do binário e melhora levemente o desempenho
  • Para compilar com stable Rust sem configuração adicional, use o comando abaixo 
    cargo build --release

Opções de configuração de build

  • É possível ajustar a configuração por variáveis de ambiente durante o build
  • EDIT_CFG_ICU* está relacionado à configuração dos nomes das bibliotecas ICU, e recomenda-se que gestores de pacotes Linux revisem essa opção
  • EDIT_CFG_LANGUAGES especifica, em uma lista separada por vírgulas, os idiomas a incluir no build

Observações para gestores de pacotes

  • O nome padrão do executável é edit, e o nome alternativo é msedit
  • Como o nome edit pode entrar em conflito com comandos existentes, recomenda-se usar msedit como nome do pacote e do executável
  • Nomes como ms-edit devem ser evitados
  • Se possível, recomenda-se atribuir edit como alias

Configurações relacionadas ao ICU

  • Este projeto depende opcionalmente da biblioteca ICU para os recursos de busca e substituição
  • Por padrão, ele procura os nomes das bibliotecas ICU conforme a plataforma
    • Windows: icuuc.dll, icuin.dll
    • macOS: libicucore.dylib
    • Linux e outros: libicuuc.so, libicui18n.so
  • Se o SONAME do ambiente de instalação for diferente, é necessário definir variáveis de ambiente durante o build
    • EDIT_CFG_ICUUC_SONAME: exemplo libicuuc.so.76
    • EDIT_CFG_ICUI18N_SONAME: exemplo libicui18n.so.76
  • Por padrão, presume-se que os símbolos ICU sejam exportados no formato u_errorName, sem prefixo _ nem sufixo de versão
  • Em ambientes que usam outro formato de símbolo, é possível usar variáveis de ambiente adicionais
    • EDIT_CFG_ICU_CPP_EXPORTS=true: procura símbolos C++ como _u_errorName; no macOS, fica ativado por padrão
    • EDIT_CFG_ICU_RENAMING_VERSION=76: procura símbolos como u_errorName_76
  • Ao definir EDIT_CFG_ICU_RENAMING_AUTO_DETECT=true, o executável tentará detectar em tempo de execução o valor da renaming version
    • Como esse método não é oficialmente suportado pelo ICU, recomenda-se não depender dele
    • No UNIX, exceto no macOS, ele fica ativado por padrão quando não há outra opção
  • Os testes da configuração de build são executados adicionando a flag --ignored a cargo test 
    cargo test -- --ignored

Leituras relacionadas

1 comentários

 
GN⁺ 2025-06-26
Opiniões no Hacker News

  • O interesse foi tão grande que este texto apareceu três vezes em uma semana

    1. O próprio autor - https://news.ycombinator.com/item?id=44034961
    2. Ubuntu Publication - https://news.ycombinator.com/item?id=44306892
      E agora este texto

  • Para o público-alvo deste editor, antes eu recomendava o micro, mas agora fico me perguntando se deveria mudar

    1: https://micro-editor.github.io/

    • Não parece haver necessidade de mudar
      Pelo menos ao testar rapidamente, o edit nem trazia realce de sintaxe por padrão
    • Da última vez que verifiquei, olhando só o tamanho do binário, o micro deveria se chamar macro
    • Também existe o dte. É um editor muito leve, mirando exatamente o mesmo ponto, mas com mais recursos, como suporte a Unicode e atalhos CUA
      Uso como editor de terminal no lugar do nano
      [1]: https://craigbarnes.gitlab.io/dte/
    • O Micro é um excelente editor para substituir algo como o nano. Mas não acho que seja um bom substituto para o edit; o edit é bem básico, enquanto o micro é bastante extensível com Lua
      Ele também lida muito bem com arquivos grandes
    • No Windows, também dá para instalar só com "winget install zyedidia.micro". Lembra aqueles editores de 8 e 16 bits de uma época parecida

  • Fico realmente curioso para saber como um projeto desses é aprovado em uma organização do porte da Microsoft. Será um projeto paralelo de alguns desenvolvedores, ou parte do roadmap de produto?
    Como convenceram a liderança a dedicar tempo a isso?

    • Pelo que foi explicado, era necessário um editor de texto de linha de comando que funcionasse em instalações do Windows Core Server
      Já faz um bom tempo que o Windows inclui um SSH Server, então ele pode ser administrado totalmente só via SSH, e era necessário um editor sem modos que administradores Windows sem experiência com vi também pudessem usar
    • Um editor de texto é um alvo natural demais para integração com o Copilot
    • Cada grupo precisa fazer alguma coisa e acaba tendo ideias. Às vezes elas vêm de uma direção da liderança, como “usem Copilot”, e às vezes de ideias de eventos como hackerdayz que acabam crescendo
      Em organizações de pesquisa, às vezes equipes técnicas começam algo com mais folga; em outros casos, recebem financiamento depois de uma análise profunda e várias revisões
      Pelo número de contribuidores aqui, este projeto provavelmente foi um investimento estratégico. Não surgiu da noite para o dia

  • O edit.com original do DOS 6.22 e depois do 7.0, por volta do Win95, foi meu primeiro IDE. Comecei com qbasic, me acostumei com uma interface parecida ou igual, e continuei usando o edit.com quando aprendi C/C++ com djgpp
    Meu “arquivo de projeto” era um e.bat contendo edit file1.cpp file2.cpp file3.cpp, e eu o usava porque tinha um suporte a múltiplos arquivos bem decente, com alternância fácil via Alt-1,2,3. Até hoje remapeio os atalhos do editor para alternar arquivos com Alt/Cmd-1,2,3, e tento manter o “conjunto ativo” pequeno, com apenas alguns arquivos na frente
    Ele não tinha realce de sintaxe e o comportamento de indentação não era muito bom, então não era um ótimo editor de código. Por isso, no começo da carreira, eu usava indentação de dois espaços, fácil de digitar manualmente e sem parecer tabulação. Mesmo assim, dava uma sensação forte de estar em contato direto com o código
    Eu sabia que muita gente usava editores como qedit, mas, por algum motivo, eles não combinavam comigo; editores no estilo Unix também pareciam estranhos no DOS
    Pelo pouco que testei, parece dar suporte a vários buffers, mas não parece permitir alternar entre buffers com os mesmos atalhos

    • É melhor abrir uma issue sobre isso. Esse tipo de coisa tem chance de ser incorporado se entrar cedo
      E não era apenas parecido; era literalmente igual. O EDIT.COM apenas executava o QBASIC com uma flag especial, e também era possível executar o QBASIC diretamente com essa flag. Como mencionei em https://news.ycombinator.com/item?id=44037509, fiz isso de verdade por diversão
    • Não havia realce de sintaxe, mas, por falta de termo melhor, havia capitalização de sintaxe
      Se você digitasse uma linha inteira em minúsculas e apertasse Enter, ele convertia automaticamente as palavras reservadas para maiúsculas. Não era incrível, mas ajudava
    • Depois da era do copy con, o edit foi realmente uma salvação

  • Gosto de muita coisa aqui. Para começar, a lista de dependências está vazia; só isso já me convence
    Funciona muito bem. É difícil acreditar que criaram uma TUI inteira, com navegador de arquivos e caixas de diálogo, só para isso. Eu gostaria de usar isso nos meus projetos e fico curioso para saber o quão fácil seria. Se alguém envolvido no projeto estiver por aqui, também gostaria de saber por que não usaram Ratatui
    A qualidade do código também é de altíssimo nível, e só posso dizer uma coisa: Bravo!

    • Tirando algumas dependências de desenvolvimento que facilitam os testes, literalmente não há dependências
      Para algo distribuído como ferramenta básica usada por administradores em um sistema operacional como o Windows, é uma escolha razoável. Para entender melhor o contexto de “fazer por conta própria”, veja as respostas de lhecker
      [1]: https://news.ycombinator.com/threads?id=lhecker

  • Cerca de um mês atrás, ouvi dizer que a Microsoft tinha sua própria distribuição Linux para que usuários do Windows se sentissem mais em casa. Pelo que lembro, era uma configuração GNOME bem simples, então não havia nada de especial
    Acho surpreendente que a Microsoft não tenha aproveitado a oportunidade para criar uma distribuição Linux própria da Microsoft, com PowerShell no lugar do bash, Edit junto com opções como vim e nano, e .NET e Visual Studio Code incluídos na instalação para desenvolvedores
    Isso também poderia ter virado a instalação padrão do WSL. Não teria vencido a disputa contra distribuições típicas como Ubuntu ou Debian, mas, como há muitos usuários de Windows, poderia ter conquistado uma certa fatia e se tornado uma opção comum
    A Microsoft não pode dominar o kernel Linux, mas pode controlar o espaço de usuário. Vale imaginar como teria sido se ela tivesse criado um movimento em que seus aplicativos viessem instalados por padrão em distribuições populares
    O Microsoft Edit também pode ser usado no Linux, assim como o PowerShell e outros. Se tivesse jogado bem suas cartas uns 10 anos atrás, a distribuição dela talvez hoje estivesse entre as 5 mais usadas graças a muitos usuários de Windows usando-a via WSL
    Grandes empresas conseguem empurrar suas marcas para dentro do espaço pessoal das pessoas. Agora só falta o Co-Pilot vir ativado por padrão no Microsoft Edit

    • Acho que, com o tempo, há uma grande chance de a Microsoft migrar para Linux. Pelo menos no caso do Windows Server e do Windows embarcado; depois, o Windows desktop também poderia mudar gradualmente ou se dividir em opções como Windows Legacy e Windows “Linux Workstation”
      Poderia ser algo como colocar uma espécie de “super” WINE sobre o kernel Linux e, para certos programas, oferecer como fallback um Windows clássico rodando em uma máquina virtual com integração estreita
      O problema, porém, é que o kernel NT tem muitas partes melhores que o kernel Linux em termos de projeto. Por exemplo, o kernel NT consegue se recuperar mesmo se o driver da GPU morrer completamente, enquanto o Linux parece que teria bastante dificuldade nessa situação. Outros drivers são parecidos
      Mas o Windows está se tornando cada vez mais um passivo do que um ativo para a Microsoft, especialmente na área de servidores. As principais fontes de receita são Azure e Office 365, que ainda crescem em dois dígitos, enquanto o crescimento das licenças do Windows está estagnado
      No mínimo, acho que veremos versões como um Windows Server baseado em Linux e uma Windows Workstation baseada em Linux
    • O motivo de o WSL existir é que desenvolvedores corporativos precisavam de uma forma de executar Linux
      As equipes de suporte de TI e suporte técnico normalmente não conhecem bem Linux e também não querem dar suporte a ele. O WSL resolve esse problema
      A maioria dos desenvolvedores não quer usar Linux em si. Muitos desenvolvedores nem sabem usar direito o terminal e dependem de ferramentas GUI
    • Se parece surpreendente que a Microsoft não tenha criado uma distribuição Linux própria, a última tentativa não foi tão bem. O nome era Xenix
    • Acho que o reconhecimento do nome ajuda. Desenvolvedores não querem instalar uma distribuição de que nunca ouviram falar, mas querem instalar Ubuntu
      Se o WSL oferece suporte ao Ubuntu, consegue aproveitar esse reconhecimento
    • Parece que você confundiu a principal distribuição Linux da Microsoft, Azure Linux (antiga CBL-Mariner), com skins de ambiente de desktop Linux parecidos com Windows que as pessoas vêm criando há muito tempo
      Azure Linux é um sistema operacional com suporte da Microsoft para uso em contêineres, VMs, servidores etc.

  • Isso parece simplesmente um projeto feito “porque deu vontade de tentar”. Eu também já fiz muita coisa assim para entender o que estava acontecendo, então entendo
    Mas reescrever o Turbo Vision em FPC e compilá-lo para vários alvos é algo que existe há uns 20 anos. Turbo Vision talvez seja a melhor biblioteca de janelas em modo texto que existe
    A parte interessante começa quando você consegue mapear a tela inteira de texto para um array assim:
    var
    Screen: Array[1..80,1..25] Of Byte Absolute $B800; // or something like that as i recall
    O que o Turbo Vision trouxe foram janelas modais/não modais móveis. Basicamente, a estrutura ficava reescrevendo esse array continuamente em um loop, e era bem rápida. Ganhei muito dinheiro com essa biblioteca

    • Para quem tiver curiosidade, existe um port moderno de Turbo Vision em C++ que também oferece suporte a Unicode:
      https://github.com/magiblot/tvision
    • Isso não é um projeto feito “porque deu vontade de tentar”. Eles precisavam de um pequeno editor TUI incluído no Windows e que também funcionasse via SSH
      https://news.ycombinator.com/item?id=44034961
    • Mais precisamente, é array[1..25, 1..80] of Word absolute $B800:0000
      Os arrays do TP eram organizados em ordem row-major, e cada caractere era representado por dois bytes. Um era o próprio caractere, e o outro era o atributo (cores de primeiro plano/fundo e piscar)
      Então, uma forma melhor seria array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000
      Em monitores de texto monocromáticos como Hercules (modo 7), bastava trocar $B800 por $B000
    • Fico curioso para saber como você ganhou dinheiro com Turbo Vision. Se não se importar, gostaria que compartilhasse
    • Sempre que vejo um novo framework TUI moderno, a decepção é a mesma: “ah, isto não é tão bom quanto Turbo Vision”

  • Agora estou esperando um EDLIN com suporte a Unicode
    Lembro que era possível fazer pipe de pressionamentos de tecla pela entrada padrão em arquivos batch para automatizar algumas tarefas de edição. Era como substituir parte das funcionalidades de sed ou awk
    Não tentei, mas acho que também deve ser possível com vi. Se isso é uma forma extremamente amaldiçoada ou não, já é outra questão

    • O que você está procurando provavelmente é ed. Dependendo do caso, use com -s

  • Interessante. Sinceramente, não sei bem para quem isso foi feito, mas parece divertido

    • É para quem quer editar arquivos no Windows Terminal. O antigo comando edit não é compatível com o Windows desde 2006, então desde então não havia um editor fornecido pela Microsoft para usar na linha de comando
      É impressionante o quão rápido esse editor é. https://github.com/microsoft/edit/pull/408

      Escrevendo uma rotina SIMD especializada em busca de quebras de linha, dá para chegar a [125 GB/s]

    • Está escrito logo no README:

      O objetivo é oferecer um editor acessível que seja fácil de usar até para usuários pouco familiarizados com o terminal

    • É uma melhoria muito maior do que o Notepad
    • Se tiver, ou vier a ter, suporte a LSP ou busca baseada em ripgrep, eu substituiria o vim de bom grado
      No momento uso o Helix, mas gosto de uma boa TUI
    • É para gente como eu, que não gosta do vi e procura algo mais sensato para substituir o nano no terminal

  • Em 1993, eu costumava abrir arquivos binários no edit e me divertir vendo aparecerem formatos de coração

    • Essa experiência, a visualização do defrag do DOS e editar saves diretamente em hexadecimal são praticamente o motivo de eu ter virado desenvolvedor hoje