Más notícias, Emacs

Problemas na versão 30 do Emacs e o surgimento de um fork

• O branch master do Emacs foi prejudicado por uma mudança significativa, apesar das preocupações de usuários e desenvolvedores.
• Essa mudança tornou a interação com os registradores do Emacs mais inconveniente e passou a exigir teclas adicionais até para tarefas simples.
• Foi criado um fork aprimorado para uso e desenvolvimento, e a participação de pessoas interessadas é bem-vinda.

A estabilidade do branch master do Emacs e as mudanças recentes

• O branch master do Emacs é a versão de desenvolvimento, acompanhada por usuários que querem experimentar as novidades mais recentes.
• Nos últimos anos, graças aos esforços dos mantenedores do Emacs, o branch master vinha sendo muito estável.
• No entanto, uma mudança recente trouxe uma surpresa desagradável para os usuários.

A piora da experiência do usuário e a reação da comunidade

• A nova mudança piorou a experiência do usuário, e cresceram os pedidos para restaurar opcionalmente o comportamento eficiente de antes.
• Apesar da opinião clara dos membros da comunidade, o problema não foi resolvido por causa da postura do desenvolvedor que defendia a mudança.
• Os mantenedores demonstraram uma atitude de insistir na mudança mesmo sacrificando a experiência do usuário.

O desenvolvimento de um novo fork e a liberdade do usuário

• Valorizando a liberdade do usuário, o autor se recusou a aceitar essas mudanças estranhas no Emacs existente e criou um novo fork.
• Esse fork incorpora seletivamente apenas as boas mudanças do branch master e também vem sendo aprimorado pelo desenvolvimento do autor.
• Quem tiver interesse no fork pode cloná-lo do repositório do autor, e colaborações e sugestões são bem-vindas.

Opinião do GN⁺

O ponto mais importante deste texto é a piora da experiência do usuário na versão 30 do Emacs e a reação da comunidade a isso. Como o Emacs é amado há muito tempo entre desenvolvedores por sua capacidade de personalização e extensibilidade, há grande interesse em saber que impacto essas mudanças podem ter sobre os usuários. Além disso, o processo em que um desenvolvedor ignora a opinião da comunidade e impõe suas próprias alterações oferece um caso interessante sobre tomada de decisão e cultura de colaboração em projetos de código aberto. O texto mostra bem como os usuários reagem às mudanças no software e, quando necessário, buscam suas próprias soluções.

[GN⁺]

Comentários do Hacker News

• Quando ocorre uma mudança significativa no branch de desenvolvimento do Emacs e alguns usuários expressam preocupação, essa mudança não é revertida imediatamente. Os prós e contras são discutidos, várias soluções são implementadas e aprimoradas e, por fim, encontra-se um meio-termo.

  • As manifestações de preocupação dos usuários começaram há 3 dias, e esse processo ainda não foi concluído.
  • Na mensagem recente de Eli, é mencionada uma discussão inicial entre duas pessoas de que o novo comportamento é muito mais razoável que o anterior, e fica claro que só agora, depois que outras opiniões foram apresentadas, está sendo discutido qual deve ser o padrão de comportamento.

• Foi aceito recentemente um commit que altera a forma como funciona o copiar no Emacs (ou, mais genericamente, um recurso mais conhecido como "registradores"). Agora o Emacs abre o minibuffer para mostrar o que está acontecendo e exige que o usuário pressione Enter para aceitar a mudança.

  • Isso altera o comportamento padrão, talvez não seja fácil de configurar e aparentemente foi feito sem discussão suficiente.
  • Por meio de uma analogia para usuários de Vim, explica-se o quão incômoda é essa mudança e descrevem-se os esforços do OP para levantar esse problema, bem como a reação do desenvolvedor Thierry.

• Ao revisar a mailing list, parece haver uma opção para reverter esse comportamento.

  • Essa opção foi mencionada antes da publicação do post original, mas o autor pode não tê-la visto.
  • Espera-se que essa opção resolva o problema, mas, segundo a resposta de ginko, ainda pode ser necessário pressionar Enter.

• No Emacs, a memória muscular deve ser considerada um fator importante.

• Do ponto de vista do desenvolvedor, usuários que querem estabilidade devem usar o branch de release ou fixar commits no master. O branch de desenvolvimento é usado para desenvolver recursos em andamento, e às vezes esse tipo de mudança pode acontecer com frequência.

• A postura do autor é um tanto teimosa, e é apontado que pouquíssimas pessoas usam esse recurso. Uma pequena alteração feita por um mantenedor não remunerado sem consultar antes não deveria ser considerada como "quebrar" o branch master.

• Já faz 20 anos que deixei o Emacs, mas entendo que essa mudança seja bastante confusa. Não entendo por que o Emacs, que se orgulha de ser uma "pia de cozinha", não adicionou uma opção para voltar ao comportamento anterior.

• A essência do Emacs é ser uma plataforma altamente personalizável, e, se você não gosta de como algum recurso funciona, pode corrigir isso você mesmo com algumas linhas de código Lisp. Não faz sentido fazer fork do projeto inteiro por causa da mudança de um único recurso.

• Tentar outro fork/reimplementação do Emacs parece ser a única solução. Desta vez certamente vai dar certo e, como todas as outras coisas, não será nem um pouco irrelevante.

• Qual é o argumento do "outro lado" para essa mudança? Alterações que geram esse tipo de opinião normalmente têm um motivo razoável por trás. Ou talvez não.