- Microsoft Edit é um editor de texto simples que presta homenagem ao clássico MS-DOS Editor
- Oferece uma interface moderna e controles de entrada semelhantes ao VS Code
- O objetivo do desenvolvimento é oferecer um ambiente de edição acessível até para usuários sem familiaridade com terminal
- Possui dependência opcional da biblioteca ICU para o recurso de Search and Replace
- Inclui orientações sobre nomes claros de executáveis e opções de variáveis de ambiente para gerenciadores de pacotes
Visão geral do projeto open source
- Microsoft Edit é um editor de texto no estilo clássico para tarefas simples
- Seu diferencial é ser uma releitura moderna do MS-DOS Editor, aplicando uma UI e um modo de entrada familiares no estilo do VS Code
- Foi projetado com foco especial na simplicidade, para que até usuários com pouca experiência em terminal possam usá-lo facilmente
Características e funcionalidades
- Com complexidade mínima, permite realizar tarefas básicas de edição de texto com facilidade
- A interface oferece uma sensação familiar e prioriza acessibilidade e facilidade de uso
- Conta com dependência opcional da biblioteca ICU (International Components for Unicode) para oferecer suporte a Search and Replace
Observações para gerenciadores de pacotes e responsáveis por empacotamento
Nomenclatura de pacotes
- O nome padrão do executável é "edit" e o nome alternativo é "msedit"
- Devido a possíveis conflitos com o comando de sistema existente "edit", recomenda-se usar nomes alternativos como "msedit"
- Recomenda-se evitar nomes como "ms-edit"
Nomenclatura da biblioteca ICU (SONAME)
- A biblioteca ICU pode ser usada para o recurso de Search and Replace
- As bibliotecas procuradas por padrão em cada sistema operacional são as seguintes
- Windows:
icuuc.dll
- macOS:
libicuuc.dylib
- UNIX e outros:
libicuuc.so
- Se o nome da biblioteca (SONAME) variar conforme o ambiente do sistema, é possível configurá-lo por meio de variáveis de ambiente (
EDIT_CFG_ICUUC_SONAME, EDIT_CFG_ICUI18N_SONAME etc.)
- Também há variáveis de ambiente adicionais para casos em que a convenção de nomenclatura dos símbolos exportados pelo ICU seja diferente
Outros
- Há opções adicionais, como detecção automática de renomeação do ICU e suporte a símbolos C++
- Para validar essas configurações, é possível executar testes com o comando
cargo test -- --ignored
Conclusão
- Um editor open source que prioriza simplicidade e acessibilidade, ao mesmo tempo em que permite configuração flexível do ambiente
- Oferece diretrizes claras e alta compatibilidade para desenvolvedores, contribuidores open source e gerenciadores de pacotes
1 comentários
Comentários do Hacker News
A história é que foi um projeto feito simplesmente “porque eu quis”, e eu também me lembro de ter aprendido muito sobre como as coisas funcionam por dentro criando algo desse jeito. Mas uma versão que reescreve o Turbo Vision em FPC e compila com suporte a vários alvos já existe há uns 20 anos. Acho o Turbo Vision a melhor biblioteca de janelas em modo texto. A diversão de verdade começa na parte de mapear a tela de texto inteira como um array. var Screen: Array[1..80,1..25] Of Byte Absolute $B800 Lembro que era algo assim. O que tornava o Turbo Vision realmente inovador eram as janelas móveis modais e não modais. Ou seja, no fim era ficar percorrendo esse array em loop e reescrevendo tudo sem parar. Era bem rápido. Também me lembro de ter ganhado bastante dinheiro com essa biblioteca
Para quem tiver curiosidade, existe uma versão atual em C++ do Turbo Vision, e até um port com suporte a Unicode https://github.com/magiblot/tvision
Os arrays do TP eram row-major. Cada caractere ocupava 2 bytes (letra + atributo). Então até existia a conveniência de usar algo como
array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000. Em displays de texto monocromáticos, bastava trocar$B800por$B000. Por exemplo, em ambientes como HerculesSeria muito bom se no VSCode uma interface dessas funcionasse no terminal, até remotamente
Fiquei curioso sobre como você ganhou dinheiro com essa biblioteca. Queria que contasse o segredo
Sempre que vejo frameworks TUI novos surgindo hoje em dia, penso a mesma coisa: “ainda ficam abaixo do Turbo Vision”
Ao mesmo tempo, estão enfiando trambolhos desnecessários como o AI Copilot à força no Notepad. Pelo que eu lembro, a essência do Notepad era justamente fazer 'uma coisa só' direito, sem nenhum recurso extra
O novo Edit também não escapa desse tipo de decisão. Na era Satya, a MS fingiu gostar de FOSS, mas na época de Gates/Balmer me lembro de a empresa ser muito mais amigável com desenvolvedores Windows. Hoje frameworks web e desktop estão todos misturados, e nem internamente parecem usar isso direito. Em vez dos antigos assistentes e plugins do VS, agora é CLI tool para despejar arquivo do Excel e coisas do tipo. Isso mostra bem a falta de know-how entre gerações na cultura de desenvolvimento para Windows e na gestão
O Raymond Chen já comentou que o Notepad é usado em surpreendentemente muitos testes. A ideia era que, embora simples, ele é usado com frequência para experimentos https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795
Colei uma captura de tela no novo Paint do Windows 11 e, mesmo minimizado, ele continuava usando 5% de CPU e ocupando cerca de 250 MB de memória. RAM até vai, mas desperdiçar CPU desse jeito já é demais. Lembro que antigamente existia orgulho e controle de qualidade
Quando o ISP estava com falhas intermitentes (problema de IPv4/MTU), nem salvar no Notepad funcionava. Só dava para fechar à força. Na época eu estava configurando um desvio temporário com Wireguard
Se você remover o notepad moderno, o notepad antigo também não aparece mais na busca do menu Iniciar
Lembro de ter ouvido, há cerca de um mês, que a MS lançou uma distribuição Linux mais familiar para usuários de Windows. Pelo que recordo, era basicamente um ambiente GNOME simples e não tinha nada de especial. Pelo contrário, já que a MS está criando sua própria distro Linux, poderia ter trocado o bash por powershell, o Edit por vim/nano etc., além de incluir .NET e Visual Studio Code como ferramentas padrão de desenvolvimento... Se a MS tivesse usado isso como distro padrão do WSL, talvez não vencesse a guerra, mas poderia aumentar sua participação entre os usuários. Mesmo sem controlar o kernel, a MS ainda poderia dominar o userland. Muitos usuários de Windows acabariam usando naturalmente as ferramentas da MS como apps padrão instalados. Agora o Microsoft Edit também pode ser usado no Linux. O mesmo vale para outros apps, como o Powershell. Fico imaginando que, se essa estratégia tivesse sido adotada há 10 anos, hoje uma distro da MS poderia estar no top 5 dentro do WSL. É meio desconfortável pensar em grandes empresas (M$) estendendo sua influência até o meu PC pessoal. No fim, fico imaginando o dia em que esse Microsoft Edit virá com Co-Pilot por padrão
Acho que, em algum momento, a MS vai pelo menos migrar gradualmente certas áreas para Linux, começando talvez por Windows Server ou Windows embarcado. No longo prazo, o desktop Windows também deve mudar aos poucos, até surgir algo como as opções ‘Windows Legacy’ vs ‘Windows Linux Workstation’. Imagino uma evolução com kernel Linux + WINE ajustado + alguma VM integrada para legado. O problema é que, em termos de projeto, o kernel NT ainda é superior ao Linux em vários pontos (por exemplo, conseguir se recuperar depois de uma pane completa no driver de GPU). Mas o próprio Windows está se tornando cada vez mais um fardo do que um ativo. Na prática, os motores de crescimento da MS são Azure e Office 365, e as licenças do Windows estão quase estagnadas. No mínimo, dá para esperar um Windows Server e uma workstation baseados em Linux
Azure Linux (antigo CBL-Mariner) é a distribuição Linux oficial da MS feita para contêineres, VMs e servidores. É diferente de uma skin ou ambiente desktop pensado para usuários comuns de Windows
A MS já teve uma distribuição Linux chamada “Xenix”, mas me lembro de que ela não foi muito bem
O WSL surgiu porque desenvolvedores em grandes empresas precisavam cada vez mais de um ambiente Linux. O pessoal de suporte de TI não entende muito de Linux e também não quer dar suporte a isso. O WSL resolve esse problema. Na prática, muitos desenvolvedores não querem usar Linux de verdade e muita gente também não tem intimidade com terminal. Dependem de ferramentas GUI
Parece meio irrealista a MS manter secretamente uma distro própria só para agradar a sensibilidade dos usuários de Windows
Esse assunto está tão em alta que apareceu 3 vezes em uma semana
Antigamente o edit.com (desde o DOS 6.22, depois 7.0/Windows 95) foi meu primeiro IDE. Tudo começou com o qbasic, que era quase o mesmo programa que o edit.com. Mesmo quando aprendi C/C++ com djgpp, continuei usando o edit.com. Meu “arquivo de projeto” era um
e.bat, e eu podia abrir vários arquivos de uma vez com algo comoedit file1.cpp file2.cpp.... Outros editores eram ruins para alternar entre múltiplos arquivos, mas eu gostava de poder mudar direto com alt-1,2,3.... Até hoje, quando troco atalhos de editor, faço questão de manter esse estilo. Embora como editor de código ele fosse bem fraco. Não tinha syntax highlighting, e o suporte a indentação era ruim (por isso no começo eu usava recuo de dois espaços, porque era mais fácil de fazer na mão). Mesmo assim, o feedback imediato no código que eu escrevia e a familiaridade eram excelentes. Existiam editores como qedit, mas não eram do meu gosto; sempre achei os editores do tipo Unix meio ruins no DOS. Esse editor novo até suporta múltiplos buffers, mas aparentemente não adota o esquema de key bindings com o qual eu estava acostumadoSeria bom abrir uma issue sobre isso. Esse tipo de feedback, se enviado cedo, muitas vezes acaba sendo realmente incorporado. E não era só “parecido”: o edit.com era literalmente o qbasic inicializado com uma flag extra. Eu mesmo cheguei a usar o qbasic desse jeito, passando a flag manualmente https://news.ycombinator.com/item?id=44037509
Não havia syntax highlighting, mas havia capitalização da sintaxe (por exemplo, converter automaticamente palavras reservadas para maiúsculas). Se você digitasse uma linha inteira em minúsculas, ao apertar Enter as palavras reservadas viravam maiúsculas automaticamente. Não era grande coisa, mas era bem conveniente
Comparado à época do
copy con, o edit foi realmente um salvadorGostei de muita coisa nisso, por vários motivos. Primeiro, uma lista limpa sem dependências! Fiquei completamente encantado. Não consigo acreditar que construíram toda a TUI do zero só para esse editor. Tem diálogos, navegador de arquivos e tudo mais. Quero tentar aplicar isso no meu projeto também. Se alguém envolvido estiver lendo, eu adoraria saber por que não usaram o Ratatui. A qualidade do código é impressionante. Em uma palavra: Bravo!
Antes eu recomendava o micro[1] para quem procurava esse tipo de editor de texto. Agora estou pensando no que recomendar
https://micro-editor.github.io/
Na minha opinião, não precisa mudar a recomendação. O edit, pelo menos na minha experiência, nem suporta syntax highlighting
Na última vez que conferi, o arquivo binário do micro era tão grande que dava para chamar de macro, não de micro
Existe também a opção dte[1]. Tem suporte a Unicode, key bindings CUA e é bem simples, mas poderoso. Tenho usado satisfeito como editor de terminal no lugar do nano https://craigbarnes.gitlab.io/dte/
No Windows, dá para instalar só com
winget install zyedidia.micro. Ele tem aquela cara de editor da era 8-bit/16-bitFico realmente curioso sobre como um projeto desses é aprovado dentro de uma organização grande como a MS. Queria saber se foi só um side project de desenvolvedor, se fazia parte do roadmap do produto ou se houve todo um processo para convencer a liderança
Um editor de texto é um alvo perfeito para a ofensiva de integração do copilot
Como dá para ver pela explicação da motivação, havia necessidade de um editor que funcionasse na linha de comando (para instalações Windows Core Server), que também pudesse ser usado via SSH (já que o Windows passou a incluir servidor SSH por padrão há alguns anos), e de um editor sem modo para administradores Windows sem experiência com vi. Essas demandas levaram a este projeto
Às vezes cada time precisa cumprir alguma cota e sai propondo ideias; em outros casos vem ordem da liderança (como usar copilot), ou algo começa em eventos tipo hackathon e depois cresce. Em organizações de pesquisa, isso também pode surgir quando gente técnica está sem algo definido para fazer, ou só recebe orçamento depois de uma longa análise. Só de ver o número de committers, isso parece ter sido um investimento estratégico considerável. Não é o tipo de projeto que aparece do nada de um dia para o outro
Eu gostaria que o antigo EDLIN reaparecesse com suporte a Unicode. Com o EDLIN, dava para automatizar certas tarefas em batch file enviando entradas de teclado por pipe de forma scriptável. Era quase um substituto parcial de sed ou awk. Acho que o vi também pode acabar tendo uma arquitetura parecida, embora quão anormal isso seja já seja outra discussão
-s, ele é perfeito para scriptsDiscussão relacionada (271 pontos, 185 comentários) https://news.ycombinator.com/item?id=44031529