Mauvaise nouvelle, Emacs

• Il s’agissait d’un texte critique sur les changements apportés à la fonctionnalité registers d’Emacs 30, mais le contenu original n’est plus disponible dans la version actuellement publique
• Le texte original a été supprimé au motif qu’il critiquait trop durement le développement récent d’Emacs et qu’il était peu bienveillant envers les personnes concernées
• Il ne reste qu’une indication suggérant de consulter le journal Git du site de l’auteur pour retrouver le contenu supprimé
• L’essentiel qui subsiste est que l’auteur a commencé à utiliser au quotidien une branche (branch) légèrement différente d’Emacs
• Avec le seul contenu actuellement public, il est difficile de vérifier les changements précis ou les enjeux techniques liés à la fonctionnalité registers d’Emacs 30

---

Un texte critique sur Emacs 30 retiré

• Le texte original portait sur des changements que l’auteur jugeait dégradants dans la fonctionnalité registers d’Emacs 30
• Le contenu public indique que l’article original a été supprimé parce qu’il critiquait excessivement le développement récent d’Emacs et manquait de bienveillance envers les personnes concernées
• Le fait qu’il ait attiré beaucoup plus d’attention que les précédents billets du blog est également mentionné comme contexte de sa suppression

Informations actuellement disponibles

• Pour lire malgré tout le texte supprimé, il est possible de consulter le journal Git de ce site web
• L’auteur indique avoir commencé à utiliser au quotidien une branch légèrement différente d’Emacs
• Le contenu actuellement public ne comporte pas de problèmes précis, d’exemples ni de détails de patch concernant les changements de la fonctionnalité registers d’Emacs 30

[GN⁺]

Avis sur Hacker News

• Quand un changement cassant la compatibilité arrive dans la branche de développement d’Emacs, qu’il soit intentionnel ou non, et que certains utilisateurs expriment leurs inquiétudes, le processus ne consiste pas à l’annuler immédiatement
  Il faut discuter des avantages et des inconvénients, implémenter et améliorer plusieurs solutions, puis trouver un compromis. Comme cela ne fait que trois jours que des utilisateurs ont fait part de leurs préoccupations, il est difficile d’estimer que ce processus aurait déjà dû être terminé
  La réponse récente d’Eli allait aussi dans ce sens : « les deux personnes qui ont participé à la discussion initiale estimaient que le nouveau comportement était bien plus justifié que l’ancien, mais maintenant que des avis opposés sont arrivés, on peut continuer à discuter du comportement, puis parler ensuite de la valeur par défaut »
  Je pense qu’il existe de sérieux problèmes dans la façon dont Emacs est développé, mais il est aussi problématique que les utilisateurs reprochent d’ordinaire aux gens obstinés d’emacs-devel leur entêtement, puis se comportent comme si le monde s’écroulait dès qu’un changement qu’ils n’aiment pas est introduit. Cela pousse les mainteneurs à se mettre sur la défensive

  • Quand on utilise la branche de développement, il n’est pas raisonnable de faire un scandale parce qu’un changement cassant la compatibilité survient. Dans une branche de développement, ce genre de chose est prévisible
    En lisant le fil de discussion par e-mail, cela ressemble davantage à un fort désaccord qu’à de « l’arrogance », et parvenir à un consensus prend forcément du temps. Qualifier publiquement quelqu’un d’« arrogant » parce qu’il ne recule pas immédiatement pour adopter votre point de vue, puis chercher à mobiliser une foule qui ne lira même pas le fil, ressemble presque à du harcèlement
    Il n’est pas non plus honnête de dire que le patch rendant le changement optionnel a été ignoré. Ce patch n’ajoutait pas seulement une option : il supprimait aussi d’autres modifications, et c’est pour cela qu’il a été refusé. Rejeter ainsi la responsabilité sur une seule personne est également difficile à accepter
  • Dire que « les réactions des utilisateurs sont une entrée essentielle de la décision finale », tout en critiquant les réactions négatives des utilisateurs comme étant « exagérées », semble contradictoire
    Si les utilisateurs n’avaient pas réagi, selon la procédure décrite, il est très probable que le changement initial auquel ils s’opposaient serait passé tel quel. Dans clojure-mode aussi, rms avait essayé de reprendre le nom d’un auteur issu de la communauté Clojure, maintenu depuis longtemps, pour le réécrire ; les protestations sur la liste ont permis de l’empêcher, mais ces personnes se sont ensuite entendu dire qu’elles exagéraient. Dans ce contexte, la critique de « l’exagération » ne paraît donc pas très pertinente
  • C’est une mauvaise procédure. L’examen d’une fonctionnalité doit commencer avant sa fusion dans la branche principale, pas après
    Si l’on ajoute dans la branche principale, sans discussion avec la communauté au sens large, une fonctionnalité qui casse les flux de travail des utilisateurs, il est normal que les gens se fâchent. Ce type de fusion est la manière dont les vieux outils perdent le soutien de leur communauté
  • La communauté Emacs a, au moins historiquement, accordé une très grande importance à la rétrocompatibilité. Casser les usages existants est à peu près l’une des pires choses que l’on puisse faire dans Emacs
    Si l’annulation immédiate d’un changement cassant la compatibilité n’est pas sérieusement envisagée, cela envoie le signal que les développeurs d’Emacs n’accordent plus autant d’importance qu’avant à la rétrocompatibilité, ce qui revient à abandonner une part importante des utilisateurs existants
    https://www.murilopereira.com/the-values-of-emacs-the-neovim...
    Les valeurs fondamentales comptent. Les mainteneurs d’Emacs ont enfreint des valeurs fondamentales, et il est légitime que la communauté en soit mécontente
  • D’après l’explication de l’article, l’état de santé d’Emacs est préoccupant. Il y avait déjà une controverse avant la fusion dans master, mais ils ont quand même fusionné
    Casser les flux de travail des utilisateurs sans même en faire une option, et sans opt-in — pire, sans même permettre de le désactiver — donne l’impression d’un mépris désinvolte de l’expérience utilisateur

• Pour résumer ce que j’ai compris, un commit a récemment été accepté dans Emacs pour modifier le comportement des registres, plus général que la simple copie.
  Désormais, Emacs ouvre un minibuffer qui montre ce qui se passe, et il faut valider le changement avec Enter ou une entrée équivalente. L’auteur du billet d’origine y voit une rupture de compatibilité catastrophique, car le comportement par défaut change, qu’il pourrait ne pas être facile de le désactiver par configuration, et qu’il n’y a pas eu suffisamment de discussion.
  Par analogie avec Vim, ce serait comme taper "dyy pour copier la ligne courante dans le registre d, puis voir ensuite s’ouvrir un buffer scratch affichant le texte et le buffer, avec une frappe exigée pour le fermer. Pour un utilisateur Vim ordinaire qui comprend les registres, ce serait épouvantable, même si certains préfèrent effectivement un comportement qui “montre explicitement ce qui est copié”, comme les personnes qui copient en mode visuel.
  Le reste du texte dit que l’auteur d’origine a essayé de lancer une discussion, mais que Thierry, l’auteur du commit, l’a bloquée, et que le reste de la communauté de développement d’Emacs en porte aussi implicitement la responsabilité.

  • Les registres sont une fonctionnalité relativement avancée, surtout utilisée pour de l’édition rapide. C’est une fonction destinée moins aux nouveaux utilisateurs qui se servent de la souris qu’aux personnes qui enchaînent vite des opérations complexes.
    J’utilise Emacs depuis des dizaines d’années, mais je ne me suis jamais vraiment plongé dans les registres ; personnellement, j’utilisais kill/yank pour copier, et les curseurs multiples ou des macros clavier ponctuelles pour les éditions complexes. Cela dit, Emacs offre beaucoup de fonctionnalités d’édition avancées optionnelles pour les gens qui veulent s’appuyer sur leur mémoire musculaire.
    Ajouter ici une touche de confirmation est étrange. C’est un peu comme ajouter une “pédale de confirmation des accords inhabituels” à un piano électrique : cela rajoute une étape à des gestes de saisie rapides et complexes.
    Emacs dispose d’un excellent annuler ; plutôt que de demander “voulez-vous coller le contenu du registre d ?”, il suffit de coller, puis de laisser l’utilisateur annuler s’il s’est trompé.
    Donc casser la compatibilité ici est étrange, et s’il n’y a pas moyen de le désactiver, beaucoup d’utilisateurs ont de bonnes raisons d’être mécontents. Emacs est un outil plus ancien que les conventions modernes des interfaces graphiques, il ne pourra donc pas être aussi familier aux nouveaux utilisateurs que vscodium ; il y a aussi un argument convaincant à servir au mieux les power users.
  • Pour les personnes qui n’utilisent pas Emacs, il faut préciser que la copie standard, kill-ring-save, par défaut M-w, n’est pas affectée, et que seul l’enregistrement dans les registres, une fonctionnalité plus avancée, change.
    Les registres ne sont pas un sur-ensemble du presse-papiers, c’est-à-dire du kill ring.
    De plus, ceux qui disent que ce changement ne sera pas configurable semblent mal connaître la capacité de personnalisation d’Emacs. Les “réglages” ne sont qu’une commodité ; si on le veut, on peut remplacer le code en entier. C’est une partie d’Emacs écrite en Elisp, et même si cela entre tel quel, un paquet modifiant ce comportement sortira en quelques minutes. Il n’y a pas besoin de fork, et parler de fork ici relève au mieux du geste performatif.
  • Si ce changement arrive dans la v30, je pense que ce sera assez agaçant. Je ne connais absolument pas Lisp, mais j’enregistre constamment des éléments dans des registres.
    Si ce n’est pas annulé, j’espère pouvoir trouver un bout de macro qui gérera à ma place la frappe supplémentaire. Emacs demande déjà beaucoup de touches même pour des choses simples, et je ne suis pas assez expert pour créer moi-même une macro pour ce changement.
  • Comme résumé du billet, c’est correct, mais si l’on lit aussi la liste de diffusion, c’est insuffisant comme résumé du problème.
    L’affaire semble avoir commencé quand Thierry a repéré plusieurs problèmes dans le comportement des registres et a voulu les corriger.
    Le défaut le plus important était qu’après avoir lancé save-to-register avec C-x r SPC, la touche pressée ensuite, quelle qu’elle soit, servait de registre dans lequel enregistrer le texte. En particulier, C-g, la touche d’annulation universelle d’Emacs, ne fonctionnait pas ici : elle enregistrait du texte ou une position dans un registre nommé ^g. Même après avoir lancé par erreur jump-to-register ou insert-register, on ne pouvait pas annuler avec C-g ou autre ; il fallait forcément choisir un registre.
    Ensuite, un registre peut contenir du texte, une position ou une valeur vide. jump-to-register ne fonctionne que sur un registre contenant une position, et insert-register attend du texte. Emacs fournit un aperçu des registres non vides lors de l’exécution de la commande, mais ne les distinguait pas, par exemple en proposant aussi les registres contenant une chaîne comme candidats pour jump-to-register.
    Thierry a essayé de corriger ces problèmes ainsi que les retours de revue de code, et les relecteurs ont estimé qu’il s’agissait de changements importants, même s’ils ajoutaient une interaction supplémentaire. Ils ont considéré que la rupture de compatibilité — devoir appuyer sur RET après le choix normal d’un registre, ou utiliser une touche supplémentaire pour enregistrer dans un registre bizarre comme ^g — était acceptable au regard des bénéfices.
    L’auteur d’origine a demandé un interrupteur permettant de passer du nouveau comportement à l’ancien, et on lui a répondu d’envoyer un patch ; mais le patch soumis annulait toutes les améliorations mentionnées ci-dessus et implémentait, via un flag, une fonctionnalité complètement différente : la “confirmation de l’écrasement d’un registre non vide”. Thierry l’a appliqué, a donné un retour simple, et l’auteur a répondu en substance : “ce n’est pas nécessaire”.
    Par la suite, à mesure que davantage de personnes utilisaient la fonctionnalité, la conviction de Thierry et des premiers relecteurs selon laquelle l’impact de la rupture était faible s’est révélée fausse, et Thierry a commencé à créer un flag qui conserve le nouveau travail tout en autorisant aussi l’ancien flux. En particulier, la suppression du RET supplémentaire n’était pas l’essentiel, mais plutôt un effet de bord.
    Dans l’ensemble, le processus semble plutôt bien fonctionner, et c’est plutôt l’auteur d’origine qui paraît vouloir forcer la discussion avec une attitude antihacker consistant à ignorer le contexte et à dire “si ça marche à peu près, il ne faut absolument rien changer”.
  • En tant que débutant Vim, j’aurais pensé que dyy voulait dire supprimer la ligne courante.
    Mais c’est probablement justement la preuve que je suis débutant.

• À voir ce fil de liste de diffusion, il semble qu’une option permettant de rétablir ce comportement va être ajoutée : https://yhetil.org/emacs/[e-mail]/#t
  Cette option semble avoir déjà été mentionnée avant la publication du billet d’origine, mais l’auteur ne l’a peut-être pas vue. Cela devrait résoudre le problème, même si j’ai peut-être manqué quelque chose.
  Modification : d’après la réponse de ginko ci-dessous, il semble qu’une frappe sur RETURN soit toujours nécessaire.

  • Il semble quand même qu’un RET supplémentaire soit nécessaire pour confirmer l’écrasement d’un registre.
    https://yhetil.org/emacs/[e-mail]/
  • À lire ce fil, register-use-previews ressemble au toggle de ce comportement.
    Cela dit, un bug est mentionné : même réglé sur never, une confirmation apparaît dans certains workflows. Si c’est bien une vraie option, cela devrait lever l’essentiel des inquiétudes.

• Dans Emacs, la mémoire musculaire devrait être élevée au rang de préoccupation de premier ordre

  • Il m’est arrivé qu’une nouvelle version d’un gestionnaire de fichiers que j’aimais change ses raccourcis clavier. Je ne me souviens même plus de son nom, mais la colère que j’ai ressentie alors m’est restée en mémoire, au point que je la trouvais déjà excessive sur le moment.
    C’est parce que la mémoire musculaire que j’avais accumulée avait été détruite. Avant de me calmer, j’ai même eu des pensées assez malveillantes. Cela peut sembler anodin, mais je comprends pourquoi la réaction au crime de « trahison de la mémoire musculaire » peut aller jusqu’à « fork you »
  • Ce n’est pas propre à Emacs. Emacs ne m’intéresse pas du tout, mais cette histoire est importante parce qu’elle montre l’arrogance de développeurs qui veulent « améliorer » quelque chose sans tenir compte des attentes stables des gens.
    Cela s’applique tout autant à Google Maps ou à iOS qu’à Emacs
  • Plus généralement, les logiciels utilisés fréquemment devraient permettre la mémorisation musculaire, et les versions ultérieures ne devraient pas la casser sans bonne raison.
    La mémoire musculaire permet de manipuler un logiciel de façon semi-asynchrone, « sans regarder », sans devoir vérifier visuellement chaque micro-interaction. Malheureusement, dans les logiciels desktop, la tendance est de rendre les interactions au clavier de plus en plus pénibles, voire carrément impossibles
  • Au minimum, une transition qui casse la mémoire musculaire devrait être un toggle dont la valeur par défaut est « conserver mes réglages comme avant »

• C’est un bon rant, mais le fait de ne pas expliquer quelle fonctionnalité est réellement concernée n’aide pas à convaincre.
  Les registres d’Emacs sont une très ancienne abstraction. On peut y stocker et en extraire des valeurs comme dans un presse-papiers séparé, et il y en a 62 associés aux symboles ASCII principaux [a-zA-Z0-9], ce qui offre une interface clavier flexible et rapide. On peut aussi faire des choses amusantes comme exécuter des macros clavier depuis des registres. Certaines personnes les utilisent beaucoup, mais personnellement je ne m’en sers pas.
  Si l’auteur est en colère, c’est parce que le binding par défaut a changé, et qu’une UI modale s’intercale désormais devant une opération qui se faisait auparavant entièrement au clavier et depuis la home row. Cela me semble être une plainte raisonnable, et si une fonctionnalité ancrée dans ma mémoire musculaire changeait ainsi, je pense que je serais moi aussi agacé

  • J’ai abandonné Emacs il y a longtemps, mais je dépends beaucoup du tampon de sélection X11, c’est-à-dire du collage au clic du milieu, donc je comprends.
    Si une boîte de dialogue modale de confirmation s’intercalait entre chaque sélection et collage, sans réglage permettant de revenir au comportement existant, je serais clairement énervé. Il suffit d’implémenter l’ancien comportement sous forme d’option. Littéralement quelques lignes de code
  • Il y a plus de 62 registres. L’une des plaintes est que le minibuffer casse, par exemple, l’accès au registre C-a.
    Je connais quelqu’un qui utilise des caractères pour les positions et C-caractère pour le texte. Pour certains, c’est peut-être un cas très particulier, mais ces personnes risquent d’être très en colère
  • Eli ne semble pas vouloir figer cela comme comportement par défaut. Je ne suis pas fan non plus.
    Sur https://yhetil.org/emacs/[e-mail]/, Eli dit : « puisque des objections ont été soulevées, nous continuons à discuter du comportement à adopter, et une fois la conclusion trouvée, nous pourrons parler de la valeur par défaut »
  • Dire « binding par défaut » donne l’impression que cela peut être configuré autrement, mais est-ce vraiment possible ?
  • C’est comme activer un uac-mode global pratiquement impossible à désactiver dans tous les buffers. Si ce n’est pas le cas, alors on peut en rire

• L’interprétation de l’auteur de l’article original n’est pas bonne. Les utilisateurs qui veulent de la stabilité devraient rester sur une branche de release ou épingler un commit de master.
  Il faut s’attendre à ce qu’une branche de développement serve à développer des fonctionnalités en cours, et que celles-ci puissent prendre du temps à être peaufinées. Si vous suivez master, vous rencontrerez souvent des changements incompatibles, et vous devriez être habitué à revenir à un commit antérieur quand votre workflow est cassé. Le meilleur choix est de rester sur une release

• L’essence d’Emacs est d’être une plateforme extrêmement personnalisable : si le comportement d’une fonctionnalité ne vous plaît pas, vous pouvez le corriger vous-même avec quelques lignes de Lisp.
  Forker tout le projet à cause de la modification d’une fonctionnalité obscure n’a absolument aucun sens. J’utilise Emacs depuis environ 1981, à l’époque où il était implémenté avec des macros TECO, mais je n’utilise pas les registres

  • Pour être une plateforme extrêmement personnalisable, la plateforme elle-même doit être très stable.
    Sinon, à chaque changement de la plateforme, tout le monde doit réécrire ou corriger toutes ses personnalisations
  • Je ne vois pas la différence entre « corriger soi-même » et « forker ».
    Si ce patch reste tel quel et que quelqu’un veut utiliser exactement l’ancien comportement, il devra en pratique appliquer un patch de revert dans son dépôt local d’Emacs, puis superposer ses propres modifications. À chaque évolution de l’upstream Emacs, il devra rebase pour récupérer les nouveaux changements.
    C’est un fork privé. Un fork permanent, avec des rebases permanents.
    On peut aussi bricoler un monkey patch en chargeant son propre fichier à la place ou après le fichier fourni pour redéfinir les fonctions, mais c’est aussi une forme de fork. Il faut stocker ce matériel quelque part comme projet, et être prêt à l’ajuster quand un changement casse le monkey patch
  • Vous semblez avoir manqué le fait que ce changement n’incluait aucune possibilité de revenir au comportement existant via un réglage

• J’ai quitté Emacs il y a 20 ans, mais je comprends que ce changement soit assez destructeur.
  Ce que je ne comprends pas, c’est pourquoi Emacs, qui se targue d’avoir « tout, jusqu’à l’évier de cuisine », n’a pas ajouté une option pour revenir à l’ancien comportement

  • Il est probable qu’ils ajoutent cette option. L’auteur original est simplement en colère parce que son patch n’a pas été accepté.
    Ce patch ajoutait un flag, mais supprimait aussi toutes les autres améliorations

• Le ton de l’article fait très « neckbeard ». C’est une fonctionnalité ultra obscure utilisée par trois nerds, pas l’échelle inamovible de l’église du Saint-Sépulcre.
  Le fait qu’un mainteneur bénévole l’ait légèrement changée sans vous demander au préalable ne signifie pas nécessairement qu’il a « cassé master ». On parle ici de master, pas d’une version stable ni d’une release taguée

• Bien sûr, la seule solution envisageable est de tenter encore un autre fork ou une réimplémentation d’Emacs.
  Celui-ci réussira forcément et ne deviendra pas totalement hors sujet comme les autres

  • L’impact de ce genre de fork tient au fait que la communauté autour du projet principal s’érode lentement.
    Cela dit, il importe assez peu que le fork amène ou non le projet principal à la table des négociations. L’auteur original a la capacité et la volonté de conserver ce patch jusqu’au bout dans son dépôt local. La seule chose qui manque pour achever le fork, c’est de rendre public ce dépôt local
  • À la seule lecture du billet de blog, je ne sais pas vraiment quelles sont les intentions de l’auteur à long terme concernant un fork.
    Peut-être s’agit-il simplement de convaincre les mainteneurs mainline