En Emacs, todo parece un servicio

 (yummymelon.com)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Emacs, más que ser un sistema operativo en sí, orquesta aplicaciones y utilidades sobre el kernel, y se convierte en cliente de diversos servicios aprovechando el sistema de archivos, la red y programas externos
  • Las capas de UI, comunicación y almacenamiento local de datos que necesita un cliente pueden construirse con bibliotecas integradas como minibuffers, buffers, URL, TCP/UDP, JSON y SQLite
  • Emacs Lisp (Elisp), al ser un lenguaje dinámico, combina funciones de Elisp y comandos de shell en tiempo de ejecución para orquestar con flexibilidad las capacidades a las que Emacs puede acceder
  • El comando de ejemplo wttr recibe una ubicación, envía una solicitud HTTP a wttr.in, extrae de JSON la región, la temperatura y el clima, lo muestra en el minibuffer y también lo guarda en el kill ring
  • Todo wttr.el tiene 67 líneas según cloc; si se delegan las solicitudes de red y el procesamiento de JSON a herramientas de línea de comandos como Python, también se puede crear un cliente Elisp más corto que trate al propio comando de shell como un servicio

Emacs orquesta servicios sobre el sistema operativo

  • Llamar a Emacs un sistema operativo no es exacto, pero la comparación surge por su capacidad de orquestar aplicaciones y utilidades sobre el kernel del sistema operativo
  • Como puede acceder con funciones integradas a servicios del sistema operativo como el sistema de archivos y la red, y también ejecutar otros programas, es fácil armar sobre la marcha comportamientos de cliente dentro de Emacs
  • Dado que permite resolver muchas tareas de cómputo mediante distintos modos de cliente, también tiene sentido la idea de que el usuario “vive solamente dentro de Emacs”

El modelo cliente-servidor visto como solicitudes y respuestas

  • El modelo cliente-servidor es un patrón de interacción en el que un servicio que proporciona recursos y un cliente que los solicita se reparten el trabajo
    • El cliente envía una solicitud
    • El servidor procesa la solicitud y devuelve una respuesta
  • Las transacciones formadas por solicitudes y respuestas pueden realizarse a través de la red o localmente dentro de un mismo sistema
  • El modelo basado en red se desarrolló ampliamente en la arquitectura de software de estilo REST

Las tres áreas que componen un cliente de Emacs

  • Un cliente típico se encarga de estas tres áreas
    • UI: procesa la entrada y la salida del usuario según sea necesario
    • Borde del cliente (Client Edge): se comunica con el servicio; en clientes de red, el subsistema de red cumple este rol
    • Base de datos local: representa los datos que se intercambian o sincronizan con el servidor, y la forma concreta de administrarlos depende de los requisitos de implementación

  • Construcción de la interfaz de usuario

  • Comunicación con servicios y transformación de datos

    • Para el borde del cliente que se conecta al servicio se pueden usar estas funciones
    • Para la serialización y deserialización se usan parsers integrados

  • Gestión de datos locales

    • Para una representación local de los datos del servidor se pueden usar colecciones de Elisp
    • Si se necesita almacenamiento local persistente, se puede usar SQLite
    • La complejidad de un cliente real depende de los requisitos, y si ya existe una utilidad de línea de comandos para encargarse del procesamiento pesado, puede replantearse como un servicio accesible mediante llamadas de shell

Cómo combinar funcionalidades con Elisp

  • Todas las bibliotecas anteriores son accesibles desde Emacs Lisp (Elisp)
  • Elisp es un lenguaje de programación dinámico que permite una composición improvisada de alto nivel durante la ejecución
  • Puede orquestar flujos complejos combinando acciones que Emacs puede usar, desde funciones de Elisp hasta comandos de shell

Implementación de un cliente meteorológico para wttr.in

  • wttr.in es un servicio web de pronóstico del tiempo centrado en la consola y admite salida JSON
  • El comando wttr para Emacs funciona en este orden
    1. Pide al usuario una ubicación
    2. Genera la URL de solicitud a wttr.in
    3. Envía la solicitud HTTP
    4. Procesa la respuesta JSON
    5. Muestra el resultado en el minibuffer y lo guarda en el kill ring
    6. Si ocurre un error durante el procesamiento, muestra un mensaje de error en el minibuffer

  • Crear la URL de solicitud

    • wttr--request-url usa https://wttr.in como URL base
    • Reemplaza los espacios de la ubicación ingresada por + y genera una consulta con la forma /<location>?0&format=j1
    • La URL completa se pasa luego a la función para obtener JSON

  • Solicitud HTTP y parsing de JSON

    • fetch-json-as-hash-table obtiene la URL de forma síncrona con url-retrieve-synchronously
    • Si no recibe datos, genera el error Failed to fetch data from <URL>
    • En el buffer de respuesta, avanza hasta después de los encabezados de metadatos HTTP y luego convierte el contenido restante en una hash-table de Elisp con json-parse-buffer
    • Al terminar el procesamiento, siempre elimina el buffer de red descargado para evitar fugas de memoria

  • Composición del mensaje del clima

    • wttr--report-message extrae estos valores de los datos JSON
      • Nombre de la localidad más cercana
      • Región
      • País
      • Temperatura actual en Celsius temp_C
      • Temperatura actual en Fahrenheit temp_F
      • Descripción del clima weatherDesc
    • Une con comas los elementos de ubicación que no estén vacíos y crea un resultado con el formato ubicación: Celsius, Fahrenheit descripción del clima
    • La implementación completa puede consultarse en el código fuente de wttr.el

Usar herramientas de línea de comandos también como servicios

  • La API de Emacs ofrece abstracciones de alto nivel, y wttr.el, que implementa directamente las solicitudes HTTP y el procesamiento de JSON, también tiene 67 líneas según cloc
  • Una alternativa más simple es delegar la solicitud de red real y el procesamiento de JSON a un script de Python llamado weather
    • El comando weather de Elisp pide al usuario una ubicación
    • Construye un comando de shell weather agregando la ubicación como argumento
    • Ejecuta el comando con shell-command-to-string
    • Guarda el resultado devuelto en el kill ring y lo muestra en el minibuffer
  • En esta configuración, el comando de shell se convierte en el servicio que recibe solicitudes y la función de Elisp actúa como cliente
  • Gracias a la naturaleza dinámica de Elisp, las bibliotecas de Elisp y las utilidades de línea de comandos pueden combinarse según sea necesario, y esta posibilidad de integración permite tratar todo dentro de Emacs como si fuera un servicio

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Hacker News

  • Como la familia de las Lisp Machines no llegó a convertirse en la corriente dominante, Emacs simplemente se ve como un sistema operativo
    “Symbolics Lisp Machine demo”
    https://www.youtube.com/watch?v=o4-YnLpLgtk
    “Emacs and Lisp”
    https://funcall.blogspot.com/2025/04/emacs-and-lisp.html
    Lucid hizo un fork de Emacs como XEmacs para intentar implementar una de las primeras ideas de LSP, y la mayoría de las funciones de esa época ya se reintegraron en Emacs
    https://dreamsongs.com/Cadillac.html
    “Lucid Energize Demo”
    https://www.youtube.com/watch?v=pQQTScuApWk

    • Un sistema operativo es una máquina virtual diseñada para que varios programas la compartan. Normalmente expone la mayor parte de la arquitectura del conjunto de instrucciones (ISA) sobre la que se ejecuta, aunque hay excepciones como Inferno, Taos y AS/400
    • Aunque las máquinas LISP hubieran tenido éxito, el editor que se ejecutara sobre ellas no se convertiría en el sistema operativo. Si se confunden plataforma y sistema operativo, se podría llamar sistema operativo a un navegador web o incluso a Roblox

  • Si se definen client, server y request con suficiente amplitud, cualquier cosa puede encajar en una arquitectura cliente/servidor. Es parecido a esforzarse por afirmar que Emacs sigue la filosofía Unix solo porque una función LISP hace bien una sola cosa
    La mayoría puede estar de acuerdo en que Emacs sigue la idea de las máquinas LISP, y sobre él se puede implementar prácticamente cualquier cosa que uno quiera. Se integra de maravilla con herramientas CLI, pero no queda claro qué se gana definiendo eso como cliente/servidor
    Durante décadas fue absorbiendo funciones al pasar por varias modas, y por dentro incluso tiene el motor de análisis semántico CEDET, que hoy casi no se usa. Luego llegó LSP, y ahora estamos en la era de los agentes; Emacs también funciona bastante bien como frontend para agentes

    • Emacs es un refugiado LISP que huyó al mundo Unix. No sigue la filosofía Unix, sino la filosofía LISP, pero se integra bien con Unix
    • En el pasado era común que la mayoría de los IDE tuvieran su propio motor de análisis semántico. Si no recuerdo mal, el primer servidor de lenguaje para Java también se separó del motor de análisis semántico de Java de Eclipse

  • Usé Emacs durante más de 25 años, pero en la empresa a la que me cambié el año pasado no me dejan usarlo ni siquiera para tareas en las que Emacs encaja especialmente bien. La razón fue que todos los miembros del equipo debían usar la misma herramienta, y no logré convencer a los demás de pasarse a Emacs
    Ahora estoy usando, de forma mucho menos eficiente, herramientas de propósito único separadas para cada tarea, mientras sigo aprendiendo nuevas interfaces y mapeos de teclas

    • A medida que la empresa creció, empezó a controlar el software instalado, y parece que administra lo permitido y lo bloqueado con Microsoft Intune. Estoy postergando incluso actualizar o cambiar mi laptop por miedo a no poder usar más Emacs
      El administrador dirá que en los proyectos nuevos todos usemos Visual Studio Code, pero el modelo de consumo que usamos ni siquiera es compatible con VSCode. Si Git y el procedimiento de despliegue coinciden, cada quien debería poder elegir el editor que mejor maneje; pero supongo que la respuesta será que, al ser open source sin soporte de Microsoft, es riesgoso y es software no validado por la empresa
      Emacs es una herramienta central que uso todos los días, así que si lo prohíben pienso renunciar. El administrador no intenta entender ni razonar lógicamente; solo sigue instrucciones de otro departamento de TI
    • ¿También dirían que es razonable obligar a todos los miembros del equipo a usar telnet y prohibir ssh? Lo importante es no pedir permiso para usar Emacs, sino simplemente usarlo
      Si la empresa designó un editor de texto de uso general, vale la pena comprobar si incluso ejecutar Notepad sería un problema, o si también designaron una herramienta personal de gestión de tareas. Busca una categoría de cosas que Emacs pueda hacer y para la que la empresa aún no haya designado una herramienta, e instálalo para ese uso
    • Es la misma lógica que decir que, como para manejar personalidades distintas habría que tratar a cada persona de manera diferente y eso es ineficiente, se les practicó una lobotomía frontal a todos los miembros del equipo
    • Si otras herramientas tuvieran tanta libertad y posibilidad de modificación como Emacs, los usuarios de Emacs tampoco intentarían meter todo su trabajo dentro de él. No es que Emacs sea necesariamente superior; más bien otras herramientas son más restrictivas y tienen peor autodocumentación
    • Me pregunto por qué sería válida la afirmación de que todos los miembros del equipo deben usar la misma herramienta

  • Emacs es una plataforma, y un sistema operativo también es solo una de varias plataformas. Una plataforma es una capa de software diseñada para permitir construir cosas nuevas encima, así que la pregunta debería ser qué plataforma X es adecuada para el Y que se quiere crear
    Para mí, X muchas veces es Emacs, pero también podría ser Racket o Rust. Si una herramienta es una aplicación y además una buena plataforma, vale la pena invertir más en aprenderla que en una aplicación simple

  • Haber usado Emacs lo suficiente como para entender que “Emacs es un sistema operativo” no como una broma, sino como un concepto que realmente se puede creer, fue un punto de inflexión importante en mi carrera

    • Ya existía un sistema operativo y también se podía programar, así que me pregunto si Emacs de verdad aportó una capacidad nueva. Emacs es un editor de texto, no un IDE ni un entorno general de ejecución de automatizaciones; me cuesta entender la lógica de que agregarle Lisp a MSPaint lo convertiría de pronto en una herramienta impresionante

  • Empecé a usar Emacs hace unos años para probar org mode, y terminé quedándome por su flexibilidad extremadamente alta

    • Usé Spacemacs durante un tiempo, pero ahora que conseguí un Keychron G6 Pro que permite reprogramar Caps Lock, pienso empezar en serio a configurar mi propio init.el

  • Emacs se parece más a un entorno de programación con un editor de texto integrado. Si se lo ve como algo parecido a algunas imágenes de Smalltalk, resulta una herramienta bastante interesante

  • Emacs no es un sistema operativo, sino más bien un shell, aunque el concepto mismo de shell no se entiende de forma generalizada

    • Si se ve el shell como un medio para usar otras herramientas, vi en realidad se parece más a un shell. Eso es porque muchas funciones deben delegarse a otros programas estándar de Unix con :.!
      En cambio, Emacs incluye todo tipo de funciones en una enorme distribución, como un sistema operativo

  • Hace poco encontré un video introductorio corto que es bueno para mostrárselo a gente que no usa Emacs
    https://www.youtube.com/watch?v=mJZDmO5yOxE

    • Me dio mucha curiosidad el init.el de Anon Emoose

  • Emacs en sí puede ejecutarse como cliente y servidor. Si se inicia el servidor con emacs --daemon y luego se conecta con emacsclient, todas las instancias de terminal y GUI usan el mismo servidor y comparten archivos abiertos y buffers
    Por desgracia, solo funcionaba en local; intenté reenviar por ssh el socket del servidor de Emacs para conectarme desde un cliente remoto, pero falló

    • Viéndolo en retrospectiva, el nombre emacsclient no fue bueno. Para alguien que conozca Emacs por primera vez en 2026, es fácil esperar que sincronice por red el estado de ejecución entre cliente y servidor, como un cliente REST
      Aquí, cliente y servidor se refieren a una estructura en la que el cliente envía comandos de control simples mediante un dominio local de Unix, es decir, un socket del sistema de archivos. Más adelante también se agregó soporte para sockets de red, pero lo que envía el cliente siguen siendo simples comandos de control
    • El reenvío de sockets no funciona, pero si usas X11 puedes abrir los frames de un Emacs remoto en tu servidor X local con ssh -X. Eso sí: en las compilaciones GTK no PGTK hay que tener cuidado, porque Emacs remoto puede fallar al cerrar un frame nuevo
    • Me pregunto si se verificó la causa por la que falló el reenvío del socket