micro — uma alternativa moderna ao nano

 (micro-editor.github.io)
2 pontos por GN⁺ 2023-08-19 | 1 comentários | Compartilhar no WhatsApp
  • micro é um editor de texto para uso no terminal que busca começar de forma simples como o nano, mas com controles mais modernos e intuitivos
  • É distribuído como um binário estático sem dependências, reduzindo o esforço de instalação, e oferece tanto downloads oficiais de releases quanto instruções detalhadas de instalação
  • As opções e atalhos de teclado podem ser alterados em formato JSON, enquanto extensões mais avançadas podem ser tratadas com configuração em Lua e plugins
  • Suporta destaque de sintaxe para mais de 75 linguagens, 7 temas de cores padrão, temas em 16/256 cores e truecolor, múltiplos cursores no estilo Sublime e operação com mouse
  • Graças ao emulador de terminal integrado, é possível executar um shell interativo dentro do editor e ver código e bash juntos em tela dividida

micro como editor de terminal

  • micro é um editor de texto baseado em terminal que se apresenta com uma usabilidade moderna e intuitiva
  • A versão mais recente pode ser obtida em Download, e também há instruções detalhadas de instalação
  • Existe um script de terceiros do tipo pipe to shell com curl https://getmic.ro | bash, mas ele não está sob o controle do micro
  • Para facilitar a instalação, é distribuído como um binário estático sem dependências

  • Configuração e extensões

    • A configuração de opções e o remapeamento de teclas usam um formato JSON simples
    • Para configurações mais avançadas, é possível usar Lua
    • Plugins são escritos em Lua, e o gerenciador de plugins cuida do download e da instalação automaticamente

  • Recursos de edição

    • Suporta destaque de sintaxe para mais de 75 linguagens
    • Oferece 7 temas de cores padrão
    • É possível usar temas em 16 cores, 256 cores e truecolor
    • Suporta múltiplos cursores no estilo Sublime
    • Os atalhos de teclado podem ser alterados em bindings.json

  • Mouse e terminal integrado

    • É possível selecionar texto com clique e arraste
    • Clique duplo é usado para seleção por palavra, e clique triplo para seleção por linha
    • É possível executar um shell interativo real dentro do micro
    • Em tela dividida, é possível deixar código de um lado e bash do outro
    • A lista completa de recursos pode ser vista na lista de recursos no GitHub e na ajuda online

Projeto e comunidade

  • Bugs podem ser reportados pelo rastreador de issues do GitHub, e também é possível fazer perguntas ou sugerir novos recursos
  • Pull requests são aceitos
  • Discussões informais sobre o editor podem ser feitas no chat do Gitter
  • Links relacionados:
  • As reações de usuários incluem avaliações de que é um editor que funciona de forma simples, oferece suporte a mouse e pode ser usado no lugar do nano ou do Vim

Leituras relacionadas

1 comentários

 
GN⁺ 2023-08-19
Opiniões do Hacker News

  • Ao ensinar programação na linha de comando em uma turma em que todos são iniciantes, recomendo nano aos alunos.
    Para esses usuários, a maior vantagem do nano é que todos os comandos aparecem na parte inferior da tela, e fiquei surpreso que o micro não tenha isso.

    • A diferença entre micro e nano é que os atalhos de teclado do nano são bem próprios, enquanto o micro segue o padrão usado hoje na maioria dos apps gráficos, como Ctrl+S para salvar, Ctrl+F para buscar, Ctrl+Z para desfazer e Ctrl+Q para sair.
      Na parte inferior da tela também há uma dica de que é possível pressionar Alt+G para ver os atalhos e Ctrl+G para ver a ajuda.
    • A intenção do micro parece estar mais próxima de ser um editor moderno e extensível do que um editor amigável para iniciantes ou disponível em qualquer lugar.
      Nesse sentido, ainda faz sentido recomendar nano aos alunos, enquanto micro parece adequado para quem já aprendeu com nano e quer mais recursos ou uma UI melhor.
    • Parece que pressionar Alt+G abre a tela de atalhos, e Ctrl+G mostra a ajuda.
      Também parece haver algum tipo de modo de comentário.

  • Usei Emacs por mais de 10 anos e agora uso micro como meu principal editor de código. A única exceção é que uso vscode para escrever Coq.
    Vejo o micro como um acme com concessões modernas, e ele tem quase todos os recursos que dão suporte às ideias centrais do acme. Também escrevi um plugin para aproveitar essa direção: https://github.com/xxuejie/micro-acme
    Até agora, ele se encaixa perfeitamente.

    • Hoje em dia uso só cerca de 1% dos recursos do Emacs, então continuo experimentando editores leves de terminal como alternativa ao Emacs, mas sinto muita falta dos modos principais do Emacs comuns para C/C++ etc., especialmente do estilo de indentação.
      Gostaria que outros editores também seguissem a convenção de usar Tab para impor a indentação correta.
    • Pergunto porque não conheço bem o micro: há algum motivo para a velocidade de desenvolvimento ter diminuído nos últimos 1 ou 2 anos?
      https://github.com/zyedidia/micro/tags
    • De forma parecida, migrei do Emacs para o Acme e uso mg no terminal.
      Agora customizei o Micro para deixá-lo com uma sensação de Acme.

  • Eu não sabia que havia gente que usava nano como editor de código principal. Em servidores *nix em que estou trabalhando, uso sempre, e provavelmente já usei dezenas de milhares de vezes.
    Trabalhei por muito tempo como engenheiro Linux/BSD, e alguns lugares se recusavam a instalar nano nos servidores. Há administradores Linux veteranos que não deixam usar absolutamente nada além de vi, e eu não entendo. É um pacote de 20 MB, e a superfície de ataque não é tão grande assim.

    • Veterano, no fim, sempre age como veterano.
      Sempre acho engraçado quando você pergunta a alguém da geração anterior que tipo de sistema ele administrava, e a pessoa fala, meio se gabando, que cuidava de todo o departamento de TI do governo local, e que era uma cidade razoavelmente grande, com pelo menos uns 500 usuários.
      Tenho 105% de certeza de que aquele sistema era o mais seguro de todo o condado, mas ao mesmo tempo provavelmente era um sistema inutilizável. Quando essa pessoa se aposentar, ou quando alguém no escritório finalmente a remover em desespero, espero que ela seja substituída por um engenheiro mais moderno que, mesmo não sabendo vi, se importe um pouco com os usuários. Claro que nós também somos engenheiros, então não vamos nos importar tanto assim.
    • O principal motivo para um administrador Unix conhecer vi a fundo é que ele é o mínimo denominador comum em sistemas Unix e Linux.
      Trabalhando como profissional de *nix, você pode ter que lidar com sistemas como QNX, HP-UX, supercomputadores SGI Altix e Sun Ultra 2. Linux era fácil porque tinha gerenciamento de pacotes de software livre/open source, e antes de nano se popularizar, também era comum Emacs vir na configuração padrão.
      Às vezes havia problemas de terminal e você precisava trabalhar vendo só uma linha; aí era preciso operar o vi no escuro ou usar sed/awk. Talvez por isso ainda exista esse instinto KISS de fazer todo mundo aprender vi. Eu também aprendi assim.
      Um editor não cria uma grande superfície de ataque, mas eu não descartaria a possibilidade de um invasor abusar do recurso de plugins como meio de garantir persistência. Ao executar como root, ele provavelmente se comportaria de outro modo, mas talvez não em contas de serviço.
    • Para algo supostamente de 20 MB, o executável do nano tem 277 KB, e o pacote .deb inteiro tem 860 KB.
      https://packages.ubuntu.com/jammy/nano
    • Eu era usuário de nano originalmente, mas fui pressionado pelos veteranos a usar vim, e hoje só toco no nano quando preciso arrumar meu arquivo vimrc.
      Na época fiquei irritado, mas agora estou satisfeito por ter mudado. Vim ou vi está em todo lugar, incluindo os switches e roteadores em que trabalho. nano não está em todo lugar, nem é algo que dê para colocar facilmente em qualquer lugar.
      Acho que eu teria percebido menos essa vantagem se não acessasse regularmente via SSH hardware antigo ou com poucos recursos.
    • Pessoalmente, detesto muito o nano, então escolheria vi a qualquer momento.
      Dito isso, a escolha de editor de texto é algo muito pessoal. Não faz nenhum sentido alguém obrigar outra pessoa a usar ou não usar um editor específico. É só deixar a pessoa usar o que gosta.

  • O JOE é bem decente: https://joe-editor.sourceforge.io/
    É uma mistura de WordStar e Emacs e, quando executado como jstar, oferece uma experiência bem autêntica de WordStar, mantendo também um clima dos primeiros IDEs Borland Turbo

    • Eu gostava muito do JOE. Talvez fosse porque ele tinha vestígios do WordStar
      Ainda hoje escrevi um texto sobre como usar as teclas WordStar Diamond no Linux: https://benhoyt.com/writings/wordstar-diamond/
    • Meu primeiro processador de texto foi o WordStar no CP/M, e meu primeiro ambiente de programação foi o Borland Turbo Pascal
      Mais tarde também usei o QEdit, que podia ser configurado para usar as teclas do WordStar
      Quando migrei do DOS para o Unix no começo dos anos 90, fiquei feliz ao descobrir o JOE. É o primeiro programa que instalo em uma nova máquina Linux ou *BSD, ou em uma VM
      Hoje em dia o JOE tem realce de sintaxe e vários bons recursos, então nunca senti necessidade de ficar proficiente em vi ou emacs
    • Tenho boas lembranças de usar joe nos anos 90 para quase tudo, exceto editar código
      Ele não era muito bom para edição de código, porque ficava mais próximo de um modelo de processador de texto, com quebra automática de linha e falta de realce de sintaxe
      Mas, para escrever documentos de texto, era um editorzinho adorável
    • Será que as diferenças entre modos e os atalhos de teclado não estão documentados no manual?
      Talvez eu não tenha encontrado, mas realmente não vejo isso
    • Costumo executá-lo como jmacs para usar o conjunto de atalhos de teclado do Emacs

  • Gosto do micro e uso todos os dias
    Mas, depois de experimentar o Helix, passei a querer uma versão do micro com treesitter, LSP e ajuda contextual integrados. O Helix realmente acertou nesse pacote de recursos, mas é difícil migrar porque o “modo único + comandos” e a memória muscular de Ctrl-C/Ctrl-V são confortáveis demais

    • Venho usando o Helix diariamente há uns 6 meses, e gosto muito do fato de ele ser um editor com os recursos básicos todos incluídos. É um excelente editor

  • Não entendo por que ainda existe software dizendo para executar com sudo algo baixado da internet
    Há opções mais fáceis, seguras, com instalação menor e integradas a todas as distribuições; então fico me perguntando por que fazem as pessoas usarem esse tipo de script
    Para comparar, o pacote micro do Alpine ocupa 4 MB depois de instalado, enquanto o binário estático compilado baixado do GitHub tem 11 MB. Acho que usar o pacote do repositório é mais no espírito do micro

    • Ele realmente faz você executar sudo?
      Olhando https://github.com/zyedidia/micro#quick-install-script, o script de instalação rápida é curl https://getmic.ro | bash, e o script coloca o binário do micro no diretório atual
      Depois, se quiser, você pode movê-lo para um diretório no PATH, e eles dão sudo mv micro /usr/bin como exemplo. Só estão avisando que é preciso sudo para mover para /usr/bin; fico me perguntando se isso é mesmo um problema
    • Recomendar canalizar uma fonte qualquer da internet para sudo ou (ba)sh é completamente irresponsável
      Também estou cansado da justificativa ridícula de que “todo mundo faz assim”
    • Pessoalmente, não quero um intermediário entre mim e o desenvolvedor do aplicativo
      Quero receber o aplicativo diretamente do desenvolvedor. Assim posso saber que estou usando uma versão oficialmente suportada e que ninguém mexeu no código
      Se eu não confio no desenvolvedor do aplicativo, simplesmente não instalo

  • Eu achava que o Nano era a alternativa moderna ao Pico

  • Fico curioso por que as pessoas se interessam por esses editores pequenos
    O único motivo para usar vi/vim é que ele está em todo lugar. Se for para instalar um editor, eu instalaria o Emacs
    Se for um sistema remoto, abro arquivos via SSH com tramp, mantendo toda a potência e velocidade do Emacs local. Para edição em UI de terminal, como sudoedit, git commit e C-x C-e, deixo o Emacs rodando como daemon, então um novo frame, até um frame de terminal, abre instantaneamente; com nerd font e cores, fica quase igual ao Emacs GUI e é literalmente Emacs
    Não há necessidade de ter vários editores para usos diferentes

    • Uso Linux há mais de 20 anos, mas nunca consegui entender vi direito e ele me parece pouco intuitivo
      O Emacs era mais atraente para mim e, quando acesso por ssh um dispositivo de baixo consumo, como um roteador rodando OpenWRT, não há Emacs, então uso o Nano, que parece intuitivo entre os editores disponíveis
      Sei que também poderia usar Emacs e TRAMP, mas cada um acaba tendo seu próprio fluxo de trabalho. Não estou tentando desmerecer o vi; é bem conhecido o fenômeno de alguns hackers não conseguirem se sentir à vontade com ele
    • Nem todo mundo está interessado em um editor enorme e uma curva de aprendizado íngreme
      Algumas pessoas só querem editar um arquivo rapidamente
      Dá para usar com o conhecimento que já se tem do Windows Notepad ou do Mac SimpleText, e ele funciona mesmo em situações em que há apenas um console Unix de uma máquina quebrada ou de um servidor
    • Não é que eu tenha interesse nesses editores pequenos em si
      Mas tenho bastante interesse em editores pequenos como o nano. O motivo está neste comentário raiz: https://news.ycombinator.com/item?id=37173126
      O primeiro parágrafo daqui também vale como referência: https://linuxize.com/post/how-to-use-nano-text-editor/
      Para os administradores de sistemas de hoje que não cresceram com vi ou vim e também não escolheram o campo do emacs, incluir o nano em imagens de distribuição em massa é uma escolha educada
    • Todos os sistemas operacionais que encontro têm Nano
      Também não edito coisas remotamente com frequência; normalmente são apenas arquivos de configuração simples
      Já usei o micro e gostei, mas ele não abriu de imediato no Pi, e não faço trabalhos grandes o bastante no editor de linha de comando para realmente precisar de seus recursos
    • O motivo para eu usar micro foi que consegui desenvolver plugins personalizados sem muito esforço e distribuí-los facilmente, apenas copiando, para sistemas que não tinham um bom editor de terminal
      Normalmente prefiro vim, mas o esforço para distribuir uma boa configuração para os sistemas-alvo é grande demais

  • O problema que tive no micro foi com colagem formatada
    Ao colar um trecho de código, o micro tentava indentar cada linha, mas, como não conhecia o contexto completo, a indentação do texto colado ia ficando cada vez mais profunda, infinitamente
    O processo também ficava quase travado de tão lento, tentando inferir a formatação linha por linha. Em vez de colar e ficar vendo uma cena estilo Matrix, eu acabava indo buscar café
    Espero que tenha sido resolvido, mas foi quando abandonei. Se tiver sido corrigido, posso tentar de novo

    • Dá para desativar: Ctrl+E e depois set autoindent off
      https://github.com/zyedidia/micro/blob/master/runtime/help/o...
      Ainda assim, mesmo ativado, ao colar um bloco inteiro ele deveria indentar corretamente
      Se você compartilhar as configurações, o ambiente e a configuração geral, posso tentar criar um patch
    • Isso aconteceu comigo uma vez usando no Windows com Wezterm
      Depende da forma como você cola. Não tenho 100% de certeza de como funciona exatamente, mas parece que o micro reimplementa a colagem diretamente com xclip, e não sei o que ele faz no Windows
      Se você cola com Ctrl+V, ele insere imediatamente o conteúdo da área de transferência como um bloco e copia a indentação original. Se usa Ctrl+Shift+V, em alguns casos o terminal trata a área de transferência como se os caracteres fossem chegando um por um; ao ver um caractere de retorno sem saber qual será o próximo, ele adiciona indentação extra e depois ingenuamente coloca mais alguns tabs por cima

  • Entre outras 14 submissões, a de 2020 teve 103 comentários, e a de 2021 teve 162 comentários
    [0]: https://news.ycombinator.com/item?id=23334190
    [1]: https://news.ycombinator.com/item?id=29128702