Ghostel.el: emulador de terminal para Emacs basado en libghostty

• Ghostel es un emulador de terminal para Emacs que usa el mismo motor libghostty-vt que Ghostty; el módulo nativo en Zig se encarga del estado de la terminal, el renderizado y la E/S de PTY local, mientras que Elisp gestiona mapas de teclas, búferes, comandos y procesos remotos.
• Admite el protocolo de teclado y gráficos de Kitty, hipervínculos OSC 8, consultas de color OSC 4/10/11, salida sincronizada DEC 2026 y 5 modos de entrada; además, aplica automáticamente la integración con shell para bash, zsh, fish y nushell locales.
• Es compatible con Emacs 28.1 o superior y con macOS, Linux, FreeBSD y Windows nativo; en el primer uso puede descargar automáticamente módulos precompilados específicos de la plataforma, por lo que una instalación común no requiere la cadena de herramientas de Zig.
• En un benchmark que procesó una salida de 1 MB en un Apple M4 Max con Emacs 32.0.50, registró 75 MB/s en Ghostel para ASCII común, frente a 18 MB/s en vterm y 6,2 MB/s en eat; la PTY nativa absorbió una tarea cat de 10 MB en unos 110 ms.
• También ofrece terminales remotas TRAMP, protección de entrada de contraseñas, imágenes en línea de Kitty e integración con compilación, Eshell, Comint, Evil y métodos de entrada, aunque el manejo de destinos remotos e imágenes tiene restricciones de plataforma y protocolo.

---

Configuración e instalación

• Ghostel se inspiró en el diseño de dos capas de emacs-libvterm, pero usa el motor VT moderno de Ghostty en lugar de libvterm.
  • El módulo en Zig procesa el estado de la terminal, el renderizado, la codificación de teclas, la PTY local y la lectura en segundo plano.
  • Elisp se encarga de mapas de teclas, búferes, comandos, integración con proyectos y procesos remotos TRAMP.
• Los requisitos son Emacs 28.1 o superior con soporte para módulos dinámicos, y macOS, Linux, FreeBSD o Windows nativo.
  • Los binarios precompilados se ofrecen para aarch64-macos, x86_64-macos, x86_64-linux, aarch64-linux, x86_64-freebsd, x86_64-windows y aarch64-windows.
  • Para otras plataformas o compilación desde el código fuente se requiere Zig 0.15.2.
• Se puede instalar mediante MELPA, use-package :vc en Emacs 30 o superior, :load-path o require manual, y la terminal se abre con M-x ghostel.
• Si no hay un módulo nativo, sugiere descargarlo o compilarlo desde el código fuente según la configuración de ghostel-module-auto-install.
  • M-x ghostel-download-module descarga el binario mínimo compatible, y con un argumento de prefijo permite elegir la etiqueta de versión.
  • M-x ghostel-module-compile compila el módulo con zig build.
  • Si el directorio del paquete puede reinstalarse, se puede establecer ghostel-module-directory en una ubicación separada.
• La compilación desde el código fuente incluye el vendor/emacs-module.h generado, por lo que normalmente no requiere encabezados locales de Emacs; se puede cambiar la ubicación de los encabezados con EMACS_INCLUDE_DIR o EMACS_BIN_DIR.
  • El terminfo xterm-ghostty compilado se incluye en etc/terminfo/ y está en un formato portable entre BSD y ncurses.

Compatibilidad con Windows

• En Emacs nativo para Windows, las terminales locales se ejecutan con ConPTY, y la arquitectura del DLL del módulo debe coincidir con la arquitectura de Emacs, no con la de Windows.
• Junto con el módulo precompilado se descargan los archivos de soporte conpty.dll y OpenConsole.exe; si no están presentes, se usa como alternativa la API ConPTY integrada en Windows.
• Las compilaciones personalizadas especiales de Emacs, como las que usan CRT estático, se admiten solo bajo el criterio de mejor esfuerzo.
• Las terminales TRAMP en Windows solo admiten destinos remotos POSIX y la PTY existe en el host remoto; actualmente no se admite el cambio dinámico del tamaño de la ventana.

5 modos de entrada

• El modo semi-char predeterminado envía la mayoría de las teclas a la terminal, pero deja excepciones en Emacs como C-c, C-x, C-u, C-h, M-x, M-: y C-\.
  • Ofrece teclas para enviar interrupción, suspensión y EOF, pegado con corchetes, eliminación del scrollback y desplazamiento por prompts e hipervínculos.
• El modo char envía todas las teclas a la terminal, por lo que es adecuado para TUI que usan por sí mismas C-x, M-x y C-h; solo M-RET queda como tecla de escape.
• El modo Emacs sigue recibiendo la salida de la terminal mientras cambia el búfer a solo lectura, lo que permite navegación estándar de Emacs como isearch, occur, marcas y copiado.
  • La entrada normal no se transmite al shell, y solo el pegado intencional con C-y se envía como bracketed paste.
• El modo copy detiene las actualizaciones de la terminal para permitir seleccionar, navegar y copiar de forma estable.
  • En el texto copiado se eliminan los saltos de línea generados por el ajuste suave de línea.
  • Con el valor predeterminado ghostel-readonly-fast-exit=t, después de escribir un carácter o copiar se vuelve automáticamente a la sesión normal de terminal.
• El modo line no envía las teclas inmediatamente al shell, sino que permite editar una línea en el búfer de Emacs y la envía completa al presionar RET.
  • Aunque llegue salida asíncrona o un nuevo prompt, conserva como snapshot la entrada en curso y luego la vuelve a insertar.
  • Si hay OSC 133, usa los límites del prompt; si no, los detecta con ghostel-prompt-regexp.
  • Cuando se inicia una TUI de pantalla completa, cambia al modo semi-char y, al salir de la TUI, vuelve al modo line.
  • TAB usa la finalización de comint y, opcionalmente, programmable completion de bash.
• Al arrastrar con el mouse, hacer clic múltiple, activar la marca o salir de la posición de entrada en vivo con isearch o consult-line, por defecto cambia al modo copy para proteger la selección y la posición.
  • Si la TUI activó el seguimiento de mouse DEC, en modo de entrada transmite los eventos de mouse a ese programa.
  • Se puede modificar el comportamiento de cambio con ghostel-mouse-drag-input-mode, ghostel-mark-activation-input-mode y ghostel-point-leave-input-mode.

Funciones de terminal y renderizado

• Mediante libghostty-vt admite emulación VT completa, 256 colores y color de 24 bits, pantalla alternativa, varios estilos y colores de subrayado, negrita, cursiva, atenuado, tachado e inversión, además de cuatro formas de cursor y parpadeo.
• El TERM=xterm-ghostty predeterminado y el terminfo incluido anuncian a las aplicaciones funciones como salida sincronizada DEC 2026, teclado Kitty, true color, subrayado con color e informes de foco.
  • Con consultas OSC 4/10/11, las TUI pueden obtener la paleta y los colores de primer plano y fondo desde los colores de las faces de Emacs.
  • El portapapeles OSC 52 está soportado, pero viene desactivado por defecto, por lo que el terminfo incluido no anuncia la capacidad Ms.
• El scrollback predeterminado es de 5 MB, aproximadamente 5.000 líneas, y se materializa en un búfer de Emacs, por lo que puede buscarse con isearch y consult-line.
• Además de hipervínculos OSC 8, detecta URL HTTP y HTTPS comunes y rutas de archivo con formato /path/file.el:42, y las convierte en enlaces clicables.
• Admite el codificador de teclas de Ghostty, el protocolo de teclado de Kitty, eventos de mouse SGR, eventos de foco DEC 1004 y arrastrar y soltar rutas de archivo y texto.
• El renderizador omite las filas que no cambiaron, agrupa actualizaciones con temporizadores y ajusta de forma adaptativa la tasa de cuadros.
  • El eco de PTY que llega justo después de una pulsación de tecla evita el temporizador predeterminado de 33 ms y se renderiza de inmediato.
  • ghostel-sync-theme resincroniza la paleta con el tema de Emacs.
• Los 16 colores ANSI son faces de Emacs que heredan de term-color-*, y con ghostel-default se pueden configurar la fuente, el tamaño, el primer plano y el fondo exclusivos de la terminal.

Integración con shells e invocación de Emacs

• Para bash, zsh, fish y nushell, configura automáticamente seguimiento de directorio con OSC 7, navegación de prompt con OSC 133, seguimiento de título con OSC 2 y ghostel_cmd
  • La integración de shell propia de nushell ofrece OSC 7, 133 y 2, y ghostel.nu agrega ghostel_cmd y un wrapper de terminfo para SSH saliente
  • El bash 3.2 incluido en macOS ignora ENV, que se usa para la inyección automática, así que hay que usar un bash más reciente o cargar ghostel.bash manualmente
• ghostel_cmd, que invoca Elisp desde el shell, usa una extensión dedicada OSC 52;e y solo ejecuta funciones incluidas en la lista permitida ghostel-eval-cmds
  • Las funciones permitidas por defecto son find-file, find-file-other-window, dired, dired-other-window y message
• Los marcadores de Emacs guardan el directorio de trabajo de la terminal y el nombre del búfer
  • Si existe un búfer previo, lo reutiliza; si no, inicia un shell nuevo en el directorio guardado
  • No guarda el scrollback ni el contenido de la sesión

Contraseñas, portapapeles y notificaciones

• Cuando detecta prompts de contraseña como los de sudo, ssh, gpg o passwd, abre read-passwd y envía la respuesta directamente al PTY, por lo que la entrada no queda en view-lossage, el key ring reciente ni las macros de teclado
  • En local, verifica con tcgetattr que el modo canonical y el echo estén desactivados
  • Solo en shells remotos usa detección alternativa por expresiones regulares para reducir falsos positivos en TUI locales en raw mode
  • Después del envío, la cadena de la contraseña se procesa inmediatamente con clear-string
  • En ghostel-password-prompt-functions se pueden agregar fuentes como auth-source, KeePass o pass
• Si OSC 52 se activa explícitamente, los programas remotos pueden establecer el kill ring de Emacs y el portapapeles del sistema, y el pegado se transmite como bracketed paste
• Las notificaciones OSC 9 y OSC 777 se entregan a ghostel-notification-function
  • El handler predeterminado usa alert si está instalado; si no, lo sustituye por message en el área de echo
• El progreso OSC 9;4 entrega los estados remove, set, error, indeterminate y pause, junto con valores de 0 a 100
  • Ofrece un indicador de texto predeterminado y un indicador animado basado en spinner.el

Imágenes inline de Kitty

• Soporta la colocación directa y la colocación con placeholder Unicode U+10EEEE del Kitty graphics protocol, y renderiza imágenes de timg, kitty +kitten icat, yazi, entre otros
• Los PNG se procesan con el decodificador stb incluido, y los datos RGB, RGBA, Gray y GrayAlpha se convierten a PPM en el módulo nativo, por lo que no se necesita ImageMagick
• Responde a consultas de tamaño CSI 14, 16 y 18 t, y permite configurar la relación de píxeles físicos con ghostel-cell-pixel-scale
• El procesamiento de imágenes tiene las siguientes limitaciones
  • El canal alfa se elimina sin composición, por lo que no es adecuado para bordes semitransparentes
  • No soporta el recorte parcial source-rect de Kitty y devuelve un error explícito
  • Varias colocaciones virtuales en el mismo búfer comparten un único renderizado y prevalece la transmisión más reciente
  • Por defecto solo permite base64 inline; por seguridad, los medios basados en archivos, archivos temporales y memoria compartida deben activarse explícitamente
  • El límite predeterminado de almacenamiento de gráficos por terminal es de 320 MiB

TRAMP y terminfo remoto

• Si default-directory es una ruta TRAMP, ejecuta el shell en ese host POSIX, y con ghostel-tramp-shells se pueden especificar métodos TRAMP de la familia SSH y shells como docker
  • login-shell detecta el shell de inicio de sesión del usuario remoto con getent passwd
  • El seguimiento de directorio con OSC 7 conserva el método, el usuario y el prefijo multihop del TRAMP existente
  • Los destinos remotos Windows no son compatibles con esta ruta de shell POSIX y tty
• La integración de shell remota no se inyecta por defecto y ofrece dos métodos
  • Con ghostel-tramp-shell-integration=t, transfiere un script temporal y lo limpia al finalizar
  • En hosts permanentes, se pueden instalar directamente los scripts de etc/shell/ y, opcionalmente, terminfo
• Si el remoto no tiene el terminfo xterm-ghostty, la apertura de la terminal puede fallar, por lo que ghostel-ssh-install-terminfo se encarga de la instalación
  • La ejecución con TRAMP transfiere terminfo a un directorio temporal mediante la conexión existente y lo elimina al finalizar
  • Un ssh ejecutado desde Ghostel local normaliza el destino con ssh -G, consulta la caché y, si hace falta, ejecuta tic -x - con una conexión adicional
  • El hash del terminfo local se incluye en la clave de caché, por lo que se invalida automáticamente al actualizar libghostty, pero no detecta terminfo modificado por separado en el remoto
  • Omite la instalación en casos como ssh HOST cmd, invocaciones de opciones sin host o cuando no existe infocmp en local
• Si no se quiere modificar el host remoto, se puede desactivar la instalación automática e instalar terminfo manualmente; al cambiar ghostel-term a xterm-256color ya no se requiere la configuración relacionada, pero también desaparece la ruta rápida de salida sincronizada específica de Ghostty

Funciones de extensión para Emacs

• evil-ghostel sincroniza los estados insert y normal de Evil con el cursor de la terminal
  • Soporta movimiento, inserción, borrado, cambio, reemplazo, bracketed paste, readline undo y formas de cursor por estado
  • No afecta a vim, less ni htop en alternate screen
• ghostel-compile ejecuta comandos en un PTY real y ofrece encabezado, pie, resaltado de errores y navegación con next-error al estilo compilation-mode
  • Por defecto es navegación de solo lectura; si se pasa un argumento de prefijo, reenvía la entrada interactiva
  • Incluso durante la ejecución, se puede alternar entre entrada interactiva y navegación de compilación con C-c C-j y C-c C-e o C-c C-t
  • ghostel-compile-global-mode envía a Ghostel las llamadas a compile, recompile, project-compile y compilation-start
  • grep-mode conserva por defecto la implementación existente
• ghostel-eshell-visual-command-mode ejecuta comandos visuales (visual commands) de Eshell, como vim, htop y less, en un búfer dedicado de Ghostel en lugar de term-mode
• ghostel-comint-mode procesa el stream de salida de comint con libghostty-vt y ofrece true color, varios tipos de subrayado, enlaces OSC 8 y actualización de directorio OSC 7
  • Como no es una terminal completa, descarta el posicionamiento del cursor, alternate screen y el redibujado de pantalla completa, por lo que no es adecuado para htop o less
• ghostel-ime-mode borra el resultado de los métodos de entrada Elisp que insertan caracteres directamente en el búfer, como Hangul, y luego lo entrega al PTY en UTF-8
  • Durante la composición de Quail, retrasa el renderizado para evitar que el búfer sobrescriba la cadena de composición

Rendimiento

• En un Apple M4 Max con Emacs 32.0.50, al enviar 1 MB mediante un pipe de proceso real y mantener unas 1,000 líneas de scrollback, los resultados fueron los siguientes
  • ASCII simple: Ghostel 75 MB/s, Ghostel con detección de enlaces desactivada 76 MB/s, vterm 18 MB/s, eat 6.2 MB/s, term integrado 7.2 MB/s
  • Salida con muchas URL: Ghostel 36 MB/s, Ghostel con detección de enlaces desactivada 78 MB/s, vterm 15 MB/s, eat 4.5 MB/s, term 5.9 MB/s
• La detección de URL y rutas de archivo se ejecuta en un temporizador consolidado fuera de la ruta de redibujado, por lo que en salidas normales casi no tiene costo, pero en salidas con alta densidad de enlaces el throughput se reduce aproximadamente a la mitad
• Para una comparación justa, las cifras anteriores usaron la ruta de procesos de Emacs; el PTY nativo local predeterminado usa un hilo en segundo plano de Zig para leer la salida y es cerca de 2 veces más rápido en volcados grandes sostenidos
• La mediana de 5 ejecuciones haciendo cat a un archivo de 10 MB fue de unos 110 ms para Ghostel nativo, unos 220 ms para Ghostel con PTY de Emacs, unos 550 ms para vterm y unos 1.8 s para eat
  • vterm y eat ocupan sincrónicamente el hilo principal de Emacs durante la transferencia, mientras que el PTY nativo de Ghostel parsea en segundo plano y la UI sigue respondiendo
• M-x ghostel-debug-typing-latency mide el mínimo, la mediana, el p99 y el máximo de la latencia por tecla en PTY, renderizado y total

Diferencias con vterm y eat

• vterm usa un módulo nativo basado en C con libvterm, mientras que eat está escrito en Elisp puro, por lo que es portable sin compilar, pero tiene menor throughput
• Solo Ghostel admite en conjunto teclado y gráficos Kitty, cinco tipos de subrayado, OSC 8, OSC 4/10/11, notificaciones OSC 9 y 777, progreso OSC 9;4 y DEC 2026
  • eat admite imágenes Sixel, pero no imágenes Kitty; vterm no admite ninguno de los dos protocolos de imagen
• Ghostel y eat pasan eventos de mouse SGR a las TUI, pero vterm usa los clics para mover el punto de Emacs
• Ghostel y eat ofrecen modo line, mientras que vterm no
  • Ghostel ofrece tanto un modo copy en el que la salida se detiene como un modo Emacs en el que la salida continúa
  • vterm ofrece un modo copy estático, y el modo Emacs de solo lectura de eat sigue actualizándose
• Ghostel inyecta automáticamente la integración con el shell, pero vterm y eat requieren cargar scripts manualmente
• Ghostel detecta automáticamente los prompts de contraseña; eat solo ofrece comandos de envío manual, y vterm no intercepta la entrada por separado

Arquitectura interna

• En los buffers locales, por defecto Zig abre el PTY y crea el proceso hijo, y luego pasa la salida a libghostty-vt desde un hilo en segundo plano
  • Si se necesita un callback OSC o un redibujado, envía eventos Lisp al pipe de Emacs para que ghostel--events-filter los procese
  • La salida masiva no atraviesa el filtro de procesos de Emacs byte por byte
• Los buffers TRAMP reciben la salida mediante un proceso de Emacs y la pasan sincrónicamente al mismo modelo de terminal para conservar la creación remota y los manejadores de archivos
• Las pulsaciones de teclas pasan por el codificador de libghostty y se escriben de inmediato en el PTY; la salida pasa por el parser VT y la etapa de invalidación, y si es eco interactivo se procesa al instante; si no, Renderer.zig actualiza las filas modificadas desde un temporizador consolidado
• El renderizado de la terminal modifica el buffer de Emacs mediante reemplazo de filas, redibujado completo, cambios de tamaño y reflow, y agregado o eliminación del scrollback, por lo que el renderer es responsable de preservar el punto, la marca y la posición de la ventana
  • Elisp decide las políticas y la intención del usuario, como si moverse al viewport activo después de una entrada o mantener el estado de navegación en cada modo
  • Debe evitarse compensar los cambios del renderer con heurísticas de Elisp antes y después del redraw, porque así es difícil distinguir entre scroll del usuario, correcciones de redisplay, cambios de tamaño y reescrituras de contenido

Pruebas y licencia

• Las pruebas se basan en ERT; las pruebas de Elisp pueden ejecutarse sin el módulo Zig, y las pruebas con la etiqueta native requieren el módulo compilado
  • Se ofrecen targets de Makefile para pruebas unitarias de Zig, pruebas completas, pruebas de la extensión Evil y benchmarks rápidos
• Los bugs, solicitudes de funciones y pull requests se reciben en el repositorio de GitHub; para problemas de renderizado se requiere el comando de reproducción, la escape sequence, la versión de Emacs y la información de la plataforma
• Se pueden recopilar eventos de diagnóstico con M-x ghostel-debug-info
• Ghostel es software libre distribuido bajo GNU GPL v3 o posterior

[lum7671]

Parece que no funciona la entrada en coreano.
Aunque presione Ctrl-\ y parezca que el método de entrada cambia a coreano, en realidad solo parece permitir escribir en inglés.
Es una lástima.

[GN⁺]

Comentarios en Lobste.rs

• Creo que Ghostel es la respuesta definitiva para la emulación de terminal en Emacs. Para ventanas de terminal simples y de un solo uso, uso el Ghostty real; para trabajo en proyectos, uso el comando ghostel-project para usar el Ghostel vinculado a ese proyecto.
  Si ya existe una instancia para el proyecto, cambia directamente a esa instancia, así que moverse entre terminales es muy rápido.
• Me dieron ganas de volver a probar Doom Emacs y ver qué tan bien se integra. Una de las razones por las que lo abandoné la vez anterior fue la inestabilidad de la terminal de Emacs.
  • Yo también quiero probarlo. vterm tiene cosas que dejan que desear, pero poder usar los comandos del editor tal cual también en la terminal es realmente genial.
    Cuando se habla de emuladores de terminal en Emacs, suele aparecer la respuesta de que se puede usar dired en lugar de cd/mv/ls/cp/rm/mkdr/..., y compile en lugar de comandos de build, así que para qué hace falta. Pero aunque no esté haciendo tareas complejas, la terminal se siente más familiar y flexible.
    En particular, si hubiera una guía sobre cómo reducir la dependencia de la terminal en Doom Emacs, me gustaría seguirla. Siempre impresiona ver cómo se mueven rápidamente por los proyectos con configuraciones avanzadas.
  • La emulación de terminal en Emacs ya llegó a un nivel casi perfectamente usable, pero algunas generaciones de herramientas de terminal se rompen en entornos como vterm, y por problemas en el cálculo del tamaño de las filas, la pantalla de jj a veces queda completamente desalineada, lo cual es frustrante.
    Al final mantengo Ghostty abierto al lado, pero espero que algún día todas las herramientas funcionen correctamente dentro de Emacs.
• Parece que no tiene una función equivalente a eat-eshell, así que para mí es difícil elegirlo. Me interesa una emulación de terminal más rápida, pero uso mucho eshell.
  Con eat-eshell, los programas que necesitan emulación de terminal, como herramientas de build y la CLI de Podman, además de aplicaciones TUI, funcionan directamente dentro del búfer de eshell, así que para quienes usan eshell con frecuencia es una función que cambia las reglas del juego.
  • Me da curiosidad para qué se usa eshell por separado si también se puede hacer desde la terminal. Como no uso mucho eshell, a menudo siento que se me escapa su propósito.

[GN⁺]

Comentarios en Hacker News

• Soy el mantenedor principal de Ghostel. baokaola y yo íbamos a publicar un Show HN la próxima semana, pero alguien envió el enlace antes
  Para echarle un vistazo rápido, es más cómodo el repositorio de GitHub: https://github.com/dakra/ghostel
  Ghostel es un emulador de terminal para Emacs basado en libghostty-vt, y una comparación de funciones con vterm y eat puede verse en https://dakra.github.io/ghostel/#ghostel-vs-vterm. También hay material comparando rendimiento y precisión con imágenes: https://gist.github.com/dakra/4a0b76ebcf5d52338e134864378465...
  En lo personal, reemplacé no solo vterm/eat sino también terminales externas como kitty y Ghostty. Tratar el texto de la terminal como un buffer normal de Emacs abre muchísimas posibilidades de extensión que no existen en otras terminales. Incluso tareas simples como buscar en el scrollback y luego moverse y seleccionar un párrafo para copiarlo usando solo el teclado resultan mucho más naturales y rápidas para usuarios de Emacs
  Si alguien prueba Ghostel y aun así mantiene una terminal externa, me interesa saber si es por alguna función faltante o porque quiere ejecutar ciertos procesos fuera de Emacs. También estoy respondiendo activamente en GitHub, así que si hay problemas agradecería que abran un issue

  • Hasta ahora Ghostel me ha funcionado muy bien. Asigné f1 para alternar entre modo semicarácter y modo copia, y antes de ejecutar un comando pienso: “¿está bien si Emacs se cuelga o se cierra a la fuerza?”. Si no, lo ejecuto en una terminal normal
  • Cuando Magit y otros parsean diffs grandes, todo Emacs puede quedarse congelado, así que al final sigo manteniendo una terminal aparte
  • En eshell se puede manipular texto igual que en cualquier otro buffer de Emacs. Si conectas a una tecla una función para poner comillas alrededor de una palabra, en eshell funciona tal cual, y además puedes usar evil-mode, xah-fly-keys e ispell, lo cual es una ventaja decisiva
    Ghostel no está integrado al mismo nivel, y extensiones como evil-ghostel-mode también tienen limitaciones. Me pregunto si hay planes para mejorar eso o si es una restricción estructural que hay que aceptar, y sería excelente que apareciera una función equivalente a eat-eshell-mode
  • Estaría bien tener el modo Quick-select basado en patrones de WezTerm. Desde que conocí esa función, casi no me dan ganas de usar otras terminales
  • Lo he estado usando desde hace un tiempo en Doom Emacs y va muy bien. Me intriga por qué programas que desplazan la pantalla, como Lazygit o Reasonix, funcionan en Ghostel cuando fallan en otros emuladores. Quisiera saber si hay algún manejo especial en la implementación o en la librería

• El título debería incluir Emacs. Un emulador de terminal general y un emulador de terminal para Emacs no son lo mismo

  • Si no conoces el proyecto, es más útil enlazar a https://github.com/dakra/ghostel que a la documentación
  • .el es la extensión de archivo de Emacs Lisp

• Hace poco cambié de vterm a Ghostel y en general es mucho mejor. Es notablemente rápido, hasta el punto de que apps TUI vistosas que refrescan toda la terminal en cada frame funcionan correctamente, el manejo de entrada es más estable y la API de ELisp también está muy bien
  Aun así, a veces no logra limpiar bien la terminal y quedan residuos arriba del prompt actual, o se queda completamente colgado y hay que cerrar el buffer y reiniciarlo. Para usarlo a diario ya alcanza y se ve prometedor, pero para convertirse en un producto maduro todavía necesita correcciones de bugs y trabajo de pulido

  • Soy co-mantenedor de Ghostel. Aunque no haya pasos exactos para reproducirlo, si llegas a tener información accionable te agradecería que abras un issue o me la hagas llegar de otra manera
    Lo de los residuos en la parte superior de la pantalla podría ser https://github.com/dakra/ghostel/issues/495, que ya fue corregido en la versión más reciente, aunque también podría tratarse de otro bug. La parte difícil está en duplicar los datos internos de libghostty-vt en un buffer de Emacs y reemplazar solo las partes necesarias. Hay pruebas basadas en propiedades para validar esto ampliamente, pero a veces algo se escapa
    En la release más reciente también mejoró el manejo del ciclo de vida, así que algunos problemas podrían haberse resuelto junto con eso. Como todavía está en una etapa temprana, la idea es irlo puliendo poco a poco

• Me gustaría ver ejemplos reales de uso eficiente de los distintos modos de entrada. La terminal quiere todas las pulsaciones, y el editor también quiere usar teclas para sus propios comandos, así que una terminal integrada en el editor necesariamente necesita modos para cambiar la propiedad del teclado
  :term de Neovim solo tiene dos modos, y si no entiendes por qué Ghostel tiene cinco, es fácil pensar por error que está sobreingenierizado. En realidad es más complejo porque resuelve más problemas, y los modos adicionales son herramientas opcionales para tareas que nvim no cubre. Aun así, no queda del todo claro cómo aprovechar esa ventaja de forma eficiente en la práctica

• Tenía dificultades usando vterm, probé Ghostel y me pareció excelente; podría terminar siendo mi terminal principal

  • Pasé de vterm a eat y luego a Ghostel, y al menos hasta ahora creo que Ghostel es el mejor

• Llevo más de un mes usándolo, y me gusta especialmente la función de hacer clic en referencias de código para abrirlas directamente en un buffer de Emacs que aparece en el resumen de Codex

  • No solo con el mouse: también puedes moverte rápido entre los hipervínculos mostrados recientemente con ghostel-previous-hyperlink o ghostel-next-hyperlink
    También se instala un mapa de repeat-mode, así que si en la salida hay tres URL o enlaces a archivos, suelo usar C-c C-p p p RET para abrir el primer enlace

• La integración entre Ghostel y Claude Code hizo que aumentara mucho mi uso de Emacs, y ahora Emacs es el hub central de mi trabajo

  • Me pregunto si por integración aquí quieres decir que el modelo manipula Emacs directamente a través de un servidor

• Si tenía unas 10 terminales abiertas en varias ventanas, Ghostty se me caía casi todas las noches. Por eso no pude usar Ghostty como se debe, ni tampoco quisiera integrarlo dentro de una herramienta que uso todos los días

  • Estoy usando Ghostty 1.1.3 en Gentoo Linux, y ahora mismo tengo alrededor de 20 pestañas por unas 12 ventanas, con más de 100 instancias de shell ejecutándose
    Incluso ejecuté ls -lR en la mayor cantidad posible de shells sobre un sistema de archivos con varios millones de archivos, y no tuve problemas ni caídas. Llevo meses usándolo intensamente todos los días durante toda la jornada y no he visto ni un crash ni un comportamiento sospechoso
    Parece mucho más probable que haya sido un bug de cierta versión de Ghostty o alguna interacción rara con otro software, como el driver de la GPU. Aquí uso una GPU de NVIDIA

• Dice que “los módulos nativos son binarios precompilados y se descargan automáticamente en el primer uso”, y me pregunto por qué no se incluyen en el paquete de distribución

  • MELPA y ELPA no tienen forma de adjuntar archivos por plataforma y distribuyen todo como checkouts de Git. Para incluirlos en la distribución habría que meter en el repositorio los binarios del módulo para todas las plataformas, y juntos pasan de 10 MB
    jinx, un paquete popular de Emacs que usa módulos nativos, también ofrece un método como vterm: compilar en el primer uso. Por eso, para ofrecer una instalación amigable en un paquete de Emacs, en la práctica no queda otra que descargar o compilar en la primera ejecución