Malas noticias, Emacs

Problemas en Emacs 30 y el surgimiento de una versión fork

• La rama master de Emacs quedó afectada por un cambio importante, a pesar de las preocupaciones de usuarios y desarrolladores.
• Debido a ese cambio, la interacción con los registros de Emacs se volvió incómoda y hasta las tareas simples requieren pulsaciones de teclas adicionales.
• Se creó una versión fork mejorada para usarla y desarrollarla, y se da la bienvenida a quienes quieran participar.

La estabilidad de la rama master de Emacs y los cambios recientes

• La rama master de Emacs es la versión de desarrollo, seguida por usuarios que quieren probar los avances más recientes.
• Gracias al esfuerzo de los mantenedores de Emacs en los últimos años, la rama master había sido muy estable.
• Sin embargo, un cambio reciente provocó una sorpresa desagradable para los usuarios.

El deterioro de la experiencia de usuario y la reacción de la comunidad

• El nuevo cambio deterioró la experiencia de usuario, y crecieron las voces que pedían restaurar de forma opcional el comportamiento eficiente anterior.
• A pesar de las opiniones claras de los miembros de la comunidad, el problema no se resolvió por la actitud del desarrollador que defendía el cambio.
• Los mantenedores mostraron una postura de mantener el cambio incluso a costa de sacrificar la experiencia de usuario.

El desarrollo de una nueva versión fork y la libertad del usuario

• El autor, que considera importante la libertad del usuario, rechazó que se le impusieran cambios extraños en Emacs existente y creó un nuevo fork.
• Esta versión fork toma selectivamente solo los buenos cambios de la rama master, y también mejora con el propio desarrollo del autor.
• Quienes estén interesados en esta versión fork pueden clonar desde el repositorio del autor, y se agradecen la colaboración y las sugerencias.

La opinión de GN⁺

Lo más importante de este texto es el deterioro de la experiencia de usuario ocurrido en Emacs 30 y la reacción de la comunidad ante ello. Como Emacs ha sido apreciado durante mucho tiempo entre desarrolladores por su capacidad de personalización y su extensibilidad, hay gran interés en cómo estos cambios podrían afectar a los usuarios. Además, el proceso en el que un desarrollador ignoró la opinión de la comunidad e impuso sus propios cambios ofrece un caso interesante sobre la toma de decisiones y la cultura de colaboración en proyectos de código abierto. Este texto muestra bien cómo reaccionan los usuarios a los cambios en el software y cómo, si es necesario, buscan sus propias soluciones.

[GN⁺]

Opiniones de Hacker News

• Cuando ocurre un cambio importante en la rama de desarrollo de Emacs y algunos usuarios expresan preocupación, ese cambio no se revierte de inmediato. Se debaten sus pros y contras, se implementan y mejoran distintas soluciones y, finalmente, se encuentra un punto de compromiso.

  • Las preocupaciones de los usuarios comenzaron hace 3 días, y este proceso todavía no ha concluido.
  • En el mensaje reciente de Eli se menciona una discusión inicial entre dos personas en la que se decía que el nuevo comportamiento era mucho más razonable que el anterior, y que solo ahora, después de que se presentaron otras opiniones, se está debatiendo el criterio de ese comportamiento.

• Recientemente se aceptó un commit que cambia la forma en que funciona copiar en Emacs (o, más generalmente, la función conocida como "registro"). Ahora Emacs abre un minibúfer que muestra lo que está ocurriendo y exige que el usuario presione Enter para aceptar el cambio.

  • Esto cambia el comportamiento predeterminado, quizá no sea fácil de configurar y parece haberse hecho sin suficiente discusión.
  • Mediante una analogía para usuarios de Vim se explica lo incómodo que resulta este cambio, y se describen los esfuerzos del autor original por plantear este problema y la reacción del desarrollador Thierry.

• Al revisar la lista de correo, parece que habrá una opción para revertir este comportamiento.

  • Esta opción se mencionó antes de que se publicara el texto original, pero puede que su autor no la haya visto.
  • Se espera que esta opción resuelva el problema, pero según la respuesta de ginko, todavía podría seguir siendo necesario presionar Enter.

• En Emacs, la memoria muscular debería considerarse un factor importante.

• Desde la perspectiva del desarrollador, los usuarios que quieren estabilidad deberían usar la rama de lanzamiento o fijar commits en master. La rama de desarrollo se usa para desarrollar funciones en progreso y, a veces, este tipo de cambios puede ocurrir con frecuencia.

• La actitud del autor es algo terca, y se señala que muy poca gente usa esta función. No debería considerarse que un mantenedor no remunerado haya "destruido" la rama master por hacer un pequeño cambio sin consultar primero.

• Aunque ya pasaron 20 años desde que dejó Emacs, se entiende que este cambio es bastante confuso. No se entiende por qué Emacs, que se enorgullece de ser un "fregadero de cocina", no añadió una opción para volver al comportamiento anterior.

• La esencia de Emacs es que es una plataforma muy personalizable, y si no te gusta cómo funciona alguna característica, puedes arreglarla tú mismo con unas pocas líneas de código Lisp. No tiene sentido bifurcar todo el proyecto por un cambio en una sola función.

• Parece que la única solución es intentar otro fork/reimplementación más de Emacs. Esta vez seguro que sí tendrá éxito y no será para nada irrelevante, como todas las demás.

• ¿Cuál es el argumento del "otro lado" respecto a este cambio? Los cambios que generan este tipo de opiniones normalmente tienen alguna razón sensata detrás. O quizá no.