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

> Clean Markdown view of GeekNews topic #30618. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30618](https://news.hada.io/topic?id=30618)
- GeekNews Markdown: [https://news.hada.io/topic/30618.md](https://news.hada.io/topic/30618.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-19T09:06:12+09:00
- Updated: 2026-06-19T09:06:12+09:00
- Original source: [rahuljuliato.com](https://rahuljuliato.com/posts/emacs-31-around-the-corner)
- Points: 1
- Comments: 2

## Topic Body

- 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](https://github.com/LionyxML/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](https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs)에 `M-x report-emacs-bug`로 보낼 수 있음
- 추가 스크린샷은 [markdown-ts-mode-lab demo](https://github.com/LionyxML/markdown-ts-mode-lab/tree/main/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](https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-03/msg02638.html) 패치가 포함돼 **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](https://debbugs.gnu.org/cgi/bugreport.cgi?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](https://karthinks.com/software/even-more-batteries-included-with-emacs/)를 함께 볼 수 있음

## Comments



### Comment 59929

- Author: neo
- Created: 2026-06-19T13:41:15+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48584135) 
- “아직도 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](<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 표시까지 다 들어온다니 몰랐음  
  지난 몇 주 동안 “이게 기본 지원되면 멋지겠다”고 스쳐 생각했던 것들이라, 어떤 꿈은 정말 이뤄짐

### Comment 59907

- Author: neo
- Created: 2026-06-19T09:06:14+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/b0mp2e/changes_emacs_31_i_m_already_daily_driving) 
- **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로 바꾸는 게 아니라, 여전히 전부 **선택적 활성화**임