▲

Ghostling - Minimum Viable 터미널 에뮬레이터

 (github.com/ghostty-org)
2P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • libghostty C API를 기반으로 한 최소 기능의 터미널 데모로, 단일 C 파일과 Raylib 렌더링을 사용해 동작
  • libghostty-vt의 기능을 검증하기 위한 구조로, GPU 렌더링 대신 2D 그래픽 기반 터미널 구현을 보여줌
  • 텍스트 리플로우, 24비트 컬러, 유니코드 처리, 마우스·키보드 프로토콜 등 실제 터미널 수준의 기능을 지원함
  • Kitty Graphics Protocol과 OSC 클립보드·타이틀 설정 등 일부 기능은 아직 미구현 상태이며, Windows 지원도 포함되지 않음
  • libghostty의 핵심을 활용해 다양한 애플리케이션이 독자적 GUI나 렌더러를 결합할 수 있는 확장성을 제공함

Ghostling 개요

  • Ghostling은 libghostty C API를 기반으로 한 최소 기능의 터미널 데모 프로젝트로, 단일 C 파일로 구성된 예제임
  • Raylib을 사용해 윈도우 관리와 렌더링을 수행하며, 단일 스레드 구조로 동작함
  • libghostty-vt의 유연성을 보여주기 위해 GPU 직접 렌더링 대신 2D 그래픽 렌더러를 사용함
  • 완전한 일상용 터미널이 아닌 최소 실행 가능한 터미널 구현 예시로, 코드의 정확성 검증은 제한적임

Libghostty 소개

  • Libghostty는 Ghostty의 핵심에서 추출된 임베디드 터미널 에뮬레이션 라이브러리로, C와 Zig API를 제공함
  • libghostty-vt는 의존성이 없는 라이브러리로, VT 시퀀스 파싱, 커서 위치, 스타일, 스크롤백 등 터미널 상태 관리를 담당함
    • 렌더링이나 윈도우 관리 코드는 포함하지 않으며, 이를 사용하는 애플리케이션이 직접 구현해야 함
  • Ghostty GUI에서 검증된 코드 기반으로, 정확하고 완전한 터미널 에뮬레이션, SIMD 최적화 파싱, 고급 유니코드 지원, 효율적 메모리 사용, 광범위한 테스트 기반 안정성을 제공함

주요 기능

  • 텍스트 리플로우를 포함한 창 크기 조정 지원
  • 24비트 컬러 및 256색 팔레트, 볼드·이탤릭·역상 스타일 지원
  • 유니코드 및 다중 코드포인트 그래핌 처리 (단, 셰이핑·레이아웃 없음)
  • Shift, Ctrl, Alt, Super 등 수정키 입력 처리
  • Kitty 키보드 프로토콜, 마우스 추적(X10, normal, button, any-event), 여러 마우스 리포팅 포맷(SGR, URxvt, UTF8, X10) 지원
  • 스크롤 휠 및 드래그 스크롤바, 포커스 리포팅(CSI I / CSI O) 지원
  • Ghostty GUI와 동일한 수준의 터미널 에뮬레이션 기능 대부분 포함

예정된 기능

  • 아직 libghostty-vt에서 완전히 노출되지 않은 기능

    • Kitty Graphics Protocol

    • OSC 클립보드 지원

      • OSC 타이틀 설정
      • Windows 지원은 libghostty-vt에서 가능하지만 Ghostling에서는 미구현 상태
      • 향후 추가 기능이 발견될 때마다 목록이 확장될 예정

제공되지 않는 기능

  • libghostty는 터미널 에뮬레이션 핵심에 집중하므로, GUI 계층 기능은 포함하지 않음
    • 탭, 다중 윈도우, 분할 화면, 세션 관리, 설정 파일, GUI, 검색 UI 등은 미포함
  • 이러한 기능은 libghostty를 사용하는 애플리케이션이 직접 구현해야 함
  • Ghostling은 최소 예시를 유지하기 위해 이러한 기능을 의도적으로 제외함

빌드 방법

  • 필수 요구사항: CMake 3.19 이상, C 컴파일러, PATH에 Zig 0.15.x
  • Raylib은 설치되어 있지 않으면 CMake의 FetchContent로 자동 다운로드됨
  • 기본 빌드 절차 
    cmake -B build -G Ninja  
cmake --build build  
./build/ghostling
  • 주의: 디버그 빌드는 안전성 검사로 인해 매우 느리며, 벤치마크용으로 부적합함
  • Release 빌드 
    cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release  
cmake --build build
  • 초기 설정 이후에는 cmake --build build만 실행하면 됨

FAQ

  • Zig 대신 C를 사용한 이유

    • libghostty-vt는 완전한 Zig API를 제공하지만, C API는 더 널리 사용되고 접근성이 높음

      • Ghostling은 최소 C API 사용 예시를 보여주기 위한 데모임

  • Rust 등 다른 언어 지원

    • libghostty-vt는 C API를 통해 제로 의존성으로 동작 가능
    • 대부분의 언어에서 얇은 바인딩만으로 사용 가능하며, 공식 바인딩은 C와 Zig 중심
    • 커뮤니티에서 다양한 언어 바인딩을 개발·유지하기를 기대함

  • Raylib 필수 여부

    • 필수 아님. libghostty는 렌더러나 GUI 프레임워크에 대한 제약이 없음
    • WASM 환경에서도 독립적으로 동작 가능
    • 렌더 상태 API를 제공해, Metal·OpenGL·Raylib 등 어떤 렌더러와도 결합 가능

  • CMake와 Raylib 선택 이유

    • 특정 기술에 종속되지 않으며, CMake는 범용적이고 지원이 넓은 빌드 시스템

    • Raylib은 간단하고 설정이 쉬운2D 윈도우·렌더링 라이브러리

      • 프로젝트의 목적은 기술 선택보다 libghostty의 활용 예시를 보여주는 데 있음
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • 나는 libghostty를 Trolley에 사용하고 있음
    이 프로젝트는 TUI를 데스크톱 앱으로 패키징하는데, 웹앱을 Electron으로 감싸는 방식과 비슷함
    단순히 GUI와 CLI 번들러를 덧붙였을 뿐인데, Windows에서도 완벽히 작동함
    Ghostty 개발자들에게 진심으로 감탄함

    • 네 GitHub README에 스크린샷이 하나쯤 있으면 좋겠음
      앱이 TUI 주변에 어떤 chrome(UI 외곽) 을 추가하는지 바로 이해할 수 있을 것 같음

  • C 파일이 작아서 몇 분이면 다 읽을 수 있었음
    5번째 줄쯤에서 폰트를 자동 생성된 헤더로 임베딩하는 독특한 방식을 보고 놀랐음
    Windows 리소스 방식에 익숙했는데, 이건 CMake 코드로 바이트 배열을 생성하는 구조였음
    약간 충격적이면서도 인상 깊었음 — 드디어 크로스플랫폼 바이너리 리소스 임베딩의 해법을 찾은 느낌임

    • 여기에 사용된 빌드 스크립트를 공유함
      cmake -DINPUT=pixel.gif -DOUTPUT=pixel.h -DARRAY_NAME=pixel_gif -P bin2header.cmake 명령으로
      1x1 픽셀 GIF를 C 배열로 변환할 수 있었음
      자동 생성된 헤더에 이미지가 그대로 바이트 배열로 들어감
    • 재미있는 사실로, XPM 비트맵은 원래 수정 없이 #include할 수 있도록 설계되었음
      X PixMap 위키에 그 구조가 잘 설명되어 있음
    • vim 패키지의 xxd 명령으로도 이런 배열을 만들 수 있음
      하지만 큰 리소스에는 비효율적임 — gcc/clang이 메모리 폭발을 일으킴
      그래서 나는 LIEF 프로젝트를 사용함
      이건 Windows PE, macOS Mach-O, Linux ELF 바이너리에 리소스를 삽입하고 다시 읽을 수 있게 해줌
      덕분에 크기 제한 없는 크로스플랫폼 리소스 번들링 시스템을 구축할 수 있었음
    • Windows 프로그래머로서 DrawTextEx 호출을 본 게 흥미로웠음
      Ghostty 라이브러리의 표현력을 잘 보여주는 샘플이었음
      다른 라이브러리 선택도 훌륭했고, 나도 터미널 앱을 직접 만들어보고 싶다는 영감을 받았음
    • “드디어 발견했다”는 표현에 공감하지는 않음
      소스 코드에 바이너리 포함은 오래된 기법임
      70~80년대 BASIC의 DATA 라인이나 Atari ST, Amiga 게임에서도 이런 방식이 흔했음
      Java에서도 픽셀 단위 폰트를 .java 파일에 직접 넣은 적이 있음
      Linux 커널의 일부 폰트도 이런 식으로 처리된다고 들었음

  • 이 프로젝트가 흥미로움
    나는 터미널 에뮬레이터에 탭이나 세션 관리 기능이 필요하지 않음
    WM이 창과 탭을 관리하고, tmux가 세션·스크롤백·검색 등을 처리함
    그래서 urxvt, st, foot 같은 단순한 터미널로 충분했음
    Ghostty는 내 취향이 아니었지만, 이건 한 번 써볼 만함
    OSC 지원이 예정되어 있고, st보다 덜 번거로운 플러그인 시스템이 추가되면 좋겠음

답변달기