Ghostty 엔진을 Emacs 안으로 끌고 온 터미널, Ghostel.el

• Ghostel.el은 Emacs 안에서 Ghostty 엔진을 쓰는 터미널 에뮬레이터임

  • 핵심 엔진은 Ghostty의 libghostty-vt이고, Emacs 패키지로는 eat.el 스타일의 입력 모드를 가져옴
  • 목표는 단순히 shell buffer 하나 더 만드는 게 아니라, 현대 터미널 기능과 Emacs 편집 UX를 같이 잡는 쪽에 가까움

• 입력 모드는 5개로 나뉨

  • 기본값은 semi-char mode로, 대부분의 키는 터미널에 보내되 M-x, C-c 같은 일부 Emacs 키는 남겨둠
  • char mode는 모든 키를 터미널로 보내고 M-RET으로 빠져나옴
  • line mode는 M-x shell처럼 Emacs 버퍼에서 한 줄을 편집한 뒤 RET을 누를 때 한 번에 shell로 보냄
  • emacs mode와 copy mode는 버퍼를 일시적으로 읽기 전용 Emacs 버퍼처럼 다루게 해줌

• copy mode의 포인트는 “출력이 계속 흘러도 선택 영역이 안 날아가게 하는 것”임

  • copy mode는 터미널 redraw를 멈춰서 선택한 텍스트가 안정적으로 유지됨
  • emacs mode는 읽기 전용이지만 live output은 계속 들어옴
  • 마우스로 드래그하거나 mark를 활성화하면 설정에 따라 자동으로 copy mode나 emacs mode로 전환됨

• line mode는 shell 입력을 Emacs 편집 대상으로 바꿔버림

  • M-b, M-DEL, C-y, 단어 전치 같은 Emacs 편집 키가 입력 중인 한 줄에서 동작함
  • RET을 누르면 bash가 한 번의 write로 전체 줄을 받고 echo 후 실행함
  • async output이나 새 prompt가 중간에 와도 snapshot/restore로 작성 중인 입력을 보존함
  • python3, irb, sqlite3 같은 REPL도 터미널 cursor를 입력 경계로 삼아 동작함

• fullscreen TUI와 line mode가 충돌하는 상황도 처리함

  • vim, less, htop 같은 alt-screen TUI는 모든 키를 raw로 받아야 함
  • Ghostel은 TUI가 시작되면 line mode에서 semi-char로 내려가고, TUI가 끝나면 다시 line mode를 복귀시킴
  • tmux나 screen 안쪽 shell prompt에서 OSC 133 marker가 전달되면 그 prompt에서도 line mode에 직접 들어갈 수 있음

• password prompt 처리가 꽤 세심함

  • sudo, ssh, gpg, passwd 등이 비밀번호를 요구하면 read-passwd를 띄워 입력받고 PTY로 보냄
  • 이때 키 입력이 Emacs의 일반 key pipeline을 지나지 않아서 view-lossage, recent-keys ring, keyboard macro recording에 남지 않음
  • primary signal은 slave tty가 canonical mode이면서 echo off인지 보는 libghostty식 heuristic이고, remote shell에서는 regex fallback도 씀
  • 전송 후 password string은 즉시 clear-string 처리해 heap에 오래 남지 않게 함

• ghostel-compile은 M-x compile UX를 실제 TTY 위에 얹은 기능임

  • shell command를 ghostel buffer에서 실행하고 compilation-mode 스타일 header, footer, error highlighting, next-error navigation을 제공함
  • PTY 기반이라 isatty(3)를 확인하는 프로그램도 색상, progress bar, curses 동작을 일반 터미널처럼 처리함
  • 기본은 read-only buffer라 실행 중에도 output을 읽고 C-c C-c로 죽이는 compile-mode 감각을 유지함
  • prefix arg를 주면 interactive mode로 실행해서 htop, less, 입력을 요구하는 test runner도 다룰 수 있음

• eat, vterm과 비교하면 Ghostel의 포지션이 꽤 분명함

  • eat은 순수 Emacs Lisp라 빌드 없이 어디서나 돌아가는 게 장점이지만 성능은 낮음
  • vterm은 CMake로 native dependency를 빌드하고 보수적인 VT220/xterm emulation 쪽에 가까움
  • Ghostel은 첫 실행 때 prebuilt module을 받거나 Zig로 빌드하고, 그 대가로 Ghostty 쪽 현대 터미널 기능을 가져옴

• 기능 지원도 Ghostel 쪽이 공격적임

  • Kitty keyboard와 graphics protocol, 5가지 underline style, OSC 8 hyperlink, OSC 4/10/11 color query, DEC 2026 synchronized output을 지원함
  • inline image는 Ghostel이 Kitty graphics, eat이 Sixel로 지원하고 vterm은 지원하지 않음
  • mouse event는 Ghostel과 eat이 SGR protocol로 child program에 전달하지만, vterm은 Emacs point movement 쪽으로 intercept함

• 성능 수치도 꽤 세게 제시됨

  • 1MB stream, 약 1,000 lines scrollback, Emacs 32.0.50 기준 plain ASCII throughput에서 Ghostel은 약 75MB/s를 기록함
  • vterm은 약 18MB/s, eat은 약 6MB/s, Emacs built-in term은 약 7MB/s 수준임
  • URL이나 path가 많은 출력에서는 clickable-link detection 비용 때문에 Ghostel 처리량이 대략 절반으로 줄지만 그래도 나머지보다 앞선다고 함

• 단점이나 트레이드오프도 명확함
  • eat처럼 순수 Elisp가 아니라 native module 다운로드나 Zig 빌드가 필요함
  • unfamiliar TERM=xterm-ghostty 때문에 일부 build/test tool이 헷갈리면 xterm-256color로 바꿔야 할 수 있음
  • Ghostty/Kitty 계열 기능을 잘 활용하는 대신, Sixel만 뿜는 프로그램은 eat과 호환되는 방식으로 보이지 않을 수 있음

---

기술 맥락

• Ghostel의 핵심 선택은 Emacs Lisp만으로 터미널을 만들기보다 Ghostty의 native VT 엔진을 끌어오는 거예요. 이렇게 하면 설치와 배포는 조금 복잡해지지만, Kitty protocol이나 synchronized output 같은 현대 터미널 기능을 한 번에 가져올 수 있거든요.

• line mode가 재미있는 이유는 터미널 입력을 char stream으로 바로 보내지 않고 Emacs 버퍼 편집으로 한 번 감싸기 때문이에요. shell에는 최종 한 줄만 atomic하게 보내면서도 사용자는 Emacs의 이동, 삭제, yank, completion을 그대로 쓰는 구조라서 평소 편집 습관을 버리지 않아도 돼요.

• password prompt 처리는 보안 UX 쪽 선택이에요. 일반 터미널처럼 키를 하나씩 보내면 Emacs 내부 기록에 남을 수 있으니, tty echo 상태와 remote prompt regex를 보고 별도 read-passwd 경로로 빼는 거예요.

• ghostel-compile은 compile-mode와 terminal-mode 사이의 오래된 갈등을 줄이려는 기능이에요. 빌드 도구는 실제 TTY를 보고 색상과 progress를 내보내고, 사용자는 compilation buffer처럼 에러 이동과 재실행을 할 수 있으니 양쪽 장점을 섞은 셈이에요.