Malas noticias, Emacs

• Era un artículo crítico sobre cambios en la función de registers de Emacs 30, pero actualmente el texto original ya no está disponible en la versión pública
• El texto original fue eliminado porque trataba el desarrollo reciente de Emacs de forma excesivamente crítica y fue poco amable con las personas involucradas
• Solo queda una indicación de consultar el log de Git del sitio web del autor para ver el contenido eliminado
• Lo esencial que queda es que el autor empezó a usar a diario una rama (branch) ligeramente distinta de Emacs
• Con el texto público actual es difícil verificar los cambios concretos o los puntos técnicos en disputa sobre la función de registers de Emacs 30

---

Artículo crítico sobre Emacs 30 retirado

• El texto original trataba sobre cambios que el autor consideraba negativos en la función de registers de Emacs 30
• En el texto público queda el motivo de la eliminación: el artículo original criticaba en exceso el desarrollo reciente de Emacs y fue poco amable con las personas involucradas
• También se menciona como parte del contexto de la eliminación que recibió mucha más atención que entradas anteriores del blog

Información disponible actualmente

• Si realmente quieres leer el artículo eliminado, puedes revisar el log de Git de este sitio web
• El autor afirma que empezó a usar a diario una branch ligeramente distinta de Emacs
• El texto público actual no incluye problemas concretos, ejemplos ni detalles de parches sobre los cambios en la función de registers de Emacs 30

[GN⁺]

Opiniones de Hacker News

• Si en la rama de desarrollo de Emacs entra un cambio que rompe la compatibilidad, ya sea intencional o no, y algunos usuarios expresan preocupación, no necesariamente se procede a revertirlo de inmediato.
  Hace falta discutir pros y contras, implementar y mejorar varias soluciones, y luego buscar un punto intermedio. Apenas pasaron 3 días desde que los usuarios plantearon sus inquietudes, así que es difícil decir que ese proceso ya debería haber terminado.
  La respuesta reciente de Eli también iba en el sentido de que “las dos personas que participaron al inicio de la discusión consideraban que el nuevo comportamiento tenía mucho más sentido que el anterior, pero ahora que también llegaron opiniones en contra, se puede seguir discutiendo el comportamiento y después hablar del valor predeterminado”.
  Creo que la forma en que se desarrolla Emacs tiene problemas serios, pero también es un problema que los usuarios normalmente culpen a la gente obstinada de emacs-devel y, cuando entra un cambio que no les gusta, actúen como si fuera el fin del mundo. Eso hace que los mantenedores se pongan a la defensiva.

  • No está bien hacer un escándalo porque apareció un cambio que rompe la compatibilidad mientras se usa la rama de desarrollo. En una rama de desarrollo, eso es esperable.
    Si se lee el hilo de correos, más que “arrogancia” parece una discrepancia fuerte, y llegar a un consenso inevitablemente toma tiempo. Llamar públicamente “arrogante” a alguien porque no retrocede de inmediato ante tu punto de vista, y tratar de atraer a una multitud que ni siquiera va a leer el hilo, se parece bastante al acoso.
    Además, tampoco es honesto decir que se ignoró un parche que hacía opcional el cambio. Ese parche no solo agregaba la opción, sino que también eliminaba otros cambios, y por eso fue rechazado; y también es difícil aceptar que se le cargue la responsabilidad a una sola persona de esa manera.
  • Decir que “la reacción de los usuarios es un insumo clave para la decisión final” y, al mismo tiempo, criticar las reacciones negativas de los usuarios como “exageradas” parece contradictorio.
    Si los usuarios no hubieran reaccionado, según el procedimiento descrito, es muy probable que el cambio original al que se oponían hubiera entrado tal cual. En clojure-mode, rms también intentó tomar el nombre del autor de la comunidad de Clojure que lo había mantenido durante mucho tiempo y reescribirlo; la gente protestó en la lista y lo impidió, pero luego a esas mismas personas se les dijo que estaban exagerando. Por eso, la crítica de “exageración” no parece tener mucho sentido.
  • Este es un mal proceso. La revisión de una funcionalidad debería empezar antes de fusionarla en la rama principal, no después.
    Si se mete en la rama principal una funcionalidad que rompe los flujos de los usuarios sin discutirlo con la comunidad más amplia, es natural que la gente se enoje. Ese tipo de fusiones es la forma en que una herramienta antigua pierde el apoyo de su comunidad.
  • La comunidad de Emacs, al menos históricamente, ha valorado muchísimo la compatibilidad hacia atrás. Romperles cosas a los usuarios existentes es casi de lo peor que se puede hacer en Emacs.
    Si no se considera seriamente revertir de inmediato un cambio que rompe la compatibilidad, eso es una señal de que los desarrolladores de Emacs ya no valoran la compatibilidad hacia atrás tanto como antes, y eso significa dejar atrás a una parte importante de los usuarios actuales.
    https://www.murilopereira.com/the-values-of-emacs-the-neovim...
    Los valores centrales importan. Los mantenedores de Emacs violaron valores centrales, y es legítimo que la comunidad esté molesta.
  • Si la explicación del artículo es correcta, me preocupa la salud de Emacs. Ya había controversia desde antes de que se fusionara en master, pero aun así lo fusionaron.
    Romper el flujo de trabajo de los usuarios sin siquiera hacerlo opcional, ni opt-in, ni siquiera permitir desactivarlo, parece un desdén descuidado por la experiencia de usuario.

• Para resumir lo que entendí: hace poco se aceptó en Emacs un commit que cambia una operación de registros, algo más general que copiar.
  Ahora Emacs abre el minibúfer para mostrar qué está pasando, y hay que aprobar el cambio con Enter o una entrada equivalente. El autor del texto original lo ve como una ruptura de compatibilidad terrible porque cambia el comportamiento predeterminado, quizá no pueda desactivarse fácilmente con una configuración y no hubo suficiente discusión.
  Haciendo una analogía con Vim, sería como escribir "dyy para copiar la línea actual al registro d, y que después se abra un búfer scratch que muestre el texto y el búfer, y pida una tecla para cerrarlo. Para un usuario común de Vim que entiende los registros sería horrible, aunque también hay quienes prefieren una acción que “muestre explícitamente qué se copia”, como las personas que copian desde el modo visual.
  El resto del texto dice que el autor original intentó generar discusión, pero Thierry, el autor del commit, la bloqueó, y que implícitamente el resto de la comunidad de desarrollo de Emacs también tiene responsabilidad.

  • Los registros son una función relativamente avanzada y se usan sobre todo para edición rápida. Están pensados más para quienes hacen operaciones complejas rápidamente que para usuarios primerizos que usan el mouse.
    He usado Emacs durante décadas, pero nunca profundicé mucho en los registros; personalmente uso kill/yank para copiar, y cursores múltiples o macros de teclado de una sola vez para ediciones complejas. Aun así, Emacs tiene muchas funciones avanzadas opcionales de edición para quienes quieren apoyarse en la memoria muscular.
    Agregar aquí una tecla de confirmación se siente raro. Es parecido a ponerle a un piano eléctrico un “pedal para confirmar acordes inusuales”: añade un paso más a una acción de entrada rápida y compleja.
    Emacs tiene un excelente deshacer, así que en vez de preguntar “¿quieres pegar lo que hay en el registro d?”, debería simplemente pegarlo y dejar que el usuario deshaga si eligió mal.
    Por eso romper la compatibilidad aquí es extraño, y si no hay forma de desactivarlo, es comprensible que muchos usuarios se enojen. Emacs es una herramienta más antigua que las convenciones modernas de GUI, así que no puede resultar tan familiar para usuarios nuevos como vscodium; también tiene sentido enfocarse en servir lo mejor posible a los usuarios avanzados.
  • Para quienes no usan Emacs, conviene aclarar que la copia estándar, kill-ring-save, por defecto M-w, no se ve afectada; solo cambia una función más avanzada: guardar en registros.
    Los registros no son un superconjunto del portapapeles, es decir, del kill ring.
    Además, quienes dicen que este cambio no será configurable parecen no conocer bien cuán personalizable es Emacs. La “configuración” existe por comodidad, pero si quieres puedes cambiar el código completo. Esto está en la parte Elisp de Emacs y, aunque entrara tal cual, en minutos aparecería un paquete que cambie el comportamiento. No hace falta un fork; hablar de forks aquí es, como mucho, un gesto performativo.
  • Si este cambio llega en v30, creo que va a ser bastante molesto. No sé nada de Lisp, pero siempre guardo elementos en registros.
    Si no se revierte, espero poder encontrar algún fragmento de macro que se encargue de la tecla adicional por mí. Emacs ya requiere muchas pulsaciones incluso para cosas simples, y no soy lo bastante experto como para hacer yo mismo una macro para este cambio.
  • Como resumen del texto está bien, pero si uno mira la lista de correo, se queda corto como resumen del problema.
    Esto parece haber empezado cuando Thierry encontró varios problemas en el comportamiento de los registros e intentó corregirlos.
    La falla más importante era que, después de presionar C-x r SPC para save-to-register, cualquier tecla que se presionara a continuación guardaba el texto en el registro correspondiente a esa tecla. En particular, C-g, la tecla universal de cancelación de Emacs, tampoco funcionaba ahí, sino que guardaba texto o una posición en un registro llamado ^g. Incluso si presionabas por error jump-to-register o insert-register, no podías cancelar con C-g u otra tecla similar: estabas obligado a elegir un registro.
    Segundo, un registro puede contener texto, una posición o un valor vacío. jump-to-register solo funciona con registros que contienen posiciones, e insert-register espera texto. Emacs ofrecía una vista previa de registros no vacíos al ejecutar comandos, pero no distinguía, por ejemplo, y mostraba también registros con cadenas como candidatos para jump-to-register.
    Thierry intentó arreglar esos problemas y atender el feedback de la revisión de código, y los revisores consideraron que era un cambio importante aunque agregara interacción adicional. Es decir, vieron como aceptable la ruptura de compatibilidad de tener que presionar RET después de elegir un registro normal, o usar una tecla adicional para guardar en registros extraños como ^g, frente a los beneficios obtenidos.
    El autor original pidió un switch para alternar entre el comportamiento nuevo y el viejo, y recibió como respuesta que enviara un parche; pero el parche que presentó revertía todas las mejoras mencionadas e implementaba mediante un flag una función totalmente distinta: “confirmar la sobrescritura de registros no vacíos”. Thierry lo probó, dio feedback breve, y el autor respondió básicamente “no hace falta eso”.
    Después, cuando más gente usó la función, quedó claro que la creencia de Thierry y de los primeros revisores de que el impacto del cambio incompatible era pequeño estaba equivocada, y Thierry empezó a crear un flag que mantuviera el trabajo nuevo pero también permitiera el flujo anterior. En particular, eliminar el RET adicional no era lo esencial, sino más bien un efecto secundario.
    En general, el proceso parece haber funcionado bastante bien, y quien más se acerca a intentar imponer la discusión ignorando el contexto, con una actitud antihacker de “si más o menos funciona, no debe cambiarse de ninguna manera”, es el autor original.
  • Como principiante en Vim, yo habría esperado que dyy significara borrar la línea actual.
    Pero probablemente eso mismo sea prueba de que soy principiante.

• Al ver este hilo de la lista de correo, parece que habrá una opción para revertir ese comportamiento: https://yhetil.org/emacs/[e-mail]/#t
  Parece que esta opción ya se había mencionado antes de que se publicara el texto original, aunque quizá el autor no la vio. Creo que esto resolverá el problema, pero tal vez se me esté escapando algo.
  Edición: por la respuesta de ginko más abajo, parece que todavía hará falta presionar RETURN.

  • Aun así, parece que para confirmar la sobrescritura de un registro sigue haciendo falta un RET adicional.
    https://yhetil.org/emacs/[e-mail]/
  • Al ver ese hilo, register-use-previews parece ser el interruptor de este comportamiento.
    Sin embargo, se menciona un bug por el cual, incluso al configurarlo en never, aparece una confirmación en ciertos flujos de trabajo. Si de verdad es una opción, creo que se resolvería la mayor parte de las preocupaciones.

• En Emacs, la memoria muscular debería elevarse a una preocupación de primer orden

  • Alguna vez salió una nueva versión de un administrador de archivos que me gustaba, y cambió los atajos de teclado. Ya ni recuerdo su nombre, pero la rabia que sentí entonces se me quedó grabada, al punto de que incluso en ese momento me pareció desmedida.
    Fue porque me arruinaron la memoria muscular acumulada. Antes de calmarme, hasta tuve pensamientos bastante malvados. Puede parecer algo menor, pero entiendo por qué la reacción ante el crimen de “traicionar la memoria muscular” puede escalar hasta un “fork you”.
  • No es algo exclusivo de Emacs. No tengo ningún interés en Emacs, pero esta historia importa porque muestra la arrogancia de los desarrolladores que intentan “mejorar” algo sin considerar las expectativas estables de la gente.
    Esto aplica igual a Google Maps o iOS que a Emacs.
  • En términos más generales, el software de uso frecuente debería diseñarse para permitir la memorización muscular, y las versiones posteriores no deberían romperla sin una razón justificada.
    La memoria muscular permite operar el software de forma semi-asíncrona, “sin mirar”, sin tener que confirmar visualmente cada microinteracción. Lamentablemente, en el software de escritorio hay una tendencia a hacer que el uso con teclado sea cada vez más engorroso, o directamente imposible.
  • Como mínimo, cualquier transición que rompa la memoria muscular debería ser un toggle cuyo valor predeterminado sea “mantener mi configuración como antes”.

• Es un buen rant, pero no ayuda a convencer que ni siquiera explique cuál es la función de la que habla.
  Los registros de Emacs son una abstracción muy antigua. Un registro permite guardar y recuperar valores como si fuera un portapapeles separado, y hay 62 asociados a los símbolos ASCII principales [a-zA-Z0-9], lo que ofrece una interfaz de teclado flexible y rápida. También permiten cosas interesantes, como ejecutar macros de teclado desde un registro. Hay gente que los usa mucho, aunque yo personalmente no los uso.
  El motivo del enojo del autor es que cambió el binding predeterminado, de modo que una tarea que antes podía hacerse completamente con el teclado y desde la home row ahora tiene una interfaz modal interpuesta. Suena como una queja razonable, y creo que a mí también me molestaría si cambiaran así una función grabada en mi memoria muscular.

  • Dejé Emacs hace mucho, pero dependía mucho del búfer de selección de X11, es decir, pegar con clic medio, así que lo entiendo.
    Si entre cada selección y pegado apareciera un cuadro de diálogo modal de confirmación, y no hubiera una configuración para volver al comportamiento anterior, sin duda me enojaría. Bastaría con implementar el comportamiento anterior como opción. Literalmente serían unas pocas líneas de código.
  • Hay más de 62 registros. Una de las quejas es que el minibuffer rompe, por ejemplo, el acceso al registro C-a.
    Conozco gente que usa letras para ubicaciones y C-letra para texto. Para algunos puede ser un caso muy raro, pero me imagino que esas personas estarían muy molestas.
  • Eli no parece querer fijar esto como comportamiento predeterminado. Yo tampoco soy fan.
    En https://yhetil.org/emacs/[e-mail]/, Eli dice: “Como llegaron objeciones, seguimos discutiendo cuál debería ser el comportamiento, y cuando lleguemos a una conclusión podremos hablar del valor predeterminado”.
  • Decir “binding predeterminado” suena a que se puede configurar de otra manera, pero ¿realmente se puede?
  • Es, en la práctica, como activar un uac-mode global imposible de desactivar en todos los buffers. Si no es cierto, entonces es para reírse y seguir de largo.

• La interpretación del autor del post original no es buena. Los usuarios que quieren estabilidad deberían estar en una rama de release o fijar un commit de master.
  Hay que esperar que una rama de desarrollo se use para desarrollar funciones en curso, y que estas puedan tardar en pulirse. Si sigues master, te vas a encontrar con frecuencia con cambios que rompen compatibilidad, y si algo rompe tu flujo de trabajo deberías estar acostumbrado a volver a un commit anterior. Una mejor opción es quedarse en los releases.

• El punto central de Emacs es que es una plataforma extremadamente personalizable, así que si no te gusta el comportamiento de alguna función, puedes modificarlo tú mismo con unas pocas líneas de Lisp.
  Forkear todo el proyecto por un cambio en una función obscure no tiene ningún sentido. Uso Emacs desde alrededor de 1981, cuando estaba implementado con macros de TECO, pero no uso registros.

  • Para ser una plataforma extremadamente personalizable, la plataforma en sí tiene que ser muy estable.
    Si no, cada vez que cambia la plataforma todos tienen que reescribir o arreglar todas sus personalizaciones.
  • No sé cuál es la diferencia entre “modificarlo tú mismo” y “hacer un fork”.
    Si este parche queda tal cual y alguien quiere usarlo exactamente como antes, en la práctica tiene que aplicar un parche de reversión en su repositorio local de Emacs y montar sus cambios encima. Cada vez que upstream Emacs cambie, tendrá que hacer rebase para traer los cambios nuevos.
    Eso es un fork privado. Queda forked para siempre, haciendo rebase para siempre.
    También se podría hacer algo tipo monkey patch, cargando un archivo propio en lugar del archivo shipped, o después de él, para redefinir la función, pero eso también es una especie de fork. Hay que guardar ese material en algún lugar como proyecto, y estar listo para ajustarlo cuando un cambio rompa el monkey patch.
  • Parece que se les pasó la parte de que este cambio no incluía ninguna función para volver al comportamiento anterior mediante configuración.

• Dejé Emacs hace 20 años, pero entiendo que este cambio es bastante disruptivo.
  Lo que no entiendo es por qué Emacs, que presume de “tener hasta el fregadero de la cocina”, no agregó una opción para volver al comportamiento anterior.

  • Probablemente terminen agregando esa opción. El autor original solo está enojado porque no aceptaron su parche.
    Ese parche agregaba un flag, pero también eliminaba todas las demás mejoras.

• El tono del texto se siente bastante “neckbeard”. Es una función increíblemente obscure que usan tres nerds, no la escalera inamovible de la Iglesia del Santo Sepulcro.
  Que un mantenedor no remunerado la haya cambiado un poco sin preguntarte antes no necesariamente significa que “rompió master”. Estamos hablando de master, no de una versión estable ni de un release etiquetado.

• Obviamente, la única solución posible es intentar otro fork o reimplementación de Emacs.
  Esta vez seguramente tendrá éxito y no terminará siendo algo completamente irrelevante como los demás.

  • El impacto de estos forks está en la erosión gradual de la comunidad alrededor del proyecto principal.
    Pero no importa mucho si el fork lleva al proyecto principal a la mesa de negociación. El autor del post original tiene la capacidad y la voluntad de mantener ese parche en su repositorio local hasta el final. Lo único que falta para completar el fork es publicar ese repositorio local.
  • Solo con leer el post del blog no queda muy claro qué intención de largo plazo tiene el autor respecto del fork.
    Quizás sea una forma de convencer a los mantenedores de mainline.