Ghostel.el - emulador de terminal para Emacs baseado em libghostty

 (dakra.github.io)
1 pontos por GN⁺ 4 시간 전 | 3 comentários | Compartilhar no WhatsApp
  • Ghostel é um emulador de terminal para Emacs que usa o mesmo motor libghostty-vt do Ghostty, com um módulo nativo em Zig cuidando do estado do terminal, renderização e E/S de PTY local, enquanto o Elisp gerencia keymaps, buffers, comandos e processos remotos
  • Suporta os protocolos de teclado e gráficos do Kitty, hyperlinks OSC 8, consultas de cor OSC 4/10/11, saída sincronizada DEC 2026 e 5 modos de entrada, além de aplicar automaticamente integração de shell para bash, zsh, fish e nushell locais
  • Suporta Emacs 28.1 ou superior e macOS, Linux, FreeBSD e Windows nativo, podendo baixar automaticamente módulos pré-compilados específicos por plataforma no primeiro uso, então uma instalação comum não exige toolchain Zig
  • Em benchmark no Apple M4 Max com Emacs 32.0.50 processando saída de 1 MB, registrou Ghostel 75 MB/s, vterm 18 MB/s e eat 6.2 MB/s em ASCII comum, enquanto o PTY nativo absorveu uma tarefa cat de 10 MB em cerca de 110 ms
  • Também oferece terminal remoto via TRAMP, proteção para entrada de senha, imagens inline do Kitty e integração com compile, Eshell, Comint, Evil e métodos de entrada, mas há restrições de plataforma e protocolo para destinos remotos e processamento de imagens

Arquitetura e instalação

  • O Ghostel foi inspirado no design em duas camadas do emacs-libvterm, mas usa o moderno motor VT do Ghostty em vez do libvterm
    • O módulo em Zig cuida do estado do terminal, renderização, codificação de teclas, PTY local e leitura em segundo plano
    • O Elisp fica responsável por keymaps, buffers, comandos, integração com projetos e processos remotos via TRAMP
  • Os requisitos são Emacs 28.1 ou superior com suporte a módulos dinâmicos e macOS, Linux, FreeBSD ou Windows nativo
    • Binários pré-compilados são fornecidos para aarch64-macos, x86_64-macos, x86_64-linux, aarch64-linux, x86_64-freebsd, x86_64-windows e aarch64-windows
    • Outras plataformas ou compilação a partir do código-fonte exigem Zig 0.15.2
  • Pode ser instalado via MELPA, use-package :vc no Emacs 30 ou superior, :load-path ou require manual, e o terminal é aberto com M-x ghostel
  • Se o módulo nativo não estiver presente, a configuração ghostel-module-auto-install sugere baixar ou compilar a partir do código-fonte
    • M-x ghostel-download-module baixa o binário mínimo suportado e, com argumento de prefixo, permite escolher uma tag de release
    • M-x ghostel-module-compile compila o módulo com zig build
    • Se o diretório do pacote puder ser reinstalado, ghostel-module-directory pode apontar para outro local
  • A compilação a partir do código-fonte inclui o vendor/emacs-module.h gerado, então normalmente não são necessários headers locais do Emacs; EMACS_INCLUDE_DIR ou EMACS_BIN_DIR podem ser usados para mudar a localização dos headers
    • O terminfo compilado xterm-ghostty está incluído em etc/terminfo/ e usa um formato portátil entre BSD e ncurses

Suporte ao Windows

  • No Emacs nativo para Windows, executa terminais locais via ConPTY, e a arquitetura da DLL do módulo deve corresponder à arquitetura do Emacs, não à do Windows
  • Junto com os módulos pré-compilados, baixa os arquivos de suporte conpty.dll e OpenConsole.exe; se eles não existirem, usa como alternativa a API ConPTY nativa do Windows
  • Builds personalizados especiais do Emacs, como com CRT estático, têm suporte apenas em regime de melhor esforço
  • O terminal TRAMP no Windows suporta apenas destinos remotos POSIX, o PTY existe no host remoto e o redimensionamento dinâmico da janela ainda não é suportado

5 modos de entrada

  • O modo padrão semi-char envia a maioria das teclas ao terminal, mas mantém exceções como C-c, C-x, C-u, C-h, M-x, M-: e C-\\ no Emacs
    • Ele fornece teclas para enviar interrupção, suspensão e EOF, bracketed paste, limpar scrollback e navegar por prompts e hyperlinks
  • O modo char envia todas as teclas ao terminal, sendo adequado para TUIs que usam C-x, M-x e C-h por conta própria, deixando apenas M-RET como tecla de escape
  • O modo Emacs continua recebendo a saída do terminal, mas torna o buffer somente leitura para permitir navegação padrão do Emacs, como isearch, occur, marcação e cópia
    • A entrada normal não é enviada ao shell, e apenas colagens intencionais com C-y são transmitidas como bracketed paste
  • O modo copy pausa as atualizações do terminal para permitir seleção, navegação e cópia estáveis
    • No texto copiado, remove quebras de linha geradas por soft wrap
    • Com o padrão ghostel-readonly-fast-exit=t, entrada de caracteres ou cópia fazem o retorno automático à sessão normal do terminal
  • O modo line não envia teclas imediatamente ao shell; em vez disso, edita uma linha no buffer do Emacs e a transmite de uma vez com RET
    • Mesmo que chegue saída assíncrona ou um novo prompt, preserva um snapshot da entrada em edição e a reinsere depois
    • Se houver OSC 133, usa os limites de prompt; caso contrário, encontra esses limites com ghostel-prompt-regexp
    • Quando um TUI em tela cheia é iniciado, muda para o modo semi-char e retorna ao modo line após o encerramento do TUI
    • TAB usa conclusão do comint e, opcionalmente, programmable completion do bash
  • Arrasto do mouse, múltiplos cliques, ativação de marca e saída da posição de entrada ativa com isearch ou consult-line mudam por padrão para o modo copy para proteger a seleção e a posição
    • Se um TUI tiver ativado rastreamento de mouse DEC, os eventos de mouse são enviados a esse programa no modo de entrada
    • O comportamento de troca pode ser alterado com ghostel-mouse-drag-input-mode, ghostel-mark-activation-input-mode e ghostel-point-leave-input-mode

Recursos de terminal e renderização

  • Por meio do libghostty-vt, oferece emulação VT completa, 256 cores e cores de 24 bits, alternate screen, vários estilos e cores de sublinhado, negrito, itálico, esmaecido, tachado, reverso, além de quatro formatos de cursor e piscagem
  • O TERM=xterm-ghostty padrão e o terminfo incluído informam aos aplicativos recursos como saída sincronizada DEC 2026, teclado Kitty, true color, sublinhado colorido e reporte de foco
    • Com consultas OSC 4/10/11, um TUI pode obter a paleta e as cores de primeiro plano e fundo a partir das faces do Emacs
    • A área de transferência via OSC 52 é suportada, mas vem desativada por padrão, então o terminfo incluído não anuncia o recurso Ms
  • O scrollback padrão é de 5 MB, cerca de 5.000 linhas, e é materializado em um buffer do Emacs, podendo ser pesquisado com isearch e consult-line
  • Além de hyperlinks OSC 8, detecta URLs HTTP e HTTPS comuns e caminhos de arquivo no formato /path/file.el:42, transformando-os em links clicáveis
  • Suporta o codificador de teclas do Ghostty, o protocolo de teclado do Kitty, eventos de mouse SGR, eventos de foco DEC 1004 e arrastar e soltar de caminhos de arquivos e texto
  • O renderizador pula linhas inalteradas, agrupa atualizações com timer e ajusta a taxa de quadros de forma adaptativa
    • O eco do PTY que chega logo após pressionar uma tecla ignora o timer padrão de 33 ms e é renderizado imediatamente
    • ghostel-sync-theme resincroniza a paleta para combinar com o tema do Emacs
  • As 16 cores ANSI são faces do Emacs que herdam de term-color-*, e ghostel-default permite definir fonte, tamanho, primeiro plano e fundo específicos para o terminal

Integração com shell e chamada do Emacs

  • Em bash, zsh, fish e nushell, configura automaticamente rastreamento de diretório via OSC 7, movimentação de prompt via OSC 133, rastreamento de título via OSC 2 e ghostel_cmd
    • A própria integração de shell do nushell fornece OSC 7·133·2, e ghostel.nu adiciona ghostel_cmd e um wrapper de terminfo para SSH de saída
    • O bash 3.2 embutido no macOS ignora ENV, usado para injeção automática, então é preciso usar um bash mais recente ou carregar ghostel.bash manualmente
  • ghostel_cmd, que chama Elisp a partir do shell, usa uma extensão dedicada OSC 52;e e executa apenas funções presentes na lista de permissões ghostel-eval-cmds
    • As funções permitidas por padrão são find-file, find-file-other-window, dired, dired-other-window e message
  • Os bookmarks do Emacs salvam o diretório de trabalho do terminal e o nome do buffer
    • Se já houver um buffer existente, ele será reutilizado; caso contrário, um novo shell será iniciado no diretório salvo
    • O scrollback e o conteúdo da sessão não são salvos

Senhas, área de transferência e notificações

  • Ao detectar prompts de senha de sudo, ssh, gpg, passwd etc., abre read-passwd e envia a resposta diretamente ao PTY, de modo que a entrada não fica em view-lossage, no histórico recente de teclas nem em macros de teclado
    • Localmente, verifica o modo canonical e a desativação de echo com tcgetattr
    • Em shells remotos, usa detecção alternativa por regex apenas no remoto para reduzir falsos positivos em TUIs locais em modo raw
    • Após o envio, a string da senha é imediatamente limpa com clear-string
    • É possível adicionar fontes como auth-source, KeePass e pass em ghostel-password-prompt-functions
  • Se o OSC 52 for ativado explicitamente, programas remotos poderão definir o kill ring do Emacs e a área de transferência do sistema, e a colagem será enviada como bracketed paste
  • Notificações via OSC 9 e OSC 777 são encaminhadas para ghostel-notification-function
    • O handler padrão usa alert se estiver instalado; caso contrário, usa message na área de echo
  • O progresso via OSC 9;4 transmite estados remove, set, error, indeterminate, pause e valores de 0 a 100
    • Há um indicador de texto padrão e um indicador animado baseado em spinner.el

Imagens inline do Kitty

  • Suporta posicionamento direto e posicionamento por placeholder Unicode U+10EEEE do protocolo gráfico do Kitty, renderizando imagens de timg, kitty +kitten icat, yazi etc.
  • PNG é processado com o decodificador stb embutido, e dados RGB·RGBA·Gray·GrayAlpha são convertidos para PPM no módulo nativo, então não é preciso ImageMagick
  • Responde a consultas de tamanho CSI 14·16·18 t, e a proporção de pixels físicos pode ser definida com ghostel-cell-pixel-scale
  • O processamento de imagens tem as seguintes limitações
    • O canal alfa não é composto, e sim removido, portanto não é adequado para bordas semitransparentes
    • O recorte parcial source-rect do Kitty não é suportado e retorna erro explícito
    • Vários posicionamentos virtuais no mesmo buffer compartilham uma única renderização, e o envio mais recente tem prioridade
    • Por padrão, apenas base64 inline é permitido; arquivos, arquivos temporários e memória compartilhada precisam ser ativados explicitamente por segurança
    • O limite padrão de armazenamento gráfico por terminal é 320MiB

TRAMP e terminfo remoto

  • Se default-directory for um caminho TRAMP, o shell será executado no host POSIX correspondente, e métodos TRAMP da família SSH e shells como docker podem ser definidos em ghostel-tramp-shells
    • login-shell detecta o shell de login do usuário remoto com getent passwd
    • O rastreamento de diretório via OSC 7 preserva o método, usuário e prefixos multi-hop do TRAMP existente
    • Alvos remotos Windows não são suportados nesse caminho de shell·tty POSIX
  • A integração de shell remoto não é injetada por padrão, e há duas abordagens disponíveis
    • Com ghostel-tramp-shell-integration=t, um script temporário é enviado e limpo ao encerrar
    • Em hosts permanentes, é possível instalar diretamente os scripts de etc/shell/ e, opcionalmente, o terminfo
  • Se o remoto não tiver o terminfo xterm-ghostty, a abertura do terminal pode falhar, e ghostel-ssh-install-terminfo cuida da instalação
    • A execução via TRAMP envia o terminfo para um diretório temporário pela conexão existente e o remove ao encerrar
    • O ssh executado a partir do Ghostel local normaliza o alvo com ssh -G, consulta o cache e, se necessário, executa tic -x - com uma conexão adicional única
    • O hash do terminfo local é incluído na chave de cache, então é invalidado automaticamente quando o libghostty é atualizado, mas mudanças feitas separadamente no terminfo remoto não são detectadas
    • Em ssh HOST cmd, chamadas de opção sem host e casos em que não há infocmp local, a instalação é ignorada
  • Se você não quiser modificar o host remoto, pode desativar a instalação automática e instalar o terminfo manualmente; se trocar ghostel-term para xterm-256color, essa configuração deixa de ser necessária, mas o caminho rápido de saída sincronizada específico do Ghostty também é perdido

Recursos de extensão do Emacs

  • evil-ghostel sincroniza os estados insert·normal do Evil com o cursor do terminal
    • Suporta mover, inserir, apagar, alterar, substituir, bracketed paste, undo do readline e formatos de cursor por estado
    • Não afeta vim, less ou htop em alternate screen
  • ghostel-compile executa comandos em um PTY real enquanto fornece cabeçalho·rodapé no estilo compilation-mode, destaque de erros e navegação com next-error
    • O padrão é navegação somente leitura, mas com argumento de prefixo também encaminha entrada interativa
    • Mesmo durante a execução, é possível alternar entre entrada interativa e navegação de compilação com C-c C-j e C-c C-e ou C-c C-t
    • ghostel-compile-global-mode envia chamadas de compile, recompile, project-compile e compilation-start para o Ghostel
    • grep-mode mantém a implementação existente por padrão
  • ghostel-eshell-visual-command-mode executa comandos visuais do Eshell, como vim, htop e less, em um buffer Ghostel dedicado em vez de term-mode
  • ghostel-comint-mode processa fluxos de saída do comint com libghostty-vt, oferecendo true color, vários tipos de sublinhado, links OSC 8 e atualização de diretório via OSC 7
    • Não é um terminal completo, então descarta posicionamento de cursor, alternate screen e redesenho de tela inteira, não sendo adequado para htop ou less
  • ghostel-ime-mode apaga o resultado de métodos de entrada Elisp que inserem caracteres diretamente no buffer, como Hangul, e o envia ao PTY em UTF-8
    • Durante a composição do Quail, adia a renderização para evitar que o buffer sobrescreva a string em composição

Desempenho

  • Em um Apple M4 Max com Emacs 32.0.50, ao enviar 1 MB por um pipe de processo real e manter cerca de 1.000 linhas de scrollback, os resultados foram os seguintes
    • ASCII comum: Ghostel 75MB/s, Ghostel com detecção de links desativada 76MB/s, vterm 18MB/s, eat 6,2MB/s, term embutido 7,2MB/s
    • Saída com muitas URLs: Ghostel 36MB/s, Ghostel com detecção de links desativada 78MB/s, vterm 15MB/s, eat 4,5MB/s, term 5,9MB/s
  • A detecção de URL e caminho de arquivo roda em um timer consolidado fora do caminho de redesenho, então quase não tem custo em saídas normais, mas em saídas densas em links a taxa de processamento cai cerca de pela metade
  • Para uma comparação justa, os números acima usam o caminho de processo do Emacs; o PTY nativo local padrão é cerca de 2x mais rápido em dumps grandes e contínuos porque uma thread em segundo plano do Zig lê a saída
  • A mediana de 5 execuções de cat em um arquivo de 10 MB foi de cerca de 110 ms no Ghostel nativo, cerca de 220 ms no Ghostel via Emacs PTY, cerca de 550 ms no vterm e cerca de 1,8 s no eat
    • vterm e eat ocupam a thread principal do Emacs de forma síncrona durante a transferência, enquanto o PTY nativo do Ghostel faz o parsing em segundo plano e a UI continua responsiva
  • M-x ghostel-debug-typing-latency mede mínimo, mediana, p99 e máximo da latência por tecla de PTY, renderização e total

Diferenças em relação a vterm e eat

  • vterm usa um módulo nativo em C baseado em libvterm, e eat é escrito em Elisp puro, o que o torna portátil sem build, mas com menor taxa de processamento
  • Só o Ghostel oferece suporte a teclado e gráficos do Kitty, cinco tipos de sublinhado, OSC 8, OSC 4/10/11, notificações OSC 9 e 777, além de progresso OSC 9;4 e DEC 2026
    • eat suporta imagens Sixel, mas não imagens Kitty, e vterm não suporta nenhum dos dois protocolos de imagem
  • Ghostel e eat repassam eventos de mouse SGR para a TUI, enquanto o vterm usa cliques para mover o ponto no Emacs
  • Ghostel e eat oferecem modo de linha, enquanto o vterm não
    • Ghostel oferece tanto um modo de cópia em que a saída para quanto um modo Emacs em que a saída continua
    • vterm oferece um modo de cópia estático, e o modo Emacs somente leitura do eat continua sendo atualizado
  • Ghostel injeta automaticamente a integração com shell, enquanto vterm e eat exigem carregar scripts manualmente
  • Prompts de senha são detectados automaticamente pelo Ghostel; eat oferece apenas um comando de envio manual, e vterm não intercepta a entrada separadamente

Arquitetura interna

  • Em buffers locais, por padrão o Zig abre o PTY e cria o processo filho, depois envia a saída para libghostty-vt em uma thread em segundo plano
    • Se for necessário um callback OSC ou redesenho, eventos Lisp são enviados pelo pipe do Emacs e processados por ghostel--events-filter
    • Grandes volumes de saída não passam byte a byte pelo filtro de processo do Emacs
  • Em buffers TRAMP, o processo do Emacs recebe a saída e a entrega de forma síncrona ao mesmo modelo de terminal para preservar a criação remota e os file handlers
  • A entrada de teclado passa pelo encoder do libghostty e é escrita imediatamente no PTY, enquanto a saída passa pelo parser VT e pela etapa de invalidação; se for eco interativo, atualiza na hora, caso contrário Renderer.zig atualiza as linhas alteradas em um timer consolidado
  • A renderização do terminal modifica o buffer do Emacs por substituição de linhas, redesenho completo, redimensionamento com reflow e adição ou remoção de scrollback, então o renderer é responsável por preservar ponto, marca e posição da janela
    • O Elisp decide políticas e intenção do usuário, como ir para o viewport ativo após entrada ou manter o estado de navegação em cada modo
    • Tentar compensar mudanças do renderer com heurísticas do Elisp antes ou depois do redraw deve ser evitado, porque dificulta distinguir entre rolagem do usuário, compensação de redisplay, redimensionamento e reescrita de conteúdo

Testes e licença

  • Os testes são baseados em ERT, e os testes em Elisp podem rodar sem o módulo Zig; os testes com a tag native exigem o módulo compilado
    • Há alvos de Makefile para testes unitários em Zig, suíte completa de testes, testes da extensão Evil e benchmarks rápidos
  • Bugs, pedidos de funcionalidade e pull requests são recebidos no repositório no GitHub; para problemas de renderização, são necessários comando de reprodução, escape sequence, versão do Emacs e informações da plataforma
  • M-x ghostel-debug-info pode ser usado para coletar eventos de diagnóstico
  • Ghostel é software livre distribuído sob a GNU GPL v3 ou posterior

Leituras relacionadas

3 comentários

 
lum7671 1 시간 전

Parece que a entrada em coreano não funciona.
Mesmo usando Ctrl-\, o método de entrada parece mudar para coreano, mas, na prática, parece que só dá para digitar em inglês.
É uma pena.
 
GN⁺ 2 시간 전
Opiniões no Lobste.rs
  • Acho que o Ghostel é a resposta definitiva para emulação de terminal no Emacs. Para janelas de terminal simples e pontuais, uso o Ghostty de verdade; para trabalho em projetos, uso um Ghostel vinculado ao projeto com o comando ghostel-project
    Se já existir uma instância para o projeto, ele muda direto para ela, então alternar entre terminais fica muito rápido
  • Fiquei com vontade de dar outra chance ao Doom Emacs e ver como a integração está boa. Um dos motivos de eu ter desistido da última vez foi a instabilidade dos terminais no Emacs
    • Eu também quero testar. O vterm tem alguns pontos fracos, mas é muito bom poder usar os comandos do editor do mesmo jeito dentro do terminal
      Quando se fala de emuladores de terminal no Emacs, a resposta comum é que não precisa disso porque dá para usar dired em vez de cd/mv/ls/cp/rm/mkdr/... e compile no lugar dos comandos de build. Mas, mesmo sem fazer tarefas complexas, o terminal ainda parece mais familiar e flexível
      Especialmente no Doom Emacs, eu gostaria de seguir algum guia que mostrasse como reduzir a dependência do terminal. Sempre acho impressionante ver alguém navegando rápido por projetos com configurações avançadas
    • A emulação de terminal no Emacs chegou a um nível quase perfeitamente utilizável, mas algumas gerações de ferramentas de terminal ainda quebram em ambientes como o vterm, e problemas no cálculo da altura das linhas às vezes bagunçam completamente a tela do jj, o que é bem frustrante
      No fim, acabo deixando o Ghostty aberto ao lado, mas espero que um dia todas as ferramentas funcionem direito dentro do Emacs
  • Não parece haver um recurso equivalente ao eat-eshell, então para mim fica difícil escolher. Tenho interesse em uma emulação de terminal mais rápida, mas uso bastante o eshell
    Com eat-eshell, programas que precisam de emulação de terminal, como ferramentas de build e a CLI do Podman, além de aplicações TUI, funcionam direto no buffer do eshell, então isso muda o jogo para quem usa eshell com frequência
    • Fico curioso sobre para que as pessoas usam o eshell separadamente, já que isso também pode ser feito no terminal. Não uso muito eshell, então muitas vezes sinto que estou deixando passar o propósito dele
 
GN⁺ 4 시간 전
Comentários do Hacker News

  • Sou o mantenedor principal do Ghostel. Eu e o baokaola íamos publicar um Show HN na semana que vem, mas alguém enviou o link antes
    Para dar uma olhada rápida, o repositório no GitHub é mais prático: https://github.com/dakra/ghostel
    O Ghostel é um emulador de terminal para Emacs baseado em libghostty-vt, e uma comparação de recursos com vterm e eat pode ser vista em https://dakra.github.io/ghostel/#ghostel-vs-vterm. Também há materiais comparando desempenho e precisão com imagens: https://gist.github.com/dakra/4a0b76ebcf5d52338e134864378465...
    Pessoalmente, ele substituiu para mim não só vterm/eat, mas também terminais externos como kitty e Ghostty. Quando você trata o texto do terminal como um buffer comum do Emacs, surgem inúmeras possibilidades de extensão que outros terminais não têm. Até tarefas simples, como pesquisar no scrollback e depois navegar e copiar um parágrafo só com o teclado, ficam muito mais naturais e rápidas para usuários de Emacs
    Se alguém usar o Ghostel e ainda assim mantiver um terminal externo, tenho curiosidade se isso é por falta de algum recurso ou porque prefere executar certos processos fora do Emacs. Também estou respondendo ativamente no GitHub, então, se houver problemas, por favor abra uma issue

    • Até agora o Ghostel está funcionando muito bem. Atribuí f1 para alternar entre modo semi-char e modo de cópia, e antes de executar um comando penso: “Tudo bem se o Emacs travar ou for encerrado à força?”. Se a resposta for não, executo em um terminal comum
    • Quando o Magit e afins vão analisar um diff grande, o Emacs inteiro pode travar, então acabo mantendo um terminal separado mesmo assim
    • No eshell dá para manipular texto exatamente como em qualquer outro buffer do Emacs. Se você ligar uma função para colocar palavras entre aspas a uma tecla, ela funciona no eshell do mesmo jeito, e também dá para usar evil-mode, xah-fly-keys e ispell, o que é uma vantagem decisiva
      O Ghostel não é integrado nesse mesmo nível, e extensões como evil-ghostel-mode também têm limitações. Queria saber se há planos para melhorar isso ou se é uma limitação estrutural inevitável, e seria excelente ter algo equivalente ao eat-eshell-mode
    • Seria ótimo ter o modo Quick-select baseado em padrões do WezTerm. Desde que conheci esse recurso, quase não tenho vontade de usar outro terminal
    • Estou usando no Doom Emacs há algum tempo e tem funcionado bem. Tenho curiosidade por que programas que rolam a tela, como Lazygit e Reasonix, falham em outros emuladores mas funcionam no Ghostel. Queria saber se existe algum tratamento especial na implementação ou na biblioteca

  • O título precisa incluir Emacs. Um emulador de terminal genérico e um emulador de terminal para Emacs não são a mesma coisa

    • Para quem não conhece o projeto, é mais útil apontar para https://github.com/dakra/ghostel do que para a documentação
    • .el é a extensão de arquivos Emacs Lisp

  • Troquei recentemente do vterm para o Ghostel, e no geral ele é muito melhor. É visivelmente mais rápido, a ponto de rodar corretamente até apps TUI chamativos que redesenham o terminal inteiro a cada frame, o tratamento de entrada é mais estável e a API em ELisp também é boa
    Ainda assim, às vezes ele não limpa o terminal corretamente e ficam resíduos acima do prompt atual, ou trava completamente e eu preciso fechar o buffer e reiniciar. Para uso diário já é suficiente e o futuro parece promissor, mas para virar um produto maduro ainda precisa de correções de bugs e acabamento

    • Sou co-mantenedor do Ghostel. Mesmo sem um modo de reprodução, se surgir qualquer informação útil, por favor registre uma issue ou envie de alguma outra forma
      Esse problema de resíduos na parte de cima da tela pode ser https://github.com/dakra/ghostel/issues/495, que foi corrigido na versão mais recente, embora também possa ser outro bug. A parte difícil é espelhar os dados internos do libghostty-vt em um buffer do Emacs e substituir apenas o que for necessário. Há testes baseados em propriedades para validar isso amplamente, mas às vezes algum problema escapa
      Na release mais recente, o tratamento do ciclo de vida também foi melhorado, então alguns problemas podem ter sido resolvidos junto. Como ainda está em estágio inicial, a ideia é ir refinando aos poucos

  • Seria bom ver exemplos reais de uso eficiente dos diferentes modos de entrada. O terminal quer receber todas as teclas, enquanto o editor também quer usar teclas para seus próprios comandos, então um terminal embutido no editor inevitavelmente precisa de modos para alternar a posse do teclado
    O :term do Neovim tem só dois modos, e sem entender por que o Ghostel tem cinco, é fácil achar que houve exagero no design. Na prática, ele é mais complexo porque resolve mais problemas, e os modos extras são ferramentas opcionais para tarefas que o nvim não cobre. Ainda assim, não está totalmente claro como aproveitar essa vantagem de forma eficiente no uso real

  • Eu estava tendo dificuldades com o vterm, testei o Ghostel e ele é excelente, então pode acabar virando meu terminal principal

    • Passei de vterm para eat e depois para Ghostel, e pelo menos até agora o Ghostel é o melhor

  • Estou usando há mais de um mês, e gosto especialmente do recurso citado no resumo do Codex de clicar em referências de código e abri-las diretamente em buffers do Emacs

    • Além do mouse, também dá para navegar rapidamente entre os hyperlinks exibidos mais recentemente com ghostel-previous-hyperlink ou ghostel-next-hyperlink
      Um mapa de repeat-mode também é instalado, então se houver três URLs ou links de arquivos na saída, muitas vezes dá para abrir o primeiro só com C-c C-p p p RET

  • A integração entre Ghostel e Claude Code aumentou muito meu uso de Emacs, e agora o Emacs virou o hub central do meu trabalho

    • Fiquei curioso se, por integração aqui, você quer dizer que o modelo manipula o Emacs diretamente por meio de um servidor

  • Quando eu deixava uns 10 terminais abertos em algumas janelas, o Ghostty travava quase toda noite. Por isso nunca consegui usar o Ghostty direito, e também não gostaria de embuti-lo na ferramenta que uso todos os dias

    • Estou usando Ghostty 1.1.3 no Gentoo Linux, e no momento tenho cerca de 20 abas em cada uma de umas 12 janelas, com mais de 100 instâncias de shell em execução
      Também executei ls -lR no maior número possível de shells em um sistema de arquivos com milhões de arquivos, e não tive problemas nem travamentos. Uso pesado o dia inteiro, todos os dias, há meses, e nunca vi travamentos nem comportamento suspeito
      Parece bem provável que fosse um bug de alguma versão específica do Ghostty, ou alguma interação estranha com outro software, como driver de GPU. Aqui uso GPU da NVIDIA

  • Dizem que “os módulos nativos são binários pré-compilados e são baixados automaticamente no primeiro uso”, então fiquei curioso por que eles não são incluídos no pacote de distribuição

    • MELPA e ELPA não têm como anexar arquivos por plataforma e distribuem tudo como checkout de Git. Para incluir isso no pacote, seria preciso colocar no repositório os binários do módulo para todas as plataformas, o que no total passa de 10 MB
      O jinx, um pacote popular que usa módulos nativos do Emacs, também oferece uma abordagem parecida com a do vterm, compilando no primeiro uso. Então, para oferecer uma instalação amigável em pacotes do Emacs, na prática só resta baixar ou compilar na primeira execução