Más notícias, Emacs
Uma mudança controversa no recurso de registradores do Emacs — introduzindo uma etapa extra de confirmação e alterando fluxos de trabalho de teclado antigos — provocou fortes reações entre usuários de longa data. Críticos argumentam que quebrar a memória muscular e não fornecer inicialmente uma forma simples de restaurar o comportamento antigo demonstra desrespeito pela compatibilidade retroativa e pelo ethos de customização extrema do Emacs, enquanto outros respondem que `master` é uma branch de desenvolvimento e que melhorias de UX para usuários mais novos são objetivos legítimos. O debate se expandiu para questões mais amplas sobre governança do projeto, quando é aceitável quebrar interfaces estabelecidas e se tais mudanças deveriam sempre ser opcionais ou opt-in.
O que mudou e por que isso importa
- A mudança afeta os “registradores” do Emacs (recurso avançado de múltiplas áreas de transferência / posição), não o copiar/colar normal.
- O novo comportamento intermedeia uma UI de minibuffer que mostra os registradores e exige um
RETextra para confirmar. - Críticos dizem que isso transforma uma operação rápida, na linha de home row, baseada em memória muscular, em uma modal, mais lenta, usada muitas vezes por minuto.
- Várias analogias: como forçar uma caixa de confirmação após cada
Ctrl-C/colar ou adicionar latência ao instrumento de um músico.
Impacto nos usuários e fluxos de trabalho
- Usuários intensivos de registradores relatam quebra da memória muscular, quebra de macros e carga cognitiva adicional.
- Alguns enfatizam que pequenos atrasos por ação se acumulam muito mal em fluxos de trabalho usados centenas de vezes por dia.
- Outros dizem que registradores são de nicho; muitos usuários antigos mal os utilizam e veem o conflito como exagerado.
- Usuários de não-Emacs no thread usam analogias com Vim e concordam que tal mudança também seria disruptiva em seus editores.
Configurabilidade e necessidade de um fork
- Um lado: em Emacs “tudo é Lisp”, então usuários ou pacotes podem facilmente restaurar o comportamento antigo; um fork rígido é visto como político ou movido por ego.
- Outro lado: fazer monkey-patch do comportamento central é, na prática, manter um fork privado de qualquer forma e transfere o ônus de manutenção para os usuários.
- Há trabalho em andamento em opções/toggles para restaurar o comportamento antigo; algumas propostas anteriores foram rejeitadas por também remover outras novas funcionalidades.
Processo de desenvolvimento e governança do projeto
- Há preocupação de que uma mudança de UX que quebra um comportamento de longa data tenha entrado em
masterapós discussão entre muito poucos desenvolvedores. - Alguns argumentam que é exatamente assim que a branch de desenvolvimento deve funcionar: mesclar, depois refinar ou reverter com base no feedback antes do lançamento.
- Outros veem um padrão de decisões “por fiat”, pouco respeito à compatibilidade retroativa e pouca disposição para reverter.
- Vários კომენტadores observam que o enquadramento do artigo é fortemente unilateral; os tópicos da lista de discussão mostram mais nuance e iteração ativa.
Filosofia de design mais ampla e usuários “novos vs antigos”
- Debate sobre se o Emacs deve otimizar os padrões para iniciantes (descobribilidade, segurança) versus usuários avançados (velocidade, estabilidade).
- Muitos dizem que quebrar décadas de atalhos de teclado deve ser raro, inicialmente opt-in e sempre reversível por uma configuração clara.
- Alguns veem isso como emblemático de uma tendência mais ampla: “melhorias” de UX que desrespeitam a memória muscular em muitos projetos de software.