Malas noticias, Emacs
Un cambio controvertido en la función de registros de Emacs —que introduce un paso adicional de confirmación y altera flujos de teclado con décadas de antigüedad— ha provocado fuertes reacciones entre usuarios veteranos. Los críticos sostienen que romper la memoria muscular y no ofrecer inicialmente una forma simple de restaurar el comportamiento antiguo muestra desdén por la compatibilidad hacia atrás y por el ethos de extrema personalización de Emacs, mientras que otros responden que `master` es una rama de desarrollo y que las mejoras de UX para usuarios nuevos son objetivos legítimos. El debate se ha ampliado a cuestiones más generales sobre la gobernanza del proyecto, cuándo es aceptable romper interfaces establecidas y si tales cambios siempre deberían ser opcionales o activados explícitamente por el usuario.
Qué cambió y por qué importa
- El cambio afecta a los “registros” de Emacs (una función avanzada de múltiples portapapeles / posición), no al copiar y pegar normal.
- El nuevo comportamiento intercala una interfaz de minibuffer que muestra los registros y requiere un
RETadicional para confirmar. - Los críticos dicen que esto convierte una operación rápida, de la fila de inicio y basada en memoria muscular, en una modal y más lenta, usada muchas veces por minuto.
- Varias analogías: como obligar a mostrar un cuadro de confirmación después de cada
Ctrl-C/pegar o añadir latencia al instrumento de un músico.
Impacto en usuarios y flujos de trabajo
- Los usuarios intensivos de registros informan de memoria muscular rota, macros rotas y mayor carga cognitiva.
- Algunos enfatizan que los pequeños retrasos por acción se acumulan gravemente en flujos de trabajo usados cientos de veces al día.
- Otros dicen que los registros son de nicho; muchos usuarios veteranos apenas los usan y ven el conflicto como exagerado.
- Usuarios que no usan Emacs en el hilo emplean analogías con Vim y coinciden en que un cambio así también sería disruptivo en sus editores.
Configurabilidad y necesidad de un fork
- Un bando: en Emacs “todo es Lisp”, así que los usuarios o paquetes pueden restaurar fácilmente el comportamiento antiguo; un fork duro se ve como algo político o impulsado por el ego.
- Otro bando: hacer monkey-patch del comportamiento central equivale en la práctica a mantener un fork privado de todos modos y desplaza la carga de mantenimiento a los usuarios.
- Hay trabajo en curso sobre opciones/conmutadores para restaurar el comportamiento antiguo; algunas propuestas anteriores fueron rechazadas por eliminar también otras funciones nuevas.
Proceso de desarrollo y gobernanza del proyecto
- Preocupa que un cambio de UX rompedor para un comportamiento de larga data llegara a
mastertras discusión entre muy pocos desarrolladores. - Algunos sostienen que así es exactamente como debería funcionar la rama de desarrollo: fusionar, y luego refinar o revertir según los comentarios antes de la versión.
- Otros ven un patrón de decisiones por “fiat”, poco respeto por la compatibilidad hacia atrás y poca disposición a revertir.
- Varios comentaristas señalan que el enfoque del artículo es muy unilateral; los hilos de la lista de correo muestran más matices e iteración activa.
Filosofía de diseño más amplia y usuarios “nuevos vs. antiguos”
- Debate sobre si Emacs debe optimizar los valores predeterminados para principiantes (descubribilidad, seguridad) o para usuarios avanzados (velocidad, estabilidad).
- Muchos dicen que romper décadas de atajos debería ser raro, inicialmente opt-in y siempre reversible mediante una configuración clara.
- Algunos ven esto como emblemático de una tendencia más amplia: “mejoras” de UX que faltan al respeto a la memoria muscular en muchos proyectos de software.