Ghostel 메인테이너임. baokaola와 다음 주에 Show HN을 올리려 했는데 누군가 먼저 링크를 제출했음
빠르게 훑어보려면 GitHub 저장소가 더 편함: https://github.com/dakra/ghostel
Ghostel은 libghostty-vt 기반 Emacs 터미널 에뮬레이터이며, vterm 및 eat과의 기능 비교는 https://dakra.github.io/ghostel/#ghostel-vs-vterm에서 볼 수 있음. 성능과 정확성을 이미지로 비교한 자료도 있음: https://gist.github.com/dakra/4a0b76ebcf5d52338e134864378465...
개인적으로는 vterm/eat뿐 아니라 kitty와 Ghostty 같은 외부 터미널까지 대체했음. 터미널 텍스트를 일반 Emacs 버퍼처럼 다루면 다른 터미널에는 없는 수많은 확장 가능성이 열림. 스크롤백을 검색한 뒤 키보드만으로 이동하고 문단을 선택해 복사하는 간단한 작업도 Emacs 사용자에게는 훨씬 자연스럽고 빠름
Ghostel을 써보고도 외부 터미널을 유지한다면 부족한 기능 때문인지, 일부 프로세스를 Emacs 밖에서 실행하려는 것인지 궁금함. GitHub에서도 활발히 대응하고 있으니 문제가 있으면 이슈를 열어주길 바람

지금까지 Ghostel이 아주 잘 작동함. f1을 세미 문자 모드와 복사 모드 전환에 할당했고, 명령을 실행하기 전에 “Emacs가 죽거나 강제로 종료돼도 괜찮은가?”를 생각함. 안 괜찮다면 일반 터미널에서 실행함

Magit 등이 큰 diff를 파싱할 때 Emacs 전체가 멈출 수 있어서, 결국 별도 터미널을 계속 유지하게 됨

eshell에서는 다른 Emacs 버퍼와 똑같이 텍스트를 조작할 수 있음. 단어를 따옴표로 감싸는 함수를 키에 연결하면 eshell에서도 그대로 작동하고, evil-mode·xah-fly-keys·ispell도 모두 쓸 수 있다는 점이 결정적인 장점임
Ghostel은 같은 수준으로 통합되지 않았고 evil-ghostel-mode 같은 확장도 한계가 있음. 이를 개선할 계획이 있는지, 구조적으로 감수해야 하는 제약인지 궁금하며 eat-eshell-mode에 대응하는 기능이 생기면 훌륭할 것 같음

WezTerm의 패턴 기반 Quick-select 모드가 있으면 좋겠음. 이 기능을 알게 된 뒤로는 다른 터미널을 쓰고 싶지 않을 정도임

Doom Emacs에서 한동안 잘 사용하고 있음. Lazygit이나 Reasonix처럼 화면을 스크롤하는 프로그램이 다른 에뮬레이터에서는 실패하는데 Ghostel에서는 작동하는 이유가 궁금함. 구현이나 라이브러리에 특별한 처리가 있는 것인지 알고 싶음

제목에 Emacs가 들어가야 함. 일반 터미널 에뮬레이터와 Emacs용 터미널 에뮬레이터는 다름

최근 vterm에서 Ghostel로 바꿨는데 전반적으로 훨씬 낫다. 매 프레임 터미널 전체를 갱신하는 화려한 TUI 앱도 제대로 돌아갈 만큼 눈에 띄게 빠르고, 입력 처리가 더 안정적이며 ELisp API도 좋음
다만 터미널을 제대로 지우지 못해 현재 프롬프트 위쪽에 찌꺼기가 남거나, 완전히 멈춰서 버퍼를 닫고 다시 시작해야 했던 적이 있음. 일상적으로 사용하기에는 충분하고 전망도 밝지만, 성숙한 제품이 되려면 버그 수정과 마무리 작업이 더 필요함

Ghostel 공동 메인테이너임. 재현 방법이 없더라도 실행 가능한 정보가 생기면 이슈를 등록하거나 다른 방식으로 전달해주길 바람
화면 위쪽에 찌꺼기가 남는 현상은 https://github.com/dakra/ghostel/issues/495일 수 있으며 최신 버전에서는 수정됐지만 다른 버그일 가능성도 있음. 어려운 부분은 libghostty-vt의 내부 데이터를 Emacs 버퍼에 복제하면서 필요한 부분만 교체하는 것임. 이를 폭넓게 검증하는 속성 기반 테스트가 있지만 가끔 문제가 빠져나감
현재 최신 릴리스에서는 수명 주기 처리가 개선돼 일부 문제가 함께 해결됐을 수 있음. 아직 초기 단계인 만큼 점차 다듬어가려 함

서로 다른 입력 모드를 효율적으로 사용하는 실제 예시가 있으면 좋겠음. 터미널은 모든 키 입력을 원하고 편집기도 자체 명령에 키를 쓰려 하므로, 편집기 내장 터미널은 키보드의 소유권을 전환하는 모드가 반드시 필요함
Neovim의 :term에는 모드가 두 개뿐인데 Ghostel에는 왜 다섯 개나 있는지 이해하지 못하면 과도하게 설계됐다고 오해하기 쉬움. 실제로는 더 많은 문제를 해결하기 때문에 복잡한 것이며, 추가 모드는 nvim이 다루지 않는 작업을 위한 선택적 도구임. 다만 이 장점을 실전에서 어떻게 효율적으로 활용할지는 충분히 명확하지 않음

vterm 사용에 어려움을 겪던 중 Ghostel을 시험해보니 훌륭해서 주력 터미널이 될 수도 있을 것 같음

vterm에서 eat을 거쳐 Ghostel로 옮겨왔으며, 적어도 지금까지는 Ghostel이 가장 낫다고 봄

한 달 넘게 사용 중인데, Codex 요약에 나온 코드 참조를 클릭해 Emacs 버퍼에서 바로 여는 기능이 특히 좋음

마우스뿐 아니라 ghostel-previous-hyperlink나 ghostel-next-hyperlink로 최근 표시된 하이퍼링크 사이를 빠르게 이동할 수 있음 repeat-mode 맵도 설치되므로 출력에 URL이나 파일 링크가 세 개 있다면 C-c C-p p p RET만으로 첫 번째 링크를 열 수 있어 자주 사용함

Ghostel과 Claude Code 통합 덕분에 Emacs 사용량이 크게 늘었고, 이제 Emacs가 작업의 중앙 허브가 됨

여기서 통합이란 모델이 서버를 통해 Emacs를 직접 조작한다는 뜻인지 궁금함

몇 개 창에 터미널을 약 10개 띄우면 Ghostty가 거의 매일 밤 충돌했음. 그래서 Ghostty를 제대로 사용하지 못했고, 매일 쓰는 도구 안에 내장하고 싶지도 않음

Gentoo Linux에서 Ghostty 1.1.3을 사용 중이며, 현재 약 12개 창마다 탭을 20개가량 열어 100개가 넘는 셸 인스턴스를 실행하고 있음
수백만 개 파일이 있는 파일 시스템에서 가능한 많은 셸에 ls -lR도 실행했지만 문제나 충돌은 없었음. 몇 달 동안 매일 종일 강하게 사용하면서도 충돌이나 수상한 동작을 본 적이 없음
특정 Ghostty 버전의 버그였거나, GPU 드라이버 같은 다른 소프트웨어와의 특이한 상호작용일 가능성이 커 보임. 여기서는 NVIDIA GPU를 사용함

“네이티브 모듈은 미리 빌드된 바이너리이며 최초 사용 시 자동으로 다운로드된다”는데, 왜 배포 패키지에 포함하지 않는지 궁금함

MELPA와 ELPA는 플랫폼별 파일을 첨부할 방법이 없고 전부 Git 체크아웃으로 배포함. 배포본에 포함하려면 모든 플랫폼의 모듈 바이너리를 저장소에 넣어야 하며, 합치면 10MB가 넘음
Emacs 네이티브 모듈을 사용하는 인기 패키지 jinx도 vterm처럼 최초 사용 시 컴파일하는 방식을 제공함. 따라서 Emacs 패키지에서 사용자 친화적인 설치를 지원하려면 현실적으로 최초 실행 시 다운로드하거나 컴파일하는 방법밖에 없음