Emacs 31에서 이미 매일 쓰는 변화들

 (rahuljuliato.com)
1P by GN⁺ | ★ favorite | 댓글 2개
  • Emacs 31은 정식 출시 전이지만 emacs-31 브랜치와 master에서 이미 체감 가능한 변화가 쌓이고 있으며, 여러 설정이 외부 패키지 없이 Emacs 코어만으로 해결되는 방향으로 이동함
  • Tree-sitter 자동 전환·문법 설치가 들어오면서 주요 모드와 문법 소스 설정을 직접 관리하던 부담이 줄어듦
  • markdown-ts-mode, Eglot 문서 렌더링, eldoc-help-at-pt, eager completion, xref-edit-mode는 편집·탐색·문서 확인 흐름을 내장 기능 중심으로 강화함
  • Speedbar side window, VC 자동 숨김, ERC 로그 조건, kill-region-dwim, ielm-history-file-name, native-comp-async-on-battery-power 같은 작은 옵션들이 반복적인 마찰을 줄임
  • Emacs 31의 기능명과 기본값은 아직 바뀔 수 있고, markdown-ts-mode와 이를 쓰는 Eglot 문서 렌더링은 실험적 기능이라 명시적으로 켜야 함

Emacs 31 프리뷰의 전제

  • Emacs 31은 아직 출시 전이며, 기준 환경은 2026년 중반에 emacs-31 브랜치와 master를 빌드해 쓰는 구성임
  • 소개된 항목들은 실제 일상 설정에 들어간 변경이며, 대부분 Emacs 코어에 들어왔거나 그에 가까운 상태임
  • 기능명과 기본값은 최종 릴리스 전까지 바뀔 수 있음
  • 설정 예시는 Emacs Solo의 init.el에서 ; EMACS-31 주석으로 확인할 수 있음

Tree-sitter 설정 감소

  • Emacs 31에서는 두 옵션으로 Tree-sitter 기반 모드 전환과 문법 설치 흐름이 단순해짐
    • treesit-enabled-modes t
    • treesit-auto-install-grammar t
  • treesit-enabled-modes를 t로 두면 Tree-sitter 변형이 있는 주요 모드를 해당 모드로 전환함
  • treesit-auto-install-grammar는 문법이 없을 때 오류만 내지 않고, Emacs가 문법을 가져와 빌드하도록 제안함
  • TypeScript, TSX, Rust, TOML, YAML, Dockerfile 같은 언어의 문법 소스가 모드 안에 들어가면서 treesit-language-source-alist에 URL과 경로를 직접 넣던 설정을 줄일 수 있음
  • 여러 아키텍처에서 공유 Emacs 디렉터리를 쓰는 경우에는 주의가 필요함
    • 자동 설치된 문법은 아키텍처별로 분리되지 않음
    • x86_64용 .so와 arm64용 .so가 같은 이름 아래 놓여, 한 머신에서 빌드한 바이너리가 다른 머신에서 로드되지 않을 수 있음

내장 markdown-ts-mode

  • Emacs 31에는 실험적 markdown-ts-mode가 포함됨
  • 이 모드는 2025년 초 emacs-devel에 보낸 제안에서 시작됐고, 이후 Stéphane Marks가 공동 작성자로 참여해 개선을 이어감
  • Markdown을 단순 구문 강조 대상이 아니라 쓰고 읽기 편한 편집 환경에 가깝게 다룸
    • Org 사용자에게 익숙한 헤딩 이동, 접기, 구조 요소 이동 방식을 제공함
    • fenced code block은 평면 고정폭 텍스트가 아니라 해당 언어의 실제 major mode로 font-locking됨
    • Emacs Lisp 블록과 다른 내장 모드도 실제 구문 강조를 받을 수 있음
    • 코드 블록 편집 명령도 상당 부분 동작하지만, 블록 안 완성 기능은 아직 거친 부분이 남아 있음
    • 이미지 링크는 버퍼 안에 인라인으로 렌더링됨
  • 아직 auto-mode-alist에 연결되지 않아 .md 파일을 자동으로 가져가지 않음
    • M-x load-library RET markdown-ts-mode로 라이브러리를 로드한 뒤 버퍼에서 켤 수 있음
    • 직접 auto-mode-alist에 추가하는 방식도 가능함
  • 피드백은 bug list에 M-x report-emacs-bug로 보낼 수 있음
  • 추가 스크린샷은 markdown-ts-mode-lab demo에 있음

Eglot, Eldoc, completion 개선

  • Eglot은 Emacs 31에서 LSP 문서를 markdown-ts-view-mode로 렌더링할 수 있음
    • eglot-documentation-renderer 'markdown-ts-view-mode
    • formatted hover docs를 외부 패키지 없이 볼 수 있음
    • 이 기능은 markdown-ts-mode에 의존하므로 마찬가지로 실험적임
  • eglot-code-action-indications로 새 inline code action 힌트를 끌 수 있음
    • 일부 language server에서는 힌트가 시끄럽게 느껴질 수 있음
  • eglot-events-buffer-size는 eglot-events-buffer-config로 대체되는 중임
  • eldoc-help-at-pt t는 커서 아래 항목의 도움말을 별도 호출 없이 보여줌
    • eldoc-echo-area-prefer-doc-buffer와 함께 쓰면 낯선 코드를 탐색할 때 안내가 늘어남
  • completion 관련 새 설정은 입력 중 UI를 더 적극적으로 갱신함
    • completion-eager-update t
    • completion-eager-display 'auto
    • minibuffer-visible-completions 'up-down
  • completion-eager-update와 completion-eager-display는 사용자가 요청하기 전에도 입력에 맞춰 completion UI를 갱신함
  • minibuffer-visible-completions를 'up-down으로 설정하면 보이는 후보를 화살표 키로 이동할 수 있음
  • icomplete에는 bug#75784 패치가 포함돼 vertical in-buffer 동작과 prefix indicator가 들어감
    • icomplete-vertical-in-buffer-adjust-list
    • icomplete-vertical-render-prefix-indicator

창 배치와 Speedbar

  • Emacs 31에는 창을 직접 다시 쪼개고 닫지 않아도 배치를 바꾸는 명령들이 추가됨
    • window-layout-transpose
    • window-layout-rotate-clockwise
    • window-layout-flip-leftright
    • window-layout-flip-topdown
  • transpose는 가로·세로 배열을 바꾸고, rotate는 전체 레이아웃을 회전시키며, flip 명령은 좌우 또는 상하로 미러링함
  • 버퍼를 유지한 채 3창 구성에서 편집기 창 위치만 바꾸고 싶을 때 유용함
  • Speedbar는 Emacs 31에서 별도 frame 대신 side window 안에 배치될 수 있음
    • speedbar-window-default-width
    • speedbar-window-max-width
    • speedbar-window
  • speedbar-window는 Speedbar를 현대적인 파일 트리처럼 옆에 dock함
  • tiling 환경이나 단일 모니터 노트북에서는 기존 floating frame보다 side window 방식이 더 잘 맞음

VC와 editable xref

  • VC에는 일상적인 버전 관리 흐름을 줄여주는 설정들이 들어감
    • vc-auto-revert-mode t
    • vc-allow-rewriting-published-history t
    • vc-dir-auto-hide-up-to-date 'revert
  • vc-dir-auto-hide-up-to-date는 vc-dir 버퍼를 새로고침할 때 최신 상태 파일을 자동으로 숨김
    • 기존에 vc-dir-refresh 뒤 vc-dir-hide-up-to-date를 호출하던 키 해킹을 삭제할 수 있음
  • vc-allow-rewriting-published-history는 Jujutsu나 feature branch force-push처럼 이미 push된 히스토리를 의도적으로 다시 쓰는 흐름에 맞음
  • Emacs 31에는 editable xref buffer가 들어감
    • 기존 xref 버퍼는 r의 xref-query-replace-in-results만 있었고 정규식 기반 치환에 한정됐음
    • Dired의 wdired-mode나 grep 버퍼의 grep-edit-mode처럼 결과 버퍼를 직접 편집하는 흐름이 xref에는 없었음
  • 처음 제안은 xref-export-to-grep로 xref 결과를 file:line:content 형태의 grep-mode 버퍼로 내보낸 뒤 편집하는 방식이었음
  • xref 유지관리자인 Dmitry Gutov가 grep 버퍼로 우회하는 UI 대신 xref 버퍼 inline 편집을 제안했고, 이후 xref-edit-mode가 작성돼 들어감
  • xref-edit-mode는 추가 버퍼 이동을 없애고 큰 xref 버퍼에서도 더 빠르게 동작함
  • 사용 흐름은 C-x p g로 검색한 뒤 *xref* 버퍼에서 e로 편집 모드를 시작하고, 수정 후 C-c C-c로 확정하는 방식임
  • 관련 논의는 bug#80616에 공개돼 있음

ERC와 작은 품질 개선들

  • ERC는 erc-log-insert-log-on-open 'erc-log-new-target-buffer-p로 새 target buffer를 열 때만 이전 로그를 삽입할 수 있음
  • Emacs 31에서는 ERC의 scrolltobottom 모듈이 더 이상 erc-fill-wrap에 의존하지 않아, 이전 버전용 조건부 설정을 제거할 수 있음
  • 작은 설정값들도 사용성 개선에 기여함
    • delete-pair-push-mark t: delete-pair 뒤 mark를 push해 C-x C-x로 내부를 선택할 수 있음
    • ibuffer-human-readable-size t: raw byte 대신 KB/MB 표시를 사용함
    • ielm-history-file-name: IELM 입력 히스토리를 재시작 후에도 유지함
    • kill-region-dwim 'emacs-word: 활성 region이 없을 때 C-w가 오류 대신 뒤쪽 단어를 kill함
    • native-comp-async-on-battery-power nil: 배터리 사용 중 백그라운드 native compilation을 멈춤
    • view-lossage-auto-refresh t: C-h l이 최근 키 입력을 실시간 갱신함
    • display-fill-column-indicator-warning nil
    • dired-hide-details-hide-absolute-location t: dired-hide-details-mode에서 절대 디렉터리 경로를 숨김
    • world-clock-sort-order "%FT%T": world clock 정렬을 조정함
    • zone-all-frames t
    • zone-all-windows-in-frame t
    • uniquify-after-kill-buffer-flag t: 기존 -p 변형에서 이름이 바뀜
  • kill-region-dwim은 C-w에서 “the mark is not active” 오류를 피하게 해줌
  • view-lossage-auto-refresh는 화면 공유나 교육 중 키 입력을 실시간으로 보여주는 데 유용함
  • native-comp-async-on-battery-power nil은 전원 연결 없이 이동 중일 때 백그라운드 컴파일로 팬이 도는 상황을 줄임
  • tty-tip-mode는 -nw로 실행하는 Emacs에서도 tooltips를 제공함

term, Modus 테마, master를 쓰는 이유

  • Emacs 31은 term과 ansi-term에서 줄이 삼켜지거나 화면이 깨지는 문제를 고침
    • htop, nethack, curses 기반 프로그램처럼 커서 주소 지정과 전체 화면 redraw를 쓰는 프로그램이 Emacs 터미널 안에서 제대로 redraw됨
    • 외부 터미널 에뮬레이터를 열어야 했던 이유 하나가 줄어듦
  • Emacs에는 Protesilaos의 Modus 5 테마들이 포함됨
    • modus-operandi-deuteranopia: 흰 배경의 deuteranopia 최적화 테마
    • modus-operandi: 흰 배경의 가독성 높은 테마
    • modus-operandi-tinted: 밝은 황토색 배경의 가독성 높은 테마
    • modus-operandi-tritanopia: 흰 배경의 tritanopia 최적화 테마
    • modus-vivendi-deuteranopia: 검은 배경의 deuteranopia 최적화 테마
    • modus-vivendi: 검은 배경의 가독성 높은 테마
    • modus-vivendi-tinted: 밤하늘 배경의 가독성 높은 테마
    • modus-vivendi-tritanopia: 검은 배경의 tritanopia 최적화 테마
  • unreleased Emacs를 매일 쓰는 이유는 코어에 무엇이 들어오는지 직접 확인하고, 릴리스마다 직접 만든 glue code가 줄어드는 과정을 보기 위해서임
  • 이미 들어 있는 기능을 다룬 짝이 되는 글로 Even More Batteries Included with Emacs를 함께 볼 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “아직도 Emacs 쓰는 사람이 있나?”라면, 34년째 쓰고 있고 바꿀 계획도 없음
    Emacs의 커서 이동 키 조합은 GNU readline을 쓰거나 일부를 직접 구현한 다른 곳에서도 꽤 널리 지원됨
    셸뿐 아니라 Chromium/Chrome/Safari 같은 브라우저 입력창, 주소창, 텍스트 영역, Cisco IOS, Juniper Junos, Netscreen 로드 밸런서 등에서도 잘 동작해서 CLI에서 손을 방향키로 옮기는 것보다 훨씬 편하고 빠름
    다만 Firefox와 파생 브라우저에서는 더 이상 안 되는 게 유일한 불만이고, 예전에는 됐는데 어떤 재작성 과정에서 왜 빠졌는지 모르겠음

    • “아직도 Emacs 쓰는 사람이 있나?”라면, 텍스트 편집기에서 원하는 텍스트 관련 작업의 다양성을 감당할 수 있는 건 Emacs밖에 없음
      HN과 Reddit을 Emacs에서 읽고, 스레드에 공유된 링크 전체를 빠르게 검색할 수 있음
      Jira와 Slack도 Emacs의 org-mode에서 읽고, 관련 내용을 찾거나 노트로 추출하기 훨씬 좋음
      글쓰기도 전부 Emacs에서 하며 맞춤법 검사, 동의어 사전, 어원·정의 조회, 번역, LLM 연동을 갖췄고, 모든 노트는 Org에 Zettelkasten 방식으로 둠
      간격 반복 카드도 Org-mode 안에 있어 별도 시스템이 필요 없고, 선택한 노트에서 특정 주제 학습용 카드를 생성할 수 있음
      AI 세션도 모두 Emacs 안에서 돌리며, 어디서든 거의 모든 텍스트를 LLM에 보낼 수 있다는 점이 놀라움
      YouTube 영상도 재생 제어를 직접 해서 일시정지, 되감기, 배속, 음소거, 자막 추출이 가능하고, 보면서 노트할 때 필수적임
      이메일 클라이언트와 Telegram 클라이언트도 Emacs 안에 있고, 웹페이지에서 동영상을 뽑아 페이지 링크 없이 바로 보낼 수 있음
      화면 일부를 잘라 OCR로 텍스트를 추출하면 Emacs 버퍼에 뜨고, Google, DuckDuckGo, Brave, HN Algolia, Wikipedia, 브라우저 기록 검색까지 Emacs에서 함
      브라우저 탭 제어, 탭 전환, 페이지 내 줄 찾기, 링크 이동, PDF 읽기와 주석 달기도 가능하며, 프로그래밍 관련 기능은 아직 꺼내지도 않았음
      20년 뒤에도 살아 있고 컴퓨터를 쓴다면 답은 “그럼, 뭘 쓰겠어?”일 것 같음
    • 왜 사람들이 “아직도 Emacs 쓰는 사람이 있나?”에 답하는지 궁금함
      이 문장은 글 어디에도 안 보임
    • 거의 40년째 쓰고 있음
      macOS 입력창도 셸과 브라우저뿐 아니라 Mail, Evernote 등에서 기본 Emacs 커서 이동 키 바인딩을 지원함
    • 나는 26년째 쓰는 중이고, Emacs는 지금도 쓰는 소프트웨어 중 가장 오래된 것 같음
      2000년에 SGI Irix에서 시작했고, HP-UX, Solaris, Windows, MacOS, 온갖 Linux에서도 써왔음
      MacOS에서도 많은 키 조합이 동작해서 업무용 Mac 노트북을 받았을 때 기분 좋은 놀라움이었음

  • “아직도 Emacs 쓰는 사람이 있나?”라면, 그렇다
    한때 Emacs보다 VSCode의 AI 연동이 나아서 잠깐 VSCode 세계에 다녀왔지만, Claude를 Emacs 안에서 잘 돌리게 된 뒤로는 다시 100% Emacs로 돌아옴
    80x24 터미널 시대에 만들어진 오래된 편집기들만큼 화면에 엄청난 양의 코드를 한꺼번에 유용하게 띄우는 도구가 없음
    표준 와이드 모니터에서 Emacs 세로 창 3개를 띄우고, 각 창을 종종 두 프레임으로 나눠 최대 6개 문맥을 동시에 유지할 수 있음
    IDE를 싫어하진 않지만, 실제로 코드 편집기만큼 쓰지 않는 요소들이 화면을 너무 많이 차지함
    10년 전쯤에는 Emacs의 장기 전망이 다소 걱정됐고 주요 릴리스 노트를 봐도 별로 설레지 않았는데, tree-sitter 즈음부터 프로젝트가 다시 활기를 얻은 것 같음
    언어별 커뮤니티가 각자 모드를 유지하는 대신, 더 일반적으로 유용한 도구에 힘을 모을 수 있게 되면 더 적은 화살에 더 많은 나무를 실을 수 있음
    이제는 주요 릴리스가 더 기대되고, Claude 연동에서 터미널 문제가 아직 거슬리긴 하지만 멈출 정도는 아님
    Emacs 팬에게는 도발적으로 들릴 수 있지만, Emacs가 이제 다른 도구를 더 잘 따라잡고 있고 다시 “진지하게 고려할 만한 파워툴 편집기”로 추천하기 쉬워지고 있음
    AI가 내게는 IDE 도구의 많은 부분을 먹어치웠고, Emacs의 텍스트 박스에도 다른 어디서나처럼 입력할 수 있음
    디버거를 쓸 때는 아직 가끔 VSCode를 켜지만, 디버깅은 원래 시간을 들이는 작업이라 약간의 오버헤드는 크게 문제 되지 않음

    • 공동 유지보수자라 편향은 있겠지만, 아직 안 써봤다면 Ghostel(https://github.com/dakra/ghostel)을 한번 써보면 좋겠음
      이미 쓰고 있다면 버그를 보고해서 고칠 수 있게 해주면 좋겠음
    • 물론 아직도 씀
      Emacs는 여러 해 동안 안정적인 편집기였고, 여러 언어를 처리했으며, 수많은 IDE가 왔다 사라지는 동안 살아남았음
      최근 사례로는 Cursor 매각도 있음
      Emacs에는 늘 새로운 개선이 있었고, 몇 년 전의 다중 커서 편집부터 최근의 LSP와 tree-sitter까지 이어짐
      지금은 vertico/marginalia/consult/embark 조합에 입문했는데, 문맥 기반 동작을 제공하는 Embark는 진지하게 과소평가된 놀라운 패키지임
    • “화면에 엄청난 양의 코드를 한꺼번에 띄우기”가 대부분의 IDE에 대한 큰 불만임
      모든 창, 보기, 하위 보기가 탭이나 현재 실행 중인 프로그램 표시 같은 것들 때문에 세로·가로 공간을 조금씩 깎아 먹음
      그냥 어두운 화면에 텍스트만 있으면 좋겠음
      Vim을 쓰기 때문에 줄 번호용 세로 공간과 명령 영역용 가로 공간 정도는 허용함
    • Emacs에 대해 자주 듣는 불만은 두 가지임
      첫째, 사용법을 외우는 학습 곡선이 큼
      둘째, 키 조합을 계속 누르다 보니 손목 통증이 생김
      그 외에는 여전히 많은 사람이 쓰고 훌륭하지만, 새 사용자에게는 익히기 어려움
    • 지난 20년 동안 거의 모든 작업에 Emacs를 써왔지만, 클라우드 VM에 원격 SSH로 접속해 코딩할 때는 VSCode로 갈아탔음
      SSH 연결에서는 VSCode의 클라이언트/서버 분리가 더 낫게 느껴졌고, 2년 전 기준 Emacs 대안은 같은 성능 수준이 아니었음
      그쪽에 진전이 있었는지 궁금하고, 타이핑이나 명령 실행 시 지연에 민감해서 일상 도구로 Emacs에 돌아가고 싶음
      원격 연결에서 AI 어시스턴트와 작업해 본 적이 있는지도 궁금함

  • 전부 좋아 보이고 Emacs 31로 올리기가 기다려지지만, 또 그 모든 걸 잊고 지난 20년처럼 똑같은 방식으로 Emacs를 계속 쓸 것 같음

    • 얼마 전 내장 자동완성이 얼마나 발전했는지 다룬 글을 보고 설정을 조금 줄였음
      treesit 관련 기능도 들어오는 걸 보니 한 번 더 설정을 줄여볼 생각임
      네이티브 컴파일이 이렇게 눈에 띄지 않게 된 건 정말 좋음
    • Emacs를 계속 쓰는 입장에서 사람들이 Emacs를 개선하는 건 반가움
      다만 이 글에서 강조한 것들을 내가 실제로 많이 쓸 것 같지는 않음
      고급 자동완성이나 tree-sitter류 기능에는 원래 크게 관심이 없고, 적당한 구문 강조와 들여쓰기 지원이면 충분함
      코딩과 텍스트 편집에는 org-mode, magit, 그리고 이메일용 notmuch 정도만 씀
      1. Emacs 버전을 하나 올림
      2. 이제 Emacs에 포함된 MELPA 패키지를 제거함
      3. 새 버전이 나오면 1번으로 돌아감
    • 정말 맞는 말임
      다만 tree-sitter에는 시간을 투자할 예정임

  • Emacs처럼 텍스트 파일로 극단적으로 설정 가능한 시스템은 현대 LLM에 딱 맞게 만들어진 것 같음
    Emacs 경험이 조금 있지만 학습 곡선이 가팔라 튕겨 나갔다면, 에이전트와 함께 다시 들어가 보길 강력히 추천함
    에이전트는 .emacs/init.el을 설정하고 유지하는 데 정말 잘함

    • 직장에서 Neovim으로 이렇게 하고 있는데 너무 재미있음
      무작위 Neovim 패키지 설정과 시스템 상호작용을 배우기보다 일을 끝내고 싶기 때문에, 난잡한 설정도 스스로 정당화하게 됨
      Claude에게 “leader /로 화면 아래 터미널을 토글하고, leader t로 오른쪽으로 옮기게 해줘”라고 말하면 그대로 해줌
      마음에 든 테마가 있었지만 포커스된 창의 상태줄도 바꾸고 싶었는데 그것도 해줬음
      neo tree가 몇 초씩 멈추는 문제가 있었고, Claude가 사내 도구 체인의 git과 나쁜 상호작용 때문이라는 걸 찾아냈음
      평범한 영어로 맞춤 설정한 나만의 텍스트 편집기가 생긴 셈임
      Neovim식 Lua를 배우고, 패키지를 조사하고, 디버깅하는 데 몇 시간을 쓸 수도 있었지만, 이 방식이 훨씬 빠르게 같은 일을 끝내고 업무로 돌아가게 해줌
      LazyVim 같은 사전 설정 Vim이나 vscode로 돌아가게 만들던 가장 큰 장벽이 사라져서 확실히 추천함
    • 늘 vim/neovim을 써왔지만 Emacs의 org, magit, lisp 같은 기능에 빠졌음
      문제는 설정에 시간을 써야 한다는 점이었음
      spacemacs/doom과 훌륭한 문서가 있어도 새 사용자 입장에서는 Emacs 설정이 여전히 너무 많은 작업이었는데, LLM 덕분에 거의 즉시 가능해짐
      지금은 Emacs와 LLM이 함께 있으니 VSCode는 전혀 손대지 않고, 디버거로 깊게 파야 할 때만 IntelliJ 같은 걸 가끔 켬
    • 프로그래밍 가능한 편집기는 이제 정말 대단함
      LLM이 생각나는 거의 무엇이든 몇 분 안에 만들어줌
      Neovim을 오래 썼지만 예전에는 많이 커스터마이즈하지 않았는데, 이제는 플러그인도 잔뜩 있고 즉흥적으로 새 기능을 추가할 수 있음
      Emacs도 시도해볼까 생각 중인데, 네이티브 GUI가 더 강력할 수 있을 것 같음
    • 현대 LLM은 이런 작업을 어느 정도 해내지만 어이없는 실수도 함
      더 큰 문제는 init.el이 더 이상 자기 것이 아니게 된다는 점임
      LLM이 작성하고 유지하면 안에서 무슨 일이 벌어지는지 모르게 됨
      초기화 파일의 모든 줄을 검토할 거라면 굳이 왜 쓰는지도 애매함
    • 동의함
      옆에 개인 Emacs 컨설턴트가 붙어 있는 느낌이라 놀라움

  • 진지한 작업을 조금이라도 한다면 텍스트 편집기가 필요함
    Emacs는 여전히 최고 중 하나이고, 빠르며, 설정 가능하고, 내 통제 아래 있음
    요청하지 않은 수많은 새 기능으로 텍스트 편집기가 갑자기 “업그레이드”되는 일을 겪지 않음
    전부 선택 적용임

    • 내 설정은 절대 빠르다고 부르기 어렵지만, 네이티브 컴파일 이후로 훨씬 나아졌음
      주요 기능들도 비동기로 바뀌기 시작해서 적어도 더 반응성 있게 느껴짐
    • Windows에서는 엄청 느림
    • 느리고, 비대하며, 절대 필요 없을 “기능”으로 꽉 차 있음
      오직 하나만이 존재함. En garde!
    • 나는 trampoline 기법으로 구현된 네이티브 컴파일을 요청한 적이 없음
      이 방식은 공격자가 알고 있는 홈 디렉터리 위치의 파일을 Emacs가 일상적으로 실행하게 만들어 공격 표면을 넓히고, 디버깅도 어렵게 함
      하지만 Emacs가 Wayland 프로토콜을 말하게 하려면 써야 하고, 실제로 쓰고 싶으니 붙잡혀 있음
      어색하게 덧붙인 lexical scope도 마찬가지임

  • “그냥 동작하는 Tree-sitter”라니 할렐루야임
    이제 dotfiles에서 이런 난잡한 스크립트를 지울 수 있음
    rm -rf ~/.emacs.d/tree-sitter
    mkdir -p ~/.emacs.d/tree-sitter
    set _plat = windows
    if ( \uname` == Linux ) set _plat = linux if ( `uname` == Darwin ) set _plat = apple set _arch = x86 if ( `arch` == arm64) set _arch = aarch64 gh release -R emacs-tree-sitter/tree-sitter-langs download -p "${_arch}${_plat}" tar -C ~/.emacs.d/tree-sitter --transform 's/^(..(so|dylib|dll))/libtree-sitter-\1/' -xzf tree-sitter-grammars*.tar.gz rm tree-sitter-grammars*.tar.gz`
    참고로 이건 csh이고, 건국의 아버지들이 의도한 바로 그 방식임

  • 이런 개선을 보니 반가움
    Emacs에서 늘 성가셨던 점은 현대적인 편집기로 쓰기 위해 필요한 설정이 너무 많다는 것이었음
    Doom Emacs와 Spacemacs가 이 문제를 풀려 하지만 둘 다 vanilla Emacs와는 꽤 멀게 느껴짐
    Emacs가 몇 가지 프리셋을 제공해서 한 줄만으로 서로 다른 출발점으로 바꿀 수 있으면 좋겠음
    예를 들어 대부분의 개발자는 tree-sitter 강조와 LSP가 기본으로 켜지길 원하니 (preset-base-ide-1) 같은 게 있으면, 기능적으로 쓰기 전부터 200줄 설정을 작성할 필요가 없고 훨씬 가까운 출발점에서 시작할 수 있음

    • 이런 댓글은 Emacs 스레드마다 나오는데 도저히 이해가 안 됨
      셸 한 줄이면 사전 설정을 내려받을 수 있고, 그걸 Emacs에 내장한다면 무엇을 넣을지는 누가 결정하나
      모두에게 필요한 사전 설정을 정하는 데 시간을 쓸 가치가 크지 않아 보임
    • 괜한 걱정임
      Doom Emacs와 Spacemacs는 둘 다 아주 좋고, vanilla Emacs에서 멀다는 게 걱정할 문제는 아님
    • 이건 문화적인 면이 있는 것 같음
      제다이가 자기 라이트세이버를 만드는 것과 비슷함
      Emacs/Vim 입문 과정의 일부는 자신에게 맞는 자기 설정을 만드는 것임
      플러그인, 키 바인딩, 색 테마 등을 맞추는 게 재미의 일부임
    • Bedrock, Centaur Emacs, Witchmacs 등도 있음
      Doom과 Spacemacs가 마음에 들지 않아도 선택지는 많음
      다만 사전 설정들은 대체로 “내 영혼처럼 어두운” 식의 테마를 넣어 텍스트를 거의 읽기 어렵게 만드는 문제가 있고, 그건 꽤 성가심
    • 나도 Doom Emacs를 쓰고 있지만 점점 vanilla Emacs로 옮길까 생각 중임
      키 바인딩 차이 때문에 전환 기간이 조금 걱정되지만, 아주 나쁘지는 않을 것 같음

  • Rahul의 글을 읽고 Emacs 31을 소스에서 빌드하고 싶어졌지만, 현실을 깨닫고 릴리스를 기다리기로 했음
    그의 Emacs 설정 글들도 좋아함
    다른 개발자가 어떤 도구를 쓰든 신경 쓰지 않지만, 1월에 내 개발용 Mac 두 대를 “VSCode free”로 만들고 모든 작업에 Emacs를 쓰고 있음
    기분이 더 좋음
    수십 년 동안 Emacs 설정을 실험하느라 엄청난 시간을 썼지만, 최근 몇 년은 더 기본에 가까운 경험으로 옮겨가고 있음
    Emacs Lisp로 직접 에이전트형 코딩 플랫폼을 만들긴 했지만, .emacs와 .emacs.d와는 분리해 둠

  • 내가 많은 걸 놓쳤다는 걸 깨달음
    2000년대 초 이후 .emacs를 의미 있게 건드리지 않은 사람들을 위한 Emacs 가이드가 있으면 좋겠음

    • Mastering Emacs 블로그의 상당 부분은 이제 10년쯤 됐지만, 그 철학과 정보는 최신 상태로 따라잡고 싶은 고참에게 여전히 매우 유용함
    • 나는 꽤 보수적인 Emacs 사용자임
      Windows, Ubuntu, macOS를 매일 모두 쓰기 때문에, 세 환경에서 일관되게 돌아가게 만지작거리는 데 시간을 쓰고 싶지 않음
      가장 “현대적인” 도입은 아마 여러 언어 모드, 특히 golang과 rust에서 lsp와 eglot을 쓰는 정도임
      여기에 tree-sitter도 추가하는 걸 고려해야 할까?
    • 인터넷에는 Emacs 정보가 많고, 에이전트는 그 자료들로 학습돼 있음
    • 이미 내장돼 있음
      C-h n view-emacs-news

  • 와, tree-sitter 문법 자동 설치, 편집 가능한 xref, 창 레이아웃 전치, 프레임 안 사이드 창으로 speed bar 표시까지 다 들어온다니 몰랐음
    지난 몇 주 동안 “이게 기본 지원되면 멋지겠다”고 스쳐 생각했던 것들이라, 어떤 꿈은 정말 이뤄짐

답변달기
GN⁺   [-]
Lobste.rs 의견들

  • tree-sitter 변경이 정말 기대됨. 설정 과정이 늘 꽤 어색하다고 느꼈음
    eager complete도 궁금함. icomplete와 fido-mode는 원하는 것에 꽤 가까운데, 아직 corfu 같은 서드파티 패키지만큼 쓰기 편하진 않음

    • 언젠가는 vertico 등에 가까운 경험을 내장 기능만으로, 그것도 기본 활성화 상태로 얻을 수 있으면 좋겠음
      몇 가지 조정과 내장 기능만 켜도 사용성이 크게 달라지는데, bedrock이나 emacs-solo가 그런 식으로 구성됨
    • Emacs 32를 매일 쓰고 있는데, treesit이 그냥 동작한다고 하긴 어려움
      Emacs를 시작할 때마다 빠진 dylib에 대한 큰 메시지가 매번 뜸

  • 예시의 (treesit-auto-install-grammar t)와 (treesit-enabled-modes t) 문법은 함수 호출처럼 보이지만 실제로는 설정해야 하는 옵션임
    다음 릴리스에서 마음에 드는 작은 변화들도 있음: minibuffer-nonselected-mode가 기본으로 켜져 미니버퍼에 미완료 작업이 남았는지 더 잘 보이고, diff-mode의 diff-delete-other-hunks는 Emacs 29에서 도입된 diff 버퍼의 VC 동작과 함께 쓰면 매우 유용함
    with-work-buffer는 with-temp-buffer와 비슷하지만 버퍼 풀을 재사용함. 개인 설정에서 우연히 같은 버퍼 이름 규칙인 *work*를 쓰다가 알게 됨
    Emacs 31에는 lua-mode가 포함되어 더 이상 따로 설치하지 않아도 됨
    다시 원하는 방식으로 정확히 동작하게 하려고 몇 가지 조정도 필요했음: xterm-mouse-mode가 기본 활성화라 명시적으로 끄고, mode-line face가 어두운 테마에 맞춰 바뀌지만 예전 기본 색상에 익숙해서 되돌렸음
    Emacs 31은 소스 파일에 lexical-binding 쿠키가 없으면 경고함. 거슬리면 끌 수 있고, elisp-enable-lexical-binding 명령으로 쉽게 고칠 수 있으며, lexical-binding을 전역 기본값으로 만드는 것도 가능함
    새 버그만 없다면 늘 그렇듯 탄탄한 릴리스가 될 것 같음

    • 이 예시는 아마 use-package의 :custom 목록에서 복사한 듯함
      그래서 :custom에 대해 애매하게 느껴짐. 값을 실험하거나 공유하려고 할 때 더 번거로움
    • with-work-buffer는 성능 목적인가? 문서에는 with-temp-buffer 대신 왜 써야 하는지가 아니라, 더 조심해야 한다는 말만 있음
    • 이 경고는 어떻게 끄는지 궁금함. 이상적으로는 elpa 안의 파일은 경고하지 않고 내 파일에 대해서만 경고할 수 있으면 좋겠음
      또 내 Emacs의 경고 68개 중 64개가 생성 파일인 -autoloads.el에서 나옴. 이건 elpa/melpa 쪽 생성 도구에서 고쳐야 할 듯함

  • 드디어 편집 가능한 xref를 바라던 참이었는데, 이건 내 생활을 훨씬 편하게 만들어 줄 것 같음
    매일 만지는 것들에 놀랄 만큼 많이 닿는 훌륭한 변경이 많음

  • Nvim이 기본값을 vim 정규식에서 treesitter로 바꿨다가 내 글쓰기 환경이 깨졌음
    treesitter는 Markdown 안의 HTML 주석을 파싱하려면 설정이 좀 필요했고, 조각을 맞춘 뒤에도 동작하지 않았음
    결국 treesitter를 꺼서 해결함
    에디터 같은 기본 인프라에는 매우 보수적인 편임. 에디터 변경은 대부분 몇 년 동안 문제없이 해오던 무언가를 깨뜨림

    • 다행히 Emacs는 기본값을 treesitter로 바꾸는 게 아니라, 여전히 전부 선택적 활성화임
답변달기