Emacs를 예쁘게 보이게 하고 싶었을 뿐 – 터미널에서 24비트 색상 사용

 (chadaustin.me)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 터미널 Emacs에서 Solarized 같은 테마를 제대로 보려면 24비트 색상 자체보다 터미널, terminfo, tmux, mosh가 같은 색상 기능을 끝까지 이해하는지가 중요함
  • RGB 색상은 ESC[38;2;<r>;<g>;<b>m 형태로 널리 쓰이지만, 표준에 가까운 콜론 구문과 실제 구현에서 퍼진 세미콜론 구문이 함께 남아 호환성을 복잡하게 만듦
  • xterm-256color와 xterm-direct는 각각 256색 팔레트와 16,777,216색을 광고하지만, terminfo의 팔레트 중심 모델은 직접 RGB 색상을 깔끔하게 표현하지 못함
  • 실제 환경에서는 ncurses-term의 -direct 항목, tmux-direct, mosh 1.4 계열, vscode-direct 같은 대체 TERM 값이 필요할 수 있으며 일부 계층은 여전히 세미콜론 방식만 받음
  • 현대 터미널 기능을 안정적으로 쓰려면 TERM과 terminfo만으로는 부족하며, 터미널 이름·버전별 기능을 더 빠르게 갱신하는 별도 표현 방식이 필요함

터미널 Emacs에서 24비트 색상이 필요한 이유

  • 그래픽 환경의 Emacs는 자동으로 24비트 색상을 지원해 Solarized 같은 테마와 글꼴을 제대로 보여줌
  • 터미널에서 같은 테마를 쓰면 색 표현이 제한되어 화면이 덜 보기 좋게 나올 수 있음
  • 인기 터미널들은 오래전부터 24비트 색상을 지원했지만, 프로그램이 이를 쓰려면 기능 감지와 설정이 모두 맞아야 함
  • 목표는 두 가지임
    • 현재 터미널 환경에서 truecolor 지원을 켜는 방법 찾기
    • Emacs 색상 문제가 1970~1990년대 터미널 표준과 어떻게 이어지는지 확인하기

ANSI 이스케이프 코드와 색상 확장 역사

  • 초기 하드웨어 터미널은 서로 다른 제어 코드 체계를 썼고, 이식 가능한 소프트웨어를 만들려면 ANSI 표준화가 필요했음
  • ANSI escape codes는 1970년대부터 이어졌으며, 색상에서는 SGR(Select Graphics Rendition) 이 핵심임
    • 굵게 또는 밝기
    • 이탤릭
    • 깜박임
    • 전경색과 배경색
    • 기타 문자 표시 속성
  • 처음 색상은 RGB 큐브의 8개 꼭짓점에 해당하는 3비트 색상이었음
    • 검정, 흰색, 가산 원색, 감산 원색이 포함됨
  • 이후 밝은 색 또는 굵게 비트가 추가되며 16색으로 확장됨
    • “bright black”은 짙은 회색에 해당함
  • 1999년 Todd Larason은 xterm에 256색 지원 패치를 추가함
    • 6x6x6 RGB 색상 큐브 샘플링
    • 24단계 그레이스케일 램프
    • 드물지만 여전히 지원되는 88색 변형도 존재함

24비트 색상 구문이 만들어진 경로

  • 8비트 색상과 24비트 색상은 호환 터미널에서 다음 형태로 설정됨
    • ESC[38;5;<n>m: 팔레트의 색상 번호 n을 전경색으로 설정
    • ESC[38;2;<r>;<g>;<b>m: RGB 값 r, g, b를 전경색으로 설정
  • 숫자 5와 2는 ISO 8613-6, 즉 ITU T.416의 확장 색상 모드와 연결됨
    • 2: RGB 공간의 직접 색상
    • 5: 인덱스 색상
  • 표준화 흐름은 다음과 같음
    • 1970년대: ANSI가 터미널 이스케이프 시퀀스를 표준화해 ANSI X3.64와 ECMA-48로 이어짐
    • 1979년: ECMA-48 2판이 SGR 30~37, 40~47을 3비트 전경색과 배경색에 할당함
    • 1984년: ECMA-48 3판이 기본 전경색과 배경색 개념을 도입하고 39, 49를 할당함
    • 1991년: ECMA-48 5판은 38과 48을 “미래 표준화용”으로 남기고 ISO 8613-6을 단서로 둠
    • 1993년: ISO 8613-6이 38과 48을 확장 전경색·배경색 모드로 정의함
  • 하위 파라미터 구분에는 콜론을 쓰는 쪽이 표준에 가깝지만, 실제 구현은 세미콜론을 널리 채택함
    • ESC[38;5;3m은 SGR 38을 모르는 터미널에서 38, 5, 3이라는 별도 파라미터처럼 해석될 수 있음
    • Thomas Dickey의 xterm FAQ는 당시 ITU T.416 사본이 비쌌고, RGB 값을 다른 SGR 파라미터처럼 세미콜론으로 구분한 것이 잘못이었다고 설명함
  • 관련 타임라인은 다음과 같음
    • 1999년: Thomas Dickey가 Todd Larason의 256색 패치를 xterm에 병합했고, 모호한 세미콜론 구문이 들어감
    • 2006년: Konsole이 xterm과 같은 세미콜론 구문으로 256색과 24비트 truecolor를 지원함
    • 2012년: xterm이 표준에 가까운 콜론 구문도 받도록 수정됨
    • 2016년: Windows 10 내장 콘솔이 ANSI 이스케이프 코드와 24비트 색상을 지원했지만 세미콜론 구문을 사용함
    • 2019년: Windows Terminal도 ANSI 이스케이프 코드를 지원하지만 세미콜론 구문을 사용함
    • 2022년: Microsoft가 레거시 VGA 스타일 콘솔 서브시스템에서 ANSI 터미널 에뮬레이션으로의 생태계 전환을 발표함
    • 2022년: Konsole이 표준 호환 콜론 구문을 지원함

terminfo가 색상 기능을 표현하는 방식

  • terminfo는 터미널 기능 데이터베이스와 적절한 이스케이프 시퀀스 생성 기능을 제공함
  • TERM 환경 변수는 프로그램이 사용할 terminfo 레코드를 가리키며, ssh 연결에서도 자동으로 전달됨
  • toe는 설치된 terminfo 레코드 목록을 보여주고, infocmp는 특정 레코드의 기능 확인에 쓰임
  • 색상과 관련해 중요한 기능은 세 가지임
    • colors: 터미널이 지원하는 색상 수
    • setaf: 전경색 설정
    • setab: 배경색 설정
  • xterm-256color의 setaf는 색상 번호에 따라 다른 시퀀스를 냄
    • 0~7: ANSI 30~37 SGR 파라미터 사용
    • 8~15: 비표준 90~97 밝은 색상 사용
    • 그 이상: 38;5;<n> 형태의 256색 팔레트 사용
  • xterm-direct는 colors를 16,777,216으로 광고하는 24비트 RGB용 terminfo 항목임
    • ccc를 끄며, 색상 인덱스에 새 RGB 값을 할당할 수 없음을 나타냄
    • initc, oc, rs1 같은 런타임 색상 변경 관련 항목도 빠짐
    • setaf와 setab는 콜론 기반 38:2::... 형태를 사용함

terminfo의 직접 색상 모델 한계

  • terminfo와 ncurses의 프로그래밍 모델은 기본적으로 팔레트 엔트리 중심임
    • N개의 팔레트 엔트리가 있음
    • 각 엔트리에 기본 RGB 값이 있음
    • 터미널이 이 값을 바꿀 수 있다는 모델을 가정함
  • -direct 터미널은 16,777,216개의 팔레트 엔트리가 있는 것처럼 표현해 24비트 색상을 나타냄
    • 각 엔트리는 8:8:8 RGB 큐브에 대응함
    • 값은 변경할 수 없음
  • 호환성을 위해 xterm-direct 방식은 가장 어두운 파란색 7개를 기본 ANSI 8색과의 호환에 사용함
    • 검정은 제외됨
    • 기존 프로그램이 setaf의 의미를 가정하다가 거의 보이지 않는 짙은 파란색을 출력하는 일을 피하기 위한 장치임
  • 이 때문에 -direct 방식과 -256color 방식은 서로 호환되지 않음
    • 프로그램은 256색이 인덱스 색상이고 16,777,216색이 직접 색상임을 알아야 함
    • 가장 어두운 파란색 7개를 피해야 하는 예외도 있음
  • termwiz 관련 문제에서는 프로그램이 xterm-256color 팔레트를 기대했지만 실제로는 읽기 어려운 짙은 파란색 계열을 출력했음
    • 해당 이슈는 작성 시점에는 열려 있었지만, @quark-zju가 수정 사항을 반영해 현재 termwiz는 합리적으로 동작함
  • 핵심은 터미널 자체보다 terminfo 제약에 가까움
    • 24비트 색상을 지원하는 터미널은 xterm 256색 팔레트와 RGB 값 동적 변경도 지원하는 것으로 보임
    • terminfo는 현대 터미널 에뮬레이터 생태계를 정확하고 빠르게 표현하기에 부족함

TERM 설정과 세미콜론 호환성

  • terminfo를 많은 프로그램이 사용하므로 TERM 값은 올바르게 설정해야 함
  • 콜론 기반 SGR 구문으로 통일하고 싶어도 여러 환경은 여전히 세미콜론 구문만 지원함
    • Windows 내장 콘솔인 Conhost
    • Mintty와 Cygwin 환경에서의 일부 동작
    • Mosh
    • PuTTY
    • Ubuntu 22.04 LTS에 포함된 Konsole 버전
  • terminfo 항목은 빌딩 블록으로 구성됨
  • xterm+indirect를 검색한 결과, vscode-direct가 가장 적합해 보였음
    • Microsoft 터미널을 대상으로 하므로 Windows Terminal과 Windows Console에 충분히 가깝다고 판단됨
    • 모든 기능을 감사한 것은 아니지만 동작함
  • 많은 서버에는 -direct terminfo 항목이 설치되어 있지 않을 수 있음
    • 대부분의 시스템에서 기본 terminfo 데이터베이스는 ncurses-base 패키지에 있음
    • 확장 터미널 항목은 ncurses-term 패키지가 필요함
  • ncurses에는 작성 중 winconsole terminfo 항목이 추가됐지만, 24비트 색상을 지원하지 않고 아직 어떤 ncurses 버전에도 릴리스되지 않았음

Emacs가 truecolor를 감지하는 방식

  • Emacs는 TTY에서 truecolor 지원을 감지하는 방식을 문서화함
  • M-x eval-expression에서 (display-color-cells)를 실행하면 Emacs가 16,777,216색을 인식하는지 확인할 수 있음
  • Emacs 문서는 -direct 모드의 terminfo 한계도 다룸
    • RGB 기능이 있는 터미널은 #000001부터 #000007까지를 직접 RGB가 아닌 인덱스 색상처럼 취급할 수 있음
    • 이는 direct color를 모르는 애플리케이션과의 하위 호환을 유지하기 위함임
    • 문제가 되면 setb24, setf24가 있는 커스텀 터미널 정의를 쓸 수 있음
  • Emacs는 먼저 setf24와 setb24 문자열을 찾고, 없으면 RGB를 대체 기능으로 사용함
  • 확인한 시스템의 terminfo 항목에는 setf24가 포함되어 있지 않았음

중첩 터미널에서 모든 계층이 맞아야 함

  • 일반적인 작업 흐름은 여러 터미널 계층을 중첩함
    • 로컬 데스크톱의 그래픽 터미널 에뮬레이터 열기
    • 원격 머신이나 VM에 mosh로 접속하기
    • tmux 시작하기
    • Emacs 내부 터미널, Asciinema, GNU Screen 등을 추가로 사용하기
  • 각 계층은 자체적으로 ANSI 이스케이프 시퀀스 상태 기계를 구현함
  • 24비트 색상이 작동하려면 모든 계층이 안쪽 TERM 값의 terminfo에서 생성한 이스케이프 시퀀스를 이해하고, 바깥쪽 terminfo에 맞게 정확히 전달해야 함
  • 따라서 관련 소프트웨어가 충분히 최신이어야 함
    • 현재 Ubuntu LTS는 mosh 1.3을 제공하므로 mosh-dev PPA를 활성화해야 했음
  • 각 계층 안의 TERM도 정확해야 함
    • tmux 안에서는 tmux-direct를 사용함
    • mosh에는 표준 terminfo가 없으므로 충분히 가까운 값을 골라야 함

환경별 설정

  • 그래픽 터미널 에뮬레이터

    • 대부분의 터미널은 적절한 기본 TERM을 설정하거나 사용자가 재정의할 수 있음
    • Konsole에는 TERM 값을 선택하는 옵션이 있음

  • ssh

    • ssh는 TERM 값을 새 셸로 전달함
    • 원격 호스트에 같은 terminfo 레코드가 있으면 설정이 비교적 단순함

  • tmux

    • tmux를 실행하면 TERM이 screen으로 설정될 수 있음
    • ~/.tmux.conf에서 기본 터미널을 바꿔 해결함
    set -g default-terminal "tmux-direct"
    • 바깥쪽 TERM이 24비트 색상을 지원할 때만 조건부로 tmux-direct를 설정하고, 그렇지 않으면 screen이나 tmux-256color를 유지하는 방식도 고려할 수 있음

  • mosh

    • 최신 mosh는 24비트 색상을 지원하지만, 자체적으로는 8색 또는 256색만 광고함
    • 따라서 사용자가 TERM을 적절히 설정해야 함
    • mosh는 xterm 호환을 목표로 하지만 SGR 38과 48에서 세미콜론 구문만 지원함
    • TERM=xterm-direct는 동작하지 않음
    • vscode-direct가 xterm-direct에 가장 가까운 대안으로 쓰였음
    • mosh 실행 여부를 알려주는 편한 변수가 없어 detect-mosh.rs 스크립트를 작성해 .bashrc에서 호출함
    • 셸 프로세스가 mosh-server의 자식인지 확인하는 방식임
    • 로그인 경로에서 Rust를 컴파일하는 방식이 저성능 호스트에 적합한지는 확정하지 않았음

최종 결과와 남은 문제

  • 설정 후 tmux와 mosh 안의 Emacs에서도 테마가 24비트 색상으로 표시됨
  • 남는 문제는 세 가지로 정리됨
    • 터미널들은 구문과 기능에 완전히 합의하지 않음
    • terminfo는 기능 조회의 표준적 경로임
    • terminfo는 제한적이고 때때로 부정확하며, 새 버전 릴리스도 자주 나오지 않음

terminfo 이후의 방향

  • 현대 터미널 기능을 충분히 활용하는 소프트웨어라면 terminfo에서 벗어날 필요가 있음
  • 가능한 방향은 다음과 같음
    • 널리 지원되는 TERM 변수는 계속 사용함
    • 운영체제나 배포판의 오래된 terminfo에만 의존하지 않고, 프로그램이 터미널 기능을 독립적으로 알 수 있게 함
    • 자주 갱신되는 라이브러리에 최근 10년 정도의 터미널 에뮬레이터 정보를 이름과 버전 기준으로 담음
    • 더 이상 쓰기 어려운 하드웨어 터미널 지원은 포함하지 않음
    • OS 제공 terminfo 파일과 terminfo 파일 형식은 계속 지원하되, 어느 정보가 최신인지 판단할 수 있는 프로토콜을 둠
    • 선택적 TERMVERSION으로 2022년 Konsole과 2023년 Konsole 같은 버전별 기능 차이를 구분함
    • 24비트 색상, 256색 팔레트 애니메이션, URL 링크, Kitty 그래픽 프로토콜 같은 현대 기능을 모호하지 않게 표현함
  • 레거시 프로그램을 위한 역호환 방식도 가능함
    • .bashrc에서 실행하는 프로그램이 TERM과 TERMVERSION을 사용해 $HOME/.terminfo/에 바이너리 terminfo 파일을 생성함
    • RGB, setf24, setb24 같은 명확한 24비트 색상 기능을 생성함
    • RGB를 모르는 프로그램은 256색 팔레트를 가정한다고 보고 colors#0x100, initc, oc를 유지함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • terminfo를 뒤지는 건 깊은 지하묘지에서 깜빡이는 횃불로 상형문자를 비춰보는 느낌임
    터미널 앱 하나에 얼마나 많은 복잡성이 들어가는지 생각하면 이상할 정도고, iTerm과 Kitty 같은 터미널 개발자들에게 더 고마워짐
    iTerm+zsh에서 탭 색을 설정하는 함수들을 모아둠: https://gist.github.com/aclarknexient/84ebe33c1879f921685304...
    예전처럼 telnet으로 HTTP나 SMTP에 붙는 방식과 비교하면, 텍스트 자체는 단순해도 그 텍스트를 보여주는 쪽은 온갖 기능을 지원하는 복잡한 애플리케이션임

    • 직접 만든 터미널을 쓰면서 초기에 terminfo는 신경 쓰지 않고 rxvt인 척하기로 했고, 생기는 문제는 감수하기로 함
      지금은 그 터미널의 사용자가 사실상 본인뿐이라 가능한 선택이지만, 현대 터미널들은 공통 부분집합을 꽤 지원해서 낯선 TERM 값을 앱들이 못 알아보고 혼란스러워하는 것보다 덜 고통스러움
      물론 새 시스템에 자주 SSH로 들어가지 않는다면 덜 중요한 문제임
    • 탭 색이 실제로 적용된 스크린샷을 공유해줄 수 있으면 좋겠음
    • Mac에서 가장 그리운 소프트웨어가 iTerm임
      가장 빠른 터미널 에뮬레이터는 아니지만, 외형은 압도적으로 가장 좋음

  • 여러 터미널 앱마다 16색 팔레트를 조정하는 편이, 애플리케이션 쪽 터미널 코드를 정확히 맞추는 것보다 쉬웠음
    ~/.Xdefaults에서 rxvt-unicode 색을 설정하고, Emacs 테마 .el에서는 그래픽 표시 여부에 따라 색 이름을 다르게 잡은 뒤 여러 face에 적용함
    덤으로 색상이 들어간 ls 출력도 더 보기 좋아짐. 기본 16색 팔레트는 너무 채도가 높고 대비가 나쁜 경우가 많음

    • 바로 (if (display-graphic-p)가 핵심임
      Emacs는 실제 그래픽 출력을 지원하고, X11/Cocoa/Win32에서 Esc가 진짜 Esc로 동작하며 Ctrl+Shift나 Cmd 바인딩, 여러 폰트 동시 사용, 이미지 표시, 커서 모양 변경 등이 가능함
      마치 20년 뒤인 1989년으로 데려다주는 타임머신 같음
    • 예전 TTL 디스플레이에서는 그 이상이 불가능했기 때문에 색이 그렇게 채도가 높았음
      빨간 선은 강한 빨강이거나 꺼짐뿐이고, intensity 선이 더해지면 100% 빨강이 되는 식이었음
    • DIRCOLORS에 시퀀스를 넣으면 ls도 실제로 24비트 색상을 지원함
    • 나도 Terminology의 16색 팔레트를 INI 파일에서 선호 테마에 맞게 조정해서, 콘솔과 터미널 앱(vim)에서 같은 스타일을 씀
    • 거의 같은 방식으로 씀
      기본 색은 어두운 배경에 비해 너무 어두워서, 모든 색의 휘도를 올려둠

  • 작성자가 export COLORTERM=truecolor를 알았다면 훨씬 덜 고생했을 것 같음
    링크된 Emacs 문서의 truecolor 감지 각주에도 나오고 Konsole 스크린샷에도 보이지만, 터미널 멀티플렉서 여러 겹 안에서 사라졌을 가능성이 큼
    이 값을 설정하면 앱이 트루컬러를 원한다는 걸 바로 이해하므로 어려운 부분을 건너뛸 수 있고, terminfo 데이터베이스도 필요 없음

    • 맞음. 이 역사에는 COLORTERM과 RGB terminfo 기능 같은 시행착오도 넣었어야 했음
      다만 모든 프로그램이 COLORTERM을 존중하지 않아서, .bashrc에서 linux | screen*일 때는 COLORTERM을 unset하고 나머지에서는 COLORTERM=truecolor를 export해둔 적이 있음
      요즘 Screen은 24비트 색상을 지원하니, 아마 Ubuntu 18 시절 설정이었을 것임
    • 또는 선호하는 GUI Emacs를 tramp나 sshfs와 함께 쓰면 됨
    • 맞음. terminfo 길로 내려가면 광기만 기다림
      한편으로는 ncurses 유지보수자가 꽤 보수적이고, 새 터미널 개발자들은 빠르게 움직이고 싶어 하기 때문이기도 함
    • terminfo 데이터베이스가 필요 없어진 건 Emacs 28부터임
      더 오래된 Emacs에서는 여전히 terminfo 데이터베이스가 필요함
    • COLORTERM도 꽤 이상함
      대부분은 정의할 필요가 없는데, screen 세션에서 COLORTERM=truecolor가 설정돼 있으면 갑자기 화면이 아주 이상해지고, 환경 변수를 지우면 다시 정상으로 보임

  • Emacs와 상호작용할 때 꼭 터미널을 쓸 필요는 없음
    MacOS, Windows, X.org, Wayland용 그래픽 프런트엔드를 쓸 수 있음
    그래픽 Emacs는 툴바를 꺼두면 터미널에서 도는 Emacs와 너무 비슷해서, Emacs를 모르는 사람은 동료 컴퓨터에서 보이는 그래픽 Emacs 창을 터미널 창으로 오해하기 쉬움
    Emacs 사용자 설문에서는 80%가 그래픽 프런트엔드를 쓴다고 답함

    • 반론으로, 완전한 GUI의 비대함 없이 터미널을 쓰고 싶다면 xterm-mouse-mode만으로도 장점의 80%는 얻을 수 있음
      mouse, xterm-mouse-mode, mouse-wheel-mode, 스크롤 설정 등을 넣으면 꽤 쓸 만하고, auto-save-default는 신의 뜻대로 nil로 둠
    • 터미널 에뮬레이터 안에서 Emacs를 돌리지 않음. Emacs가 터미널 에뮬레이터임
      모든 터미널 프로그램은 그래픽 Emacs의 shell-mode 버퍼에서 실행하고, 전체 화면 제어가 필요한 드문 프로그램만 term-mode를 씀
      가장 기능이 많거나 빠르지는 않지만, 다른 버퍼처럼 이동하고 편집 중인 내용과 매끄럽게 함께 다룰 수 있음
      원격 컴퓨터에서 그래픽 Emacs를 못 띄우면 tramp로 원격 파일을 편집하거나, headless Emacs 서버를 띄운 뒤 그래픽 emacsclient로 접속함
    • 좋은 지적임
      사람들이 내가 Emacs를 터미널에서 돌린다고 생각할 수 있다는 걸 고려해본 적이 없었음
      그래픽 Emacs가 훨씬 낫지만, 터미널에서도 90% 정도가 같은 방식으로 동작하고 보이는 건 여전히 훌륭함
    • X 기반 Emacs를 쓰는데 프로토콜이 효율적임
      체감은 터미널만큼 가볍고 VNC 같은 느낌이 아님
      폰트, 동시에 다른 폰트 사용, 메뉴, 마우스, 색상, 여러 프레임/창 같은 장점이 있음
      그래픽은 로컬에서 돌리고 tramp로 원격 시스템에 접근하면, 사실상 busybox만 있는 원격 Linux 기반 라우터의 설정 파일도 온갖 편의 기능과 함께 편집할 수 있음
    • 결국 항상 터미널 기반 Emacs로 돌아오게 되는 이유가 두 가지 있음
      90년대부터 X11을 간헐적으로 써왔지만, 폰트는 아직도 검색하다가 어쩌다 동작하는 명령을 찾고 그대로 건드리지 않는 수준임
      기업 환경에서 쓰게 되는 X11 설정보다 대부분의 터미널 프로그램 표시 성능이 여전히 눈에 띄게 빠름

  • 요즘은 최신 Emacs를 설치하고 24비트 xterm을 지원하는 터미널을 연 뒤 emacs -nw를 실행하면 됨
    테마 적용 후 괜찮아 보이면 끝이고, 아니면 .bashrc, .zshrc, .fishrc 등에 export COLORTERM=truecolor를 추가한 뒤 셸을 다시 로드하거나 그 줄만 실행하고 emacs -nw를 다시 시작하면 됨
    이 글은 terminfo를 파야 하는 것처럼 보이게 하지만, 보통은 그럴 필요가 없음. 10년 전이면 몰라도 지금은 아님
    MacOS의 iTerm과 Linux의 Alacritty, Kitty, Gnome Terminal에서 빠르게 다시 확인해봤고, 요즘은 24비트 xterm 지원이 흔함

  • 오늘 Windows 10 명령 프롬프트에서도 표준 ANSI 이스케이프 시퀀스가 동작한다는 걸 알게 됨
    24비트 색상도 잘 됨
    echo ^[[48;2;255;0;0mHello^[[0m를 실행하면 Hello가 빨간 RGB(255,0,0) 배경으로 출력되고, ^[[0m은 색을 원래대로 돌림
    ^[는 CTRL-[로 입력해야 하며, ^와 [를 따로 치면 안 됨

    • 명령줄에 출력 불가능 문자를 직접 넣지 않으려면, 이스케이프 코드를 받는 명령과 함께 \x1b 이스케이프 코드나 \e 별칭을 쓸 수 있음
      예를 들어 echo -e '\e[48;2;255;0;0mHello\e[0m'처럼 가능함
      다만 스크립트에서는 echo -e가 비표준이고 일반 echo도 경계 사례에서 다르므로 항상 printf '\e[48;2;255;0;0mHello\e[0m\n'를 쓰는 편이 좋음
    • C:\CONFIG.SYS 파일에 DEVICE=C:\DOS\ANSI.SYS를 추가하는 걸 잊지 말아야 함

  • vim/neovim과 비교했을 때 Emacs의 가장 좋은 점은, 단순히 창 안의 터미널 에뮬레이터가 아니라 일급 GUI 지원이 있다는 것임
    gVim이나 수많은 어중간한 neovim 프런트엔드가 있다는 건 알지만, Emacs의 기본 실행 방식은 진짜 GUI이고 그 점이 좋음
    터미널도 괜찮지만 역사적 찌꺼기와 제약이 너무 많고, 지금 시대에는 말이 안 되는 부분도 많음
    원격 서버에서 Emacs를 실행하는 게 문제라면 TRAMP와 emacsclient가 있음

    • 모든 걸 터미널에서 실행할 때 좋은 점은, 터미널에 보이는 건 무엇이든 복사할 수 있다는 것임
      GUI 앱이 표시 중인 텍스트를 복사하지 못하게 해서 손으로 다시 입력해야 할 때가 답답함
    • 사실이 아님. Neovim에는 네이티브 프런트엔드가 많고, 애초에 그런 구조를 가능하게 하도록 설계됐음
      https://github.com/neovim/neovim/wiki/Related-projects#gui
    • 완전히 동의함
      모달 편집과 vim을 정말 좋아하지만, 터미널 편집기가 주는 어중간한 해결책은 견디기 어려웠음
      풍부한 그래픽 플랫폼이 있는데 왜 쓰지 않겠음?
    • 워크플로에 크게 좌우됨
      예를 들어 vim은 거의 파일 편집에만 쓰고, git, 린터, 포매터, 디버거, 파일 트리 조작 같은 외부 도구는 셸로 돌아가서 씀
      그래서 내 주 애플리케이션은 이미 터미널 에뮬레이터이고, 이 워크플로에서는 전용 GUI가 없다는 점이 거의 중요하지 않음

  • 내 Emacs는 오히려 이렇게 보였으면 좋겠음: https://imgur.com/a/h0jA1ro
    진지한 얘기는 아니고 농담임. Cool Retro Term은 발표할 때만 씀
    보니 내 Emacs는 24비트 색상이 기본으로 동작함: https://imgur.com/a/BM5OTxp
    다만 구문 강조는 좀 거슬림

    • https://muppetlabs.com/~mikeh/crt_emacs.png
      Cool Retro Term은 훌륭하고, 나도 발표에서 써보고 싶음
    • Cool Retro Term을 정말 좋아하는데, 프로젝트가 거의 방치됐고 MacOS에서 여러 문제가 있어서 아쉬움
      개인적으로 다른 레트로 터미널들은 이만큼 보기 좋지 않음
    • Windows Terminal에서 가볍게 커스터마이즈한 CRT 효과를 실제로 쓰고 있음

  • 표준을 그렇게 비싼 가격 뒤에 가둬둔 건 정말 부끄러운 일임
    사람들이 사지 않으려고 이렇게까지 우회해야 하고, 이런 결과까지 생길 수 있음
    표준이라면 접근 가능해야 함. 책으로만 나오던 시절에는 인쇄비를 받는 게 말이 됐을지 몰라도, 허접한 PDF가 200달러였다는 건 믿기 어려움

  • xterm의 24비트 색상 패치를 작성했지만, 오늘에야 xterm-direct로 ncurses를 동작시키는 방법을 알게 됨
    이미 Lisp로 만든 자체 터미널 라이브러리를 쓰고 있었지만, ncurses로 대체 경로를 둘 수 있는 건 여전히 유용함
    Stack Overflow 질문에 답한 Mr. Dickey와 이 내용을 꺼낸 Chad에게 고마움

답변달기