Migrarse de lsp-mode a Eglot en GNU Emacs

• Partes de Wandering Thoughts y CSpace muestran una página de bloqueo cuando un User-Agent de navegador antiguo activa reglas anti-crawlers
• A inicios de 2025 aumentaron los crawlers masivos, y algunos parecen buscar recolectar datos para entrenamiento de LLM, usando User-Agents antiguos de Chrome
• Se está probando bloquear User-Agents de navegadores antiguos para reducir la carga del sitio, y usuarios legítimos también pueden verse afectados por falsos positivos
• Si el bloqueo aparece incluso en navegadores modernos, se puede contactar a través de la página personal de la Univ. de Toronto y se debe enviar el navegador y la cadena exacta de User-Agent
• La familia archive.* es difícil de distinguir por sus User-Agents antiguos de Chrome e IPs distribuidas, por lo que para el archivo de Wandering Thoughts se recomienda archive.org

---

Por qué aparece la página de bloqueo

• Al acceder a Wandering Thoughts o a algunas partes de CSpace, aparece una página de bloqueo si la versión del navegador es clasificada como sospechosa por las reglas anti-crawlers del sitio
• A inicios de 2025 aumentaron los crawlers masivos, y algunos parecen estar orientados a recolectar datos para entrenamiento de LLM, usando varios User-Agents de navegadores antiguos, incluido Chrome User-Agent antiguo
• Se está realizando una prueba de bloqueo de User-Agents de navegadores antiguos para reducir la carga del sitio, y usuarios legítimos también pueden quedar atrapados por esta regla
• Si usas un navegador moderno y aun así te bloquean, puedes contactarlos a través de la página personal de la Univ. de Toronto y, de ser posible, debes enviar también el navegador que usas y la cadena exacta de User-Agent

Notas según el tipo de usuario

• Usuarios de Inoreader

  • El recolector de feeds de Inoreader en sí no es objetivo del bloqueo, y de hecho sigue obteniendo los feeds periódicamente
  • Inoreader puede recuperar el feed o la página usando un HTTP User-Agent de navegador antiguo o un navegador realmente antiguo, y luego mostrar al usuario la página de bloqueo que recibió como resultado
  • Los resultados recientes de solicitudes HTTP pueden variar según el HTTP User-Agent utilizado; hay más detalles en HTTPResultsAndUserAgents

• Usuarios de Vivaldi

  • Debido al ataque en curso, incluso la versión más reciente de Vivaldi puede ser bloqueada si se identifica como Google Chrome
  • Puede ser necesario cambiar la configuración de "User Agent Brand Masking" para que Vivaldi se identifique como Vivaldi y no como Google Chrome

• Usuarios de archive.*

  • Puedes ver esta página de bloqueo a través de archive.today, archive.ph, archive.is, etc.
  • archive.* usa un Chrome User-Agent antiguo, rastrea desde bloques de IP ampliamente distribuidos y algunas IP tienen entradas de DNS inverso falsificadas que afirman ser IPs de googlebot, por lo que es difícil distinguirlo de actores maliciosos
  • Si quieres archivar Wandering Thoughts, se recomienda usar archive.org, cuyo crawler de archivado funciona mejor

[GN⁺]

Opiniones en Lobste.rs

• Dependiendo del lenguaje, el consejo de iniciar Eglot automáticamente puede ser terriblemente malo. Muchos servidores LSP no son seguros para usarse con código no confiable, y con solo abrir archivos de un proyecto de Rust o Elixir controlado por un atacante tu máquina podría verse comprometida
  A menos que sea un lenguaje con un servidor LSP conocido por ser seguro, conviene evitar la activación automática de LSP. Referencia: https://rust-analyzer.github.io/book/security.html

  • Si vas a mirar código potencialmente hostil, al final todo el trabajo debería hacerse dentro de un límite de seguridad real. Incluso git status puede ser una superficie de ataque: https://github.com/justinsteven/advisories/…
    La diferencia es que en ese caso el exploit tiene que estar en el propio repositorio, mientras que con LSP también puede venir por el lado de las dependencias. Aun así, si te acostumbras a tener LSP encendido por inercia, parece difícil evitar volverte insensible a las advertencias
  • Otra razón para evitar el inicio automático es que algunos servidores de lenguaje tienen requisitos de recursos muy altos. En un proyecto Rust de tamaño medio, con solo abrir un archivo por un momento puede quedarse corriendo durante varios minutos un proceso rust-analyzer de 4 GB y aparecer un directorio target/debug/ de más de 1 GB
  • De todos modos, en cuanto ejecutaste cargo build ya casi da lo mismo. Claro, hay una gran diferencia entre la carga automática de LSP y un comando que el usuario ejecuta explícitamente, pero en la práctica la diferencia quizá sea menor de lo que parece
  • Si quieres automatización, es mejor que pregunte antes de activarse, como lsp-mode, y que agregue el proyecto a una lista de permitidos. Si ya tienes un hook que “ejecuta automáticamente”, con unas 10 líneas puedes hacer que primero pregunte con read-from-minibuffer “¿Confías en esta carpeta?” y, si usas algo como projectile para fijar el directorio base, obtienes la mayor parte de la ventaja de seguridad
    En mi configuración uso la lista de permitidos de lsp-mode, pero la borro en cada sesión, así que cada vez que vuelvo a abrir Emacs tengo que aceptar otra vez por proyecto. Creo que originalmente lo hice por rendimiento, porque a veces lsp-mode levantaba varios procesos incluso antes de abrir cierto proyecto. El riesgo de seguridad es real, pero no es tan difícil armar un flujo de trabajo razonable

• Lo más molesto de Eglot es que no expone la mayoría de sus comandos como funciones, sino que los define sobre interfaces de Emacs como xref. Cuando tienes ambos backends de xref, CIDER y clojure-lsp, como pasa con Clojure, terminas prefiriendo el lado de CIDER, que sí conoce el estado real en tiempo de ejecución del código cargado
  El análisis estático de clojure-lsp puede desincronizarse, sobre todo en flujos de trabajo con REPL remota. En lsp-mode puedes seguir usando xref y a la vez invocar directamente comandos como ir a definición, pero en Eglot quitar solo un backend específico de xref es bastante engorroso. También faltan en Eglot otros comandos que sí están en lsp-mode, aunque en realidad son funcionalidades que podrían ofrecerse mediante puntos de integración de Emacs parecidos a xref

• Probé lsp-mode una vez, pero me aparecieron demasiados popups y notificaciones confusas, así que lo borré enseguida. Eglot da una experiencia de LSP mucho más silenciosa
  Lo dejas encendido y usas las funciones cuando ya estás listo. Es interesante cómo ~cks aborda el tema desde la dirección opuesta y va mencionando varios consejos y alternativas

  • En lsp-mode desactivé muchas funciones y lo uso con una interfaz bastante silenciosa. Quise cambiarme a Eglot, pero no parecía tener la integración que yo quería, así que no seguí intentando en ese momento
    Lo que de verdad me gustaría encontrar es un servidor LSP capaz de manejar repositorios muy grandes. Eso me ha topado seguido con límites, y me hace pensar si debería construir algo que haga la mayor parte de la indexación del código fuente de una vez y luego la reutilice para varias tareas tipo LSP, aunque me preocupa estar intentando hervir otro océano

• Eglot y lsp-mode son los clientes LSP para Emacs más conocidos, pero también hay alternativas como lspce y lsp-bridge
  Llevo años usando Eglot con satisfacción, pero tiene una limitación de diseño que podría volverse más problemática en el futuro. Asume un cliente por buffer; cuando se creó Eglot eso era razonable, pero ahora cada vez es más común querer correr varios servidores LSP en un mismo buffer. La recommendation actual es usar un programa aparte como multiplexor de LSP

  • Para eso está this

• Hace 4 días me cambié de lsp-mode a Eglot para Python y estoy satisfecho
  Aquí publiqué la versión mínima de mi configuración actual: https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

  • Hace casi un año me cambié de elpy a eglot + basedpyright, y yo también estoy bastante satisfecho
    Eso sí, tengo algunas molestias con el autocompletado. Por ejemplo, si presiono foo<tab><tab>, a veces basedpyright autoimporta algo raro aunque haya un símbolo que encaja con el scope actual, y todavía no encuentro una forma de completar solo hasta la cadena común más larga. Fuera de eso, está bastante bien

• Me dan envidia las personas que hacen que Emacs se comporte como un IDE moderno. Uso los atajos de Emacs, pero ni dedicándole 6 a 8 horas he logrado hacer que Emacs funcione como IDE
  Antes traté de ajustarlo para FB Flow, que usaba en lugar de TypeScript en entornos de desarrollo de Linux y FreeBSD, y lo abandoné; el fin de semana pasado volví a rendirme intentando armar en Windows un entorno Python completo con tree-sitter. Hay demasiadas cosas por configurar y también demasiados DLL aparte que bajar, como los parsers de tree-sitter, así que se siente excesivo todo lo que hace falta para dejarlo como un IDE de verdad. Ya no quiero invertirle tiempo, aunque sí me gusta que en cualquier terminal pueda escribir emacs -nw y aparezca mi entorno de edición conocido

  • Para Python, una configuración mínima con fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure y basedpyright ya alcanza para empezar bien
    Si basedpyright está en el path, puedes tener autocompletado y resaltado de sintaxis correctos incluso sin gramática de tree-sitter. Es una versión reducida al mínimo de mi configuración completa, y la configuración completa está en my full config
  • Vale la pena probar doom emacs. Configurarlo es muy fácil y en su estado predeterminado ya funciona bien en la mayoría de los casos. Si no te gusta evil-mode, también puedes volver a los atajos de Emacs