Mauvaises nouvelles, Emacs

Problèmes de la version 30 d’Emacs et création d’un fork

• La branche master d’Emacs a été abîmée par un changement majeur, malgré les inquiétudes des utilisateurs et des développeurs.
• Ce changement rend l’interaction avec les registres Emacs moins pratique et exige des frappes supplémentaires même pour des tâches simples.
• Une version fork améliorée a été créée et est en cours d’utilisation et de développement, et la participation des personnes intéressées est la bienvenue.

Stabilité de la branche master d’Emacs et changements récents

• La branche master d’Emacs est une version de développement, suivie par les utilisateurs qui veulent essayer les toutes dernières évolutions.
• Ces dernières années, grâce aux efforts des mainteneurs d’Emacs, la branche master était très stable.
• Mais un changement récent a provoqué une mauvaise surprise pour les utilisateurs.

Dégradation de l’expérience utilisateur et réaction de la communauté

• Le nouveau changement a dégradé l’expérience utilisateur, et les demandes pour restaurer au moins de manière optionnelle l’ancien comportement efficace se sont multipliées.
• Malgré les avis clairement exprimés par les membres de la communauté, le problème n’a pas été résolu à cause de l’attitude du développeur qui défend ce changement.
• Les mainteneurs ont montré une volonté de maintenir ce changement même au prix de l’expérience utilisateur.

Développement d’une nouvelle version forkée et liberté des utilisateurs

• L’auteur, qui accorde de l’importance à la liberté des utilisateurs, refuse qu’on lui impose les changements étranges de l’Emacs existant et a créé un nouveau fork.
• Cette version forkée récupère de manière sélective uniquement les bons changements de la branche master et s’améliore aussi grâce au développement de l’auteur.
• Les personnes intéressées par cette version forkée peuvent la cloner depuis le dépôt de l’auteur, et toute collaboration ou proposition est la bienvenue.

Avis de GN⁺

Le point le plus important de ce texte est la dégradation de l’expérience utilisateur apparue dans Emacs 30 et la réaction de la communauté face à ce changement. Emacs est apprécié depuis longtemps parmi les développeurs pour sa personnalisation et son extensibilité, ce qui explique l’attention portée à l’impact de cette évolution sur ses utilisateurs. De plus, la manière dont un développeur a ignoré l’avis de la communauté pour imposer ses modifications offre un cas intéressant sur la prise de décision et la culture de collaboration dans les projets open source. Ce texte montre bien comment les utilisateurs réagissent aux changements d’un logiciel et cherchent, si nécessaire, leurs propres solutions.

[GN⁺]

Avis Hacker News

• Lorsqu’un changement important survient dans la branche de développement d’Emacs et que certains utilisateurs expriment leurs inquiétudes, ce changement n’est pas immédiatement annulé. Les avantages et les inconvénients sont discutés, diverses solutions sont mises en œuvre et améliorées, puis un compromis finit par être trouvé.

  • Les préoccupations des utilisateurs ont commencé à être soulevées il y a trois jours, et ce processus n’est pas encore terminé.
  • Dans le récent message d’Eli, il est fait mention d’une discussion initiale entre deux personnes selon laquelle le nouveau comportement serait bien plus raisonnable que l’ancien, et ce n’est qu’après l’apparition d’avis divergents qu’une discussion a été engagée sur les critères de comportement.

• Un commit modifiant la façon dont fonctionne la copie dans Emacs (ou, plus généralement, ce qu’on appelle les « registres ») a récemment été accepté. Désormais, Emacs ouvre un minibuffer montrant ce qui se passe et demande à l’utilisateur d’appuyer sur Entrée pour accepter le changement.

  • Cela modifie le comportement par défaut, il se peut que ce ne soit pas facilement configurable, et cela semble avoir été fait sans discussion suffisante.
  • Une analogie avec les utilisateurs de Vim est utilisée pour expliquer à quel point ce changement est contraignant, et les efforts de l’OP pour soulever ce problème ainsi que la réaction du développeur Thierry sont décrits.

• Après examen de la mailing list, il semble qu’il y ait une option permettant de revenir sur ce comportement.

  • Cette option avait été mentionnée avant la publication du message d’origine, mais son auteur a peut-être simplement manqué cette information.
  • Cette option devrait résoudre le problème, mais selon la réponse de ginko, il pourrait malgré tout rester nécessaire d’appuyer sur Entrée.

• Dans Emacs, la mémoire musculaire doit être considérée comme un élément important.

• Du point de vue du développeur, les utilisateurs qui veulent de la stabilité doivent utiliser la branche de release ou épingler un commit sur master. La branche de développement sert à développer des fonctionnalités en cours, et ce type de changement peut donc survenir assez souvent.

• L’attitude de l’auteur semble quelque peu obstinée, et il est souligné que très peu de personnes utilisent cette fonctionnalité. Le fait qu’un mainteneur bénévole l’ait légèrement modifiée sans consultation préalable ne devrait pas être considéré comme une « destruction » de la branche master.

• Cela fait 20 ans que certains ont quitté Emacs, mais ce changement reste perçu comme particulièrement déroutant. Ils ne comprennent pas pourquoi Emacs, qui se présente comme un « évier de cuisine », n’a pas ajouté d’option permettant de revenir au comportement précédent.

• L’essence d’Emacs est d’être une plateforme extrêmement personnalisable, et si le comportement d’une fonctionnalité ne convient pas, il est possible de le corriger soi-même avec quelques lignes de code Lisp. Forker l’ensemble du projet à cause du changement d’une seule fonctionnalité n’a pas de sens.

• Tenter un autre fork / une autre réimplémentation d’Emacs semble être la seule solution. Cette fois, ce sera certainement un succès, et ce ne sera sûrement pas totalement sans rapport, comme tout le reste.

• Quel est l’argument de « l’autre camp » concernant ce changement ? Les modifications qui suscitent ce type de réaction ont généralement une raison valable derrière elles. Ou peut-être pas.