Más notícias, Emacs

• Era um texto crítico sobre as mudanças no recurso de registers do Emacs 30, mas no corpo atualmente público o conteúdo original foi removido
• O texto original foi apagado por tratar o desenvolvimento recente do Emacs de forma excessivamente crítica e por ser indelicado com as pessoas envolvidas
• Para verificar o conteúdo removido, resta apenas a orientação de procurar o log do Git no site do autor
• O ponto principal que permanece é que o autor passou a usar no dia a dia um branch um pouco diferente do Emacs
• Apenas com o corpo atualmente público, é difícil confirmar as mudanças específicas no recurso de registers do Emacs 30 ou as questões técnicas envolvidas

---

Texto crítico sobre o Emacs 30 que foi removido

• O texto original tratava de mudanças no recurso de registers do Emacs 30 que o autor considerava uma piora
• No corpo público, permanece a justificativa de remoção: o texto criticava excessivamente o desenvolvimento recente do Emacs e era indelicado com as pessoas relacionadas
• Também é mencionado como contexto da remoção o fato de o texto ter recebido muito mais atenção do que posts anteriores do blog

Informações que ainda podem ser verificadas

• Se você realmente quiser ler o texto removido, pode consultar o log do Git deste site
• O autor afirma que começou a usar no dia a dia um branch um pouco diferente do Emacs
• O corpo público atual não inclui o problema concreto das mudanças no recurso de registers do Emacs 30, exemplos ou conteúdo de patches

[GN⁺]

Opiniões do Hacker News

• Quando uma mudança que quebra compatibilidade entra no branch de desenvolvimento do Emacs, intencionalmente ou não, e alguns usuários expressam preocupação, o processo não é simplesmente revertê-la de imediato
  É preciso discutir prós e contras, implementar e aprimorar várias soluções e então encontrar um compromisso. Como faz apenas 3 dias que os usuários levantaram preocupações, é difícil dizer que esse processo já deveria ter sido concluído
  A resposta recente de Eli também tinha o sentido de que “as duas pessoas que participaram da discussão inicial consideraram o novo comportamento muito mais razoável do que o antigo, mas agora que também surgiram opiniões contrárias, podemos continuar discutindo o comportamento e depois falar sobre o padrão”
  Acho que há problemas sérios no modo de desenvolvimento do Emacs, mas também é um problema quando usuários normalmente culpam as pessoas teimosas da emacs-devel e, quando entra uma mudança de que não gostam, agem como se fosse o fim do mundo. Isso deixa os mantenedores na defensiva

  • Não faz sentido fazer escândalo por surgir uma mudança que quebra compatibilidade ao usar o branch de desenvolvimento. Nesse branch, esse tipo de coisa é previsível
    Lendo a thread de e-mail, isso parece mais uma divergência forte do que “arrogância”, e chegar a um consenso inevitavelmente leva tempo. Chamar alguém publicamente de “arrogante” porque a pessoa não recua imediatamente para o seu ponto de vista, e tentar mobilizar uma multidão que nem vai ler a thread, parece quase assédio
    Além disso, não é honesto dizer que o patch que tornava a mudança opcional foi ignorado. Aquele patch não apenas adicionava uma opção; ele também removia outras mudanças, e foi rejeitado por isso. Colocar a responsabilidade em uma pessoa desse jeito também é difícil de aceitar
  • Parece contraditório dizer que “a reação dos usuários é um insumo central para a decisão final” e, ao mesmo tempo, criticar reações negativas dos usuários como “exageradas”
    Se os usuários não tivessem reagido, pelo procedimento descrito, é bem provável que a mudança original à qual eles se opuseram tivesse entrado do jeito que estava. No clojure-mode também, rms tentou pegar o nome do autor da comunidade Clojure que o mantinha havia muito tempo e reescrevê-lo; as pessoas protestaram na lista e isso foi barrado, mas essas mesmas pessoas ouviram que estavam exagerando. Por isso, a crítica de “exagero” não parece ter muito significado
  • Este é um processo ruim. A revisão de uma funcionalidade deve começar antes de ela ser mesclada ao branch principal, não depois
    Se uma funcionalidade que quebra o fluxo dos usuários é colocada no branch principal sem discussão com a comunidade mais ampla, é natural que as pessoas fiquem irritadas. Esse tipo de merge é como ferramentas antigas perdem o apoio da comunidade
  • A comunidade Emacs, ao menos historicamente, sempre deu enorme importância à compatibilidade retroativa. Quebrar usuários existentes é praticamente uma das piores coisas no Emacs
    Se reverter imediatamente uma mudança que quebra compatibilidade não é considerado com seriedade, isso sinaliza que os desenvolvedores do Emacs já não valorizam a compatibilidade retroativa tanto quanto antes, o que significa abandonar uma parte considerável dos usuários existentes
    https://www.murilopereira.com/the-values-of-emacs-the-neovim...
    Valores fundamentais importam. Os mantenedores do Emacs violaram valores fundamentais, e a comunidade tem razão em ficar incomodada
  • Pela explicação do texto, fico preocupado com a saúde do Emacs. Já havia controvérsia antes de ser mesclado ao master, mas mesmo assim foi simplesmente mesclado
    Quebrar o fluxo de trabalho dos usuários sem nem tornar isso opcional, sem ser opt-in e sequer permitindo desativar, parece uma negligência indiferente com a experiência do usuário

• Resumindo o que entendi: recentemente foi aceito no Emacs um commit que altera o comportamento de registradores, algo um pouco mais geral do que copiar
  Agora o Emacs abre um minibuffer mostrando o que está acontecendo, e é preciso aprovar a alteração com Enter ou uma entrada equivalente. O autor do post original vê isso como uma quebra terrível de compatibilidade, por mudar o comportamento padrão, talvez não ser fácil de desativar por configuração e não ter havido discussão suficiente
  Fazendo uma analogia com o Vim, seria como digitar "dyy para copiar a linha atual para o registrador d e, em seguida, ele abrir um buffer scratch mostrando o texto e o buffer e exigir uma tecla para fechar. Para um usuário comum de Vim que entende registradores, isso seria horrível, embora também existam pessoas que preferem um comportamento que “mostre explicitamente o que está sendo copiado”, como quem copia no modo visual
  O restante do texto diz que o autor original tentou provocar uma discussão, mas Thierry, o autor do commit, a bloqueou, e que, implicitamente, o restante da comunidade de desenvolvimento do Emacs também tem responsabilidade

  • Registradores são um recurso relativamente avançado e usados principalmente para edição rápida. São mais voltados a pessoas que digitam operações complexas rapidamente do que a usuários iniciantes que usam mouse
    Uso Emacs há décadas, mas nunca me aprofundei muito em registradores; pessoalmente, uso kill/yank para copiar e cursores múltiplos ou macros de teclado pontuais para edições complexas. Ainda assim, o Emacs tem muitos recursos avançados opcionais de edição para quem quer depender da memória muscular
    Adicionar aqui uma tecla de confirmação parece estranho. É parecido com colocar num piano elétrico um “pedal de confirmação de acorde incomum”: acrescenta mais uma etapa a uma ação de entrada rápida e complexa
    Como o Emacs tem um excelente desfazer, em vez de perguntar “colar o conteúdo do registrador d?”, bastaria colar e deixar o usuário desfazer caso tenha escolhido errado
    Portanto, quebrar compatibilidade aqui é estranho, e se não houver forma de desligar isso, é compreensível que muitos usuários fiquem irritados. O Emacs é uma ferramenta mais antiga que as convenções modernas de GUI, então não pode ser tão familiar a novos usuários quanto o vscodium; por isso, também faz sentido servir da melhor forma possível os power users
  • Para quem não usa Emacs, é importante deixar claro que a cópia padrão, kill-ring-save, por padrão M-w, não é afetada; só muda o recurso mais avançado de salvar em registrador
    Registradores não são um superconjunto da área de transferência, isto é, do kill ring
    Além disso, quem diz que essa mudança não será configurável parece não conhecer bem o quanto o Emacs é personalizável. “Configuração” existe por conveniência; se quiser, você pode trocar o código inteiro. Isso fica na parte Elisp do Emacs e, mesmo que entre exatamente assim, em poucos minutos deve aparecer um pacote que mude o comportamento. Não é algo que exija um fork, e falar em fork aqui é, no máximo, um gesto performático
  • Se essa mudança chegar no v30, acho que vai ser bem irritante. Não sei nada de Lisp, mas salvo itens em registradores o tempo todo
    Se não for revertida, espero encontrar algum trecho de macro que lide com a tecla extra por mim. O Emacs já exige muitas teclas até para coisas simples, e eu não sou especialista o bastante para criar por conta própria uma macro para essa mudança
  • Como resumo do post, está bom, mas, olhando também a lista de e-mails, é insuficiente como resumo do problema
    Parece que tudo começou quando Thierry encontrou alguns problemas no comportamento dos registradores e tentou corrigi-los
    O defeito mais importante era que, depois de pressionar C-x r SPC para save-to-register, qualquer próxima tecla pressionada salvava o texto no registrador correspondente àquela tecla. Em especial, C-g, a tecla universal de cancelamento do Emacs, também não funcionava ali: ela salvava texto ou posição em um registrador chamado ^g. Mesmo ao pressionar jump-to-register ou insert-register por engano, não era possível cancelar com C-g etc.; era obrigatório escolher um registrador
    Em segundo lugar, um registrador pode conter texto, uma posição ou um valor vazio. jump-to-register só funciona em registradores que contêm posições, e insert-register espera texto. O Emacs oferecia uma prévia dos registradores não vazios ao executar o comando, mas não diferenciava os tipos, por exemplo mostrando registradores com strings como candidatos para jump-to-register
    Thierry tentou corrigir esses problemas e responder ao feedback de revisão de código, e os revisores consideraram a mudança importante, mesmo que ela criasse interação adicional. Ou seja, julgaram aceitável a quebra de compatibilidade de ter que pressionar RET depois de escolher um registrador comum, ou usar uma tecla extra para salvar em registradores estranhos como ^g, em comparação com os benefícios obtidos
    O autor original pediu um interruptor para alternar entre o novo e o antigo comportamento e recebeu como resposta um pedido de patch, mas o patch que enviou revertia todas as melhorias mencionadas acima e implementava, por meio de uma flag, uma funcionalidade totalmente diferente: “confirmar a sobrescrita de registradores não vazios”. Thierry aplicou isso, deu um feedback simples, e o autor respondeu, na prática, “não precisamos disso”
    Depois, com mais pessoas usando o recurso, ficou claro que a crença de Thierry e dos revisores iniciais de que o impacto da mudança incompatível seria pequeno estava errada, e Thierry começou a criar uma flag que mantivesse o novo trabalho, mas também permitisse o fluxo antigo. Em especial, remover o RET extra não era a essência da mudança, e sim mais um efeito colateral
    No geral, o processo parece estar funcionando bastante bem, e quem parece estar tentando empurrar a discussão com uma postura anti-hacker de ignorar o contexto e dizer “se funciona mais ou menos, não se deve mudar de jeito nenhum” é mais o autor original
  • Como iniciante em Vim, eu teria imaginado que dyy significasse apagar a linha atual
    Mas talvez isso seja justamente prova de que sou iniciante

• Olhando esta thread da lista de e-mails, parece que será criada uma opção para reverter esse comportamento: https://yhetil.org/emacs/[e-mail]/#t
  Essa opção parece já ter sido mencionada antes da publicação do post original, mas talvez o autor não tenha visto. Isso parece resolver o problema, embora eu possa estar deixando algo passar
  Correção: pela resposta de ginko abaixo, parece que a tecla RETURN ainda será necessária

  • Ainda assim, parece que um RET extra é necessário para confirmar a sobrescrita de registrador
    https://yhetil.org/emacs/[e-mail]/
  • Olhando essa thread, register-use-previews parece ser o toggle desse comportamento
    Porém, é mencionado um bug em que, mesmo configurando como never, a confirmação aparece em certos fluxos de trabalho. Se for uma opção de verdade, parece que a maior parte das preocupações será resolvida

• No Emacs, a memória muscular precisa ser elevada a uma preocupação de primeira classe

  • Uma vez, uma nova versão de um gerenciador de arquivos de que eu gostava mudou os atalhos de teclado. Hoje nem lembro mais o nome, mas a raiva que senti na época ficou marcada a ponto de eu achar, mesmo então, que era exagerada
    Porque a memória muscular que eu tinha acumulado foi destruída. Até me acalmar, tive pensamentos bem perversos. Pode parecer algo pequeno, mas dá para entender por que a reação ao crime de “traição da memória muscular” chega a “fork you”
  • Isso não é exclusivo do Emacs. Não tenho nenhum interesse em Emacs, mas essa história é importante porque mostra a arrogância de desenvolvedores que tentam “melhorar” algo sem levar em conta as expectativas estáveis das pessoas
    Isso se aplica ao Google Maps ou ao iOS tanto quanto ao Emacs
  • De forma mais geral, softwares usados com frequência devem permitir a formação de memória muscular, e versões posteriores não devem quebrá-la sem um bom motivo
    A memória muscular permite operar o software de forma semissíncrona, “sem olhar”, sem confirmar visualmente cada microinteração. Infelizmente, em software desktop, há uma tendência de tornar o uso pelo teclado cada vez mais trabalhoso, ou até impossível
  • No mínimo, uma transição que quebre a memória muscular deveria ser um toggle cujo padrão fosse “manter minhas configurações como antes”

• É um bom rant, mas o fato de não explicar qual é exatamente o recurso em questão não ajuda na argumentação
  Os registros do Emacs são uma abstração muito antiga. Registros permitem guardar e recuperar valores como em uma área de transferência separada, e há 62 deles ligados aos principais símbolos ASCII [a-zA-Z0-9], oferecendo uma interface de teclado flexível e rápida. Também dá para fazer coisas interessantes, como executar macros de teclado a partir de registros. Há quem use bastante, mas eu pessoalmente não uso
  O motivo da raiva do autor é que o atalho padrão mudou, inserindo uma UI modal antes de uma operação que antes podia ser feita inteiramente pelo teclado e pela home row. Parece uma reclamação razoável, e eu também ficaria irritado se um recurso gravado na minha memória muscular mudasse assim

  • Faz muito tempo que deixei o Emacs, mas simpatizo porque dependo bastante do buffer de seleção do X11, isto é, colar com o clique do meio
    Se entre cada seleção e colagem aparecesse uma caixa de diálogo modal de confirmação, sem configuração para voltar ao comportamento antigo, eu certamente ficaria furioso. Bastaria implementar o comportamento antigo como opção. Literalmente, algumas linhas de código resolveriam
  • Há mais de 62 registros. Uma das reclamações é que o minibuffer quebra, por exemplo, o acesso ao registro C-a
    Conheço gente que usa letras para posições e C-letra para texto. Para alguns pode ser um caso extremamente específico, mas imagino que essas pessoas fiquem muito irritadas
  • Eli não parece querer fixar isso como comportamento padrão. Também não sou fã
    Em https://yhetil.org/emacs/[e-mail]/, Eli diz que “como chegaram objeções, ainda estamos discutindo qual deve ser o comportamento e, quando chegarmos a uma conclusão, poderemos falar sobre o padrão”
  • Quando se fala em “atalho padrão”, parece que seria possível configurar de outro jeito; na prática, dá para fazer isso?
  • É basicamente como ativar um uac-mode global em todos os buffers, impossível de desligar. Se não for verdade, é caso de dar risada e seguir em frente

• A interpretação do autor original não é boa. Usuários que querem estabilidade devem estar no branch de release ou fixar um commit da master
  Deve-se esperar que um branch de desenvolvimento seja usado para desenvolver recursos em andamento, e esses recursos podem levar tempo para serem refinados. Se você acompanha a master, encontrará mudanças que quebram compatibilidade com frequência, e precisa estar acostumado a voltar para um commit anterior quando algo quebrar seu fluxo de trabalho. A melhor escolha é ficar em uma release

• A essência do Emacs é ser uma plataforma extremamente personalizável; se você não gosta do comportamento de algum recurso, pode ajustá-lo você mesmo com algumas linhas de Lisp
  Fazer um fork do projeto inteiro por causa de uma mudança em um recurso obscuro não faz sentido nenhum. Uso Emacs desde mais ou menos 1981, quando ele ainda era implementado com macros TECO, mas não uso registros

  • Para ser uma plataforma extremamente personalizável, a própria plataforma precisa ser muito estável
    Caso contrário, toda vez que a plataforma muda, todo mundo precisa reescrever ou consertar todas as suas personalizações
  • Não sei qual é a diferença entre “corrigir você mesmo” e “fazer um fork”
    Se esse patch permanecer como está e alguém quiser usar exatamente do jeito antigo, na prática terá de aplicar um patch de reversão ao repositório local do Emacs e colocar suas próprias mudanças por cima. Cada vez que o upstream do Emacs mudar, terá de fazer rebase para puxar as novas alterações
    Isso é um fork privado. Fica forkado para sempre, fazendo rebase para sempre
    Também daria para fazer mais ou menos um monkey patch, carregando seu próprio arquivo no lugar de, ou depois de, um arquivo distribuído, para redefinir a função; mas isso também é uma espécie de fork. Você precisa guardar esse material em algum lugar como projeto e estar pronto para ajustá-lo quando alguma mudança quebrar o monkey patch
  • Parece que você deixou passar o fato de que essa mudança não incluiu, em nenhuma configuração, uma forma de voltar ao comportamento antigo

• Saí do Emacs há 20 anos, mas entendo que essa mudança seja bastante destrutiva
  O que não entendo é por que o Emacs, que se orgulha de “ter até a pia da cozinha”, não adicionou uma opção para voltar ao comportamento antigo

  • Provavelmente vão adicionar essa opção. O autor original só está irritado porque o patch dele não foi aceito
    Esse patch adicionava uma flag, mas também removia todas as outras melhorias

• O tom do texto passa bastante uma sensação de “neckbeard”. É um recurso extremamente obscuro usado por três nerds, não a escada imóvel da Igreja do Santo Sepulcro
  O fato de um mantenedor não remunerado ter mudado levemente algo sem perguntar a você antes não quer dizer necessariamente que ele “quebrou a master”. Estamos falando da master, não de uma versão estável ou de uma release tagueada

• Naturalmente, a única solução possível é tentar mais um fork ou reimplementação do Emacs
  Este certamente vai dar certo e não vai se tornar algo completamente irrelevante como os outros

  • O impacto desse tipo de fork está na erosão gradual da comunidade ao redor do projeto principal
    Mas não importa muito se o fork força ou não o projeto principal a sentar à mesa de negociação. O autor original tem capacidade e disposição para manter esse patch até o fim no próprio repositório local. A única coisa que falta para completar o fork é tornar público esse repositório local
  • Só pelo post do blog, não dá para saber muito bem quais são as intenções de longo prazo do autor em relação ao fork
    Talvez seja apenas uma forma de convencer os mantenedores da mainline