Emacs 윈도우 관리 백과사전

 (karthinks.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Emacs의 윈도우 관리는 버퍼와 윈도우가 분리된 유연한 구조 위에 다소 투박한 기본 조작이 얹혀 있어, 사용자가 도구와 습관을 조합해 작업 흐름을 만들어야 함
  • 글의 초점은 display-buffer 규칙이나 탭 기반 워크스페이스가 아니라, 한 Emacs 프레임 안에서 포커스 이동, 버퍼 배치, 분할·삭제, 임시 작업을 다루는 수동 조작에 맞춰져 있음
  • other-window, windmove, winum, ace-window, 마우스, transpose-frame, window-prefix-map, other-window-prefix, winner-mode가 순환 이동·방향 이동·번호 선택·힌트 선택·레이아웃 변환·복구를 나눠 맡음
  • ace-window와 Avy를 활용하면 특정 윈도우를 고른 뒤 명령을 실행하거나, 텍스트 위치로 바로 점프해 윈도우 전환 자체를 줄일 수 있음
  • Emacs 윈도우 관리는 복잡한 고정 체계라기보다 열려 있는 문제에 가까우며, display-buffer-alist, Popper·Popwin, 윈도우 트리 조작, 타일링 WM 통합은 강력한 만큼 설정 비용과 빈틈도 큼

Emacs에서 말하는 윈도우 관리

  • Emacs의 윈도우(window) 는 프레임 안의 뷰포트나 패널이고, 버퍼(buffer) 는 파일 내용일 수도 있고 아닐 수도 있는 연속된 텍스트 덩어리임
  • 많은 IDE와 편집기는 윈도우와 버퍼 개념을 사실상 합쳐 인지 부담을 낮추지만, Emacs는 둘을 분리해 더 유연한 배치를 가능하게 함
    • 같은 파일을 두 번 보는 일이 간단함
    • 파일과 직접 대응하지 않는 버퍼도 자연스럽게 다룰 수 있음
    • Emacs의 indirect buffers는 버퍼 전체의 “라이브” 복사에 가까움
  • 이 분리 구조는 새 사용자에게 비용을 줌
    • 프레임 안에서 윈도우를 원하는 위치에 놓아야 함
    • 원하는 버퍼를 원하는 윈도우에 넣어야 함
    • 초반에는 분리 구조가 주는 장점보다 조작 부담이 먼저 드러남

이 글이 다루지 않는 영역

  • display-buffer를 완전히 제어하는 자동 버퍼 표시 규칙은 중심 주제가 아님
  • 탭, 워크스페이스, 버퍼 격리, 세션 지속성도 핵심 범위 밖임
  • Emacs 안에서 별도 윈도우 매니저처럼 동작하는 급진적 대안도 본문 밖에 둠
    • Edwina는 DWM 스타일의 master-and-stack 자동 타일링 레이아웃을 강제함
    • HyControl은 윈도우 레이아웃 액션 제어판과 균등 그리드 표시 기능 등을 제공함
  • 실제 초점은 수동적이고 일상적인 조작임
    • 윈도우 포커스 전환
    • 윈도우 사이 버퍼 이동
    • 윈도우 분할과 삭제
    • 명령 실행 중 표시 대상 윈도우 제어

기본 이동: other-window와 “다음 윈도우”

  • other-window는 Emacs 튜토리얼에서 배우는 기본 윈도우 전환 명령이며, 기본 키는 C-x o임
  • 선택 순서는 대체로 프레임 안에서 시계 방향으로 순환함
    • 윈도우가 적을 때는 단순하고 충분히 쓸 만함
    • 윈도우가 많아질수록 원하는 위치까지 여러 번 호출해야 함
  • 실용적인 조정 방법도 있음
    • M-o처럼 더 누르기 쉬운 키에 바인딩할 수 있음
    • 숫자 인자로 여러 칸 건너뛰거나 역방향으로 이동할 수 있음
    • repeat-mode를 켜면 C-x o o o... 또는 M-o o o...처럼 반복 입력이 가능함
  • no-other-window 윈도우 파라미터를 설정하면 other-window가 특정 윈도우를 건너뜀
    • dired-sidebar나 dirvish-side 같은 파일 매니저형 사이드 윈도우가 other-window 대상에서 빠지는 이유가 여기에 해당함
  • “다음 윈도우” 개념은 scroll-other-window처럼 다른 윈도우에 작용하는 명령의 기본 대상이기도 함

방향 기반 이동: windmove

  • windmove는 방향을 기준으로 윈도우 포커스를 이동하는 내장 라이브러리임
    • Vim 사용자가 기대하는 좌·우·상·하 이동에 가까움
    • evil-mode 사용자도 내부적으로 Windmove를 쓰고 있음
  • windmove-left, windmove-right, windmove-up, windmove-down을 WASD, HJKL, 방향키 등에 묶어 사용할 수 있음
  • windmove-swap-states-left/right/up/down 명령은 방향을 기준으로 윈도우의 버퍼를 교환함
    • 이때 포커스는 버퍼와 함께 이동함
  • windmove-delete-* 계열로 특정 방향의 윈도우를 삭제할 수도 있지만, 본문은 아래에서 다른 방법들을 더 다룸
  • 타일링 WM 환경에서는 Emacs 내부 윈도우와 OS 윈도우 사이를 같은 키로 이동하도록 통합할 수 있음

Emacs 윈도우를 OS 윈도우로 맡기기

  • frames-only-mode는 모든 버퍼를 Emacs 윈도우가 아니라 새 프레임으로 열어 OS 윈도우 매니저가 관리하게 함
  • 이 방식은 Emacs 버퍼를 OS 윈도우와 같은 층위에서 다루게 해, 같은 키로 양쪽을 관리할 수 있게 함
  • Avy, winum, ace-window, scroll-other-window 같은 도구는 윈도우뿐 아니라 프레임 전체에도 적용될 수 있음
  • 일부 Emacs 명령은 프레임을 마음대로 분할할 수 있다고 가정하므로 예외 상황이 생길 수 있음
    • 특히 org-mode 명령에서 그런 경향이 있음
  • Wayland 컴포지터에서 frames-only-mode를 써 본 경험은 없음

번호와 힌트로 즉시 선택하기

  • winum은 모드라인에 윈도우 번호를 표시하고, 번호로 윈도우를 선택하게 함
    • other-window가 O(n)에 가깝고 windmove가 공간 배치에 기대는 방식이라면, winum은 번호를 알 때 O(1) 접근에 가까움
    • 음수 prefix 인자로 선택 명령을 호출하면 해당 윈도우를 삭제함
    • 미니버퍼가 활성화되면 항상 0번을 받음
    • Emacs 프레임을 가로질러 동작함
  • 기본 키 C-x w <n>은 길 수 있어, M-0부터 M-9까지를 윈도우 선택에 쓰는 설정 예시가 있음
  • ace-window는 키보드 기반 Emacs 윈도우 제어의 강력한 도구로 다뤄짐
    • 각 윈도우 위에 힌트를 표시하고, 해당 키를 눌러 선택함
    • ace-window-display-mode를 켜면 winum처럼 힌트를 모드라인에 계속 표시할 수 있음
    • ?를 누르면 dispatch 메뉴가 열림
  • ace-window의 강점은 단순 선택보다 윈도우를 고른 뒤 액션을 실행하는 데 있음
    • 윈도우 삭제
    • 윈도우 이동과 교환
    • 윈도우 분할
    • 특정 버퍼 표시
    • 선택된 윈도우에서 벗어나지 않고 다른 윈도우에 작업 적용

마우스와 레이아웃 변환

  • Emacs에서 마우스는 윈도우 선택, 크기 조절, 컨텍스트 메뉴, 드래그 앤 드롭에 자연스럽게 맞음
    • context-menu-mode와 메뉴바는 발견 가능성을 높임
  • 이미 손이 키보드에서 떨어져 있다면 마우스로 Emacs를 조작하는 것이 가장 저항이 적은 경로가 될 수 있음
  • 마우스 제스처로 할 수 있는 작업도 있음
    • 프레임의 수직·수평 분할
    • 윈도우 삭제
    • 윈도우 안의 버퍼 순환
    • 오른쪽·왼쪽으로 윈도우 교환
    • 한 윈도우에서 마지막 두 버퍼 토글
  • mouse-autoselect-window를 설정하면 focus-follows-mouse 동작을 켤 수 있음
  • transpose-frame은 프레임의 윈도우 레이아웃을 회전하거나 뒤집는 명령을 제공함
    • rotate-frame, flip-frame, flop-frame이 자주 쓸 만한 명령으로 꼽힘
    • transpose-frame 자체는 주대각선 기준 전치라 실제 활용도가 낮다고 평가됨

window-prefix-map과 윈도우 트리

  • window-prefix-map은 Emacs 기본 키 C-x w에 묶인 윈도우 관리 명령 모음임
  • split-root-window-right와 split-root-window-below는 프레임의 루트 윈도우를 나눔
    • 각각 C-x w 3, C-x w 2에 바인딩됨
    • 일반 분할 명령이 현재 윈도우를 더 쪼개는 것과 달리, 별도 작업 공간을 만들 때 유용함
  • Emacs의 윈도우들은 트리 구조로 배치됨
    • 실제 윈도우는 leaf 노드임
    • 분할은 leaf를 두 윈도우의 부모 노드로 바꿈
    • i3나 bspwm 같은 수동 타일링 윈도우 매니저의 배치와 비슷함
  • tab-window-detach와 tear-off-window는 현재 윈도우를 새 탭이나 새 프레임으로 옮김
    • 기본 키는 각각 C-x w ^ t, C-x w ^ f로 길다고 평가됨
    • ace-window dispatch 액션이나 마우스 바인딩으로 대체할 수 있음

other-window-prefix: 다음 명령의 표시 위치 바꾸기

  • other-window-prefix는 C-x 4 4에 묶인 내장 명령이며, 다음 명령이 표시하는 버퍼를 다음 윈도우에 보이게 함
  • 이 명령은 파일 열기, 버퍼 전환, 북마크 점프처럼 버퍼를 표시하는 명령과 표시 대상 윈도우 선택을 분리함
    • find-file-other-window, find-file-other-tab, find-file-other-frame 같은 명령군을 매번 외울 필요가 줄어듦
    • find-file, find-file-read-only, switch-to-buffer 같은 기본 명령 앞에 prefix를 붙여 표시 위치만 바꿀 수 있음
  • Forge 예시에서는 이슈 목록에서 RET을 눌렀을 때 현재 윈도우가 덮이는 문제를 other-window-prefix로 피할 수 있음
  • Magit, Org mode, Notmuch, Elfeed, EWW처럼 패키지마다 “다른 윈도우에 열기” 방식이 다를 때도 균일한 동작을 제공함
  • 관련 prefix도 있음
    • same-window-prefix는 다음 명령의 버퍼를 현재 윈도우에 강제함
    • other-frame-prefix는 새 프레임에 열게 함
    • other-tab-prefix는 새 탭에 열게 함

윈도우 구성 저장과 되돌리기

  • window-configuration-to-register는 현재 윈도우 구성을 레지스터에 저장하는 기본 명령이며, 기본 키는 C-x r w임
  • jump-to-register는 저장된 구성을 복원하며, 기본 키는 C-x r j임
  • Elisp 수준에서는 current-window-configuration 결과를 변수에 저장하고 set-window-configuration으로 적용할 수 있음
    • prin1, persist, multisession 같은 방식으로 디스크에 저장하면 세션 간 복원 기능의 씨앗이 됨
    • 다만 각 윈도우의 커서 위치까지 복원되는 점은 보통 원하지 않는 동작일 수 있음
  • 자동으로 과거 구성을 쌓아 두는 “oops” 옵션도 있음
    • winner-mode: 탭을 쓰지 않을 때 winner-undo, winner-redo로 윈도우 구성 변경을 되돌리거나 다시 적용함
    • tab-bar-history-mode: 탭마다 별도 히스토리 스택을 제공함
    • undelete-frame-mode와 tab-undo: 실수로 닫은 프레임이나 탭을 복구함
  • winner-undo를 Emacs가 엉뚱한 곳에 버퍼를 띄운 뒤 매번 수습하는 용도로 쓰는 것은 임시방편에 가까움
    • 근본 문제는 버퍼 표시 규칙이 원하는 대로 잡히지 않은 것임

자주 오가는 두 윈도우에 최적화하기

  • 실제 작업에서는 화면에 여러 윈도우가 있어도 대부분 두 윈도우 사이를 자주 오감
    • Code & REPL
    • Code & Grep
    • Prose & Notes
    • Listing & Item
  • 다른 윈도우들은 문서, 디버그 정보, 로그, 명령 출력, 목차, 파일 탐색기, 미리보기처럼 자주 보지만 거의 전환하지 않는 참고 영역일 수 있음
  • get-mru-window를 사용해 가장 최근 사용한 윈도우로 전환하는 other-window-mru 예시가 있음
    • 두 번째 윈도우를 마우스, ace-window, winum 등 어떤 방식으로 골라도 이후에는 빠르게 왕복할 수 있음
  • other-window 자체를 개선하는 방식도 있음
    • 윈도우가 하나뿐이면 자동으로 분할하게 만들기
    • switchy-window처럼 최근 사용 순서로 순환하기
    • other-window-alternating처럼 연속 호출이 아닐 때마다 방향을 반전해 두 윈도우 왕복을 자연스럽게 만들기

ace-window를 명령 실행 기반으로 확장하기

  • ace-window는 aw-select를 통해 특정 윈도우를 고르는 선택 단계만 따로 사용할 수 있음
  • aw-select가 반환한 윈도우를 대상으로 원하는 작업을 수행하면, “윈도우 선택 → 작업 실행 → 원래 윈도우 유지” 패턴을 만들 수 있음
  • 예시 명령은 다음과 같음
    • ace-tear-off-window: ace-window로 고른 윈도우를 새 프레임으로 떼어냄
    • ace-tab-window-detach: 고른 윈도우를 새 탭으로 이동함
  • ace-window-one-command는 선택한 윈도우에서 임의의 단일 명령을 실행하게 함
    • 먼저 ace-window로 윈도우를 고름
    • 키 시퀀스를 읽어 해당 명령을 실행함
    • 원래 선택 윈도우를 바꾸지 않고 다른 윈도우에 작업을 적용할 수 있음
  • ace-window-prefix는 other-window-prefix의 더 직접적인 버전처럼 동작함
    • 다음 명령이 표시할 버퍼의 대상 윈도우를 ace-window로 직접 선택함
    • 필요하면 ace-window 액션으로 새 윈도우를 즉석에서 만들고 그곳에 표시할 수 있음
    • 제안된 키 바인딩은 C-x 4 o임

윈도우를 꼭 전환해야 하는가

  • 윈도우 전환의 목적은 크게 두 가지로 나뉨
    • Switch and stay: 목적지 윈도우에서 계속 편집하거나 작업함
    • Switch and return: 잠깐 스크롤, 검색, 복사, 삭제 같은 일을 하고 원래 위치로 돌아옴
  • 첫 번째 경우 Avy가 윈도우 전환과 커서 이동을 하나로 합칠 수 있음
    • avy-goto-char-timer는 화면에 보이는 여러 Emacs 윈도우와 프레임을 하나의 점프 후보 풀처럼 다룸
    • 특정 문자열이나 문자 위치로 점프하면서 자동으로 윈도우도 바뀜
    • Avy가 윈도우와 프레임을 가로지르지 않으면 avy-all-windows 설정을 확인해야 함
  • pop-global-mark는 이전 위치로 돌아가는 수단이며, 필요하면 윈도우 전환도 함께 일어날 수 있음
    • 기본적으로는 현재 윈도우에서 버퍼를 전환하므로, pop-to-buffer를 사용하게 하는 advice가 있음
  • 두 번째 경우에는 “전환 → 행동 → 복귀” 흐름을 명령으로 감싸 자동화할 수 있음
    • ace-window-one-command는 범용적인 한 가지 방법임
    • 특정 동작은 전용 명령이나 매크로로 만들 수 있음

다른 윈도우 스크롤·검색·버퍼 전환

  • scroll-other-window와 scroll-other-window-down은 현재 윈도우를 떠나지 않고 다른 윈도우를 스크롤함
    • 기본 대상은 현재 윈도우에서 시계 방향의 “다음 윈도우”임
    • 윈도우가 셋 이상이면 기대한 참고 윈도우가 아니라 다른 윈도우가 스크롤될 수 있음
  • other-window-scroll-default를 설정해 스크롤 대상 선택 규칙을 바꿀 수 있음
    • get-lru-window를 쓰면 가장 덜 최근에 사용한 윈도우를 스크롤함
    • get-mru-window를 쓰면 최근 사용 윈도우를 대상으로 삼을 수 있음
  • other-window-scroll-buffer를 설정하면 특정 버퍼가 표시된 윈도우를 스크롤 대상으로 지정할 수 있음
    • 주로 패키지 작성자에게 유용한 옵션으로 다뤄짐
  • isearch-other-window 예시는 스크롤 대상 윈도우에서 검색을 시작하고, 검색 종료 후 원래 윈도우로 돌아오는 방식임
    • shell과 Man 버퍼를 함께 쓰는 예시가 있음
  • next-buffer, previous-buffer, switch-to-buffer도 prefix 인자와 other-window-for-scrolling을 조합해 다른 윈도우에서 실행하도록 확장할 수 있음
    • repeat-mode용 keymap을 만들면 n, p, b로 다른 윈도우의 버퍼를 연속 순환하거나 선택할 수 있음

master-mode, scroll-all-mode, with-other-window

  • master-mode는 현재 버퍼를 “master”, 다른 버퍼를 “slave”로 지정해 현재 위치를 떠나지 않고 slave 버퍼에 액션을 보낼 수 있음
    • 기본적으로는 위의 other-window-scroll-default 방식보다 덜 투명한 대안으로 평가됨
    • master-says를 통해 slave 버퍼에서 recenter 같은 임의 액션을 수행하는 키를 만들 수 있음
  • scroll-all-mode는 프레임 안 모든 윈도우의 스크롤 동작을 묶음
    • 여러 윈도우 뷰를 동기화해 보고 싶을 때 유용함
  • with-other-window 매크로는 other-window-for-scrolling이 고른 윈도우에서 본문 코드를 실행하는 Elisp 헬퍼임
    • isearch-other-window, isearch-other-window-backwards 같은 명령을 간단히 만들 수 있음
    • 대화형 ace-window-one-command의 Elisp 대응물처럼 쓰임

윈도우 수를 줄이는 전략

  • 현대 편집기 UI는 대체로 하나의 메인 윈도우, 상단 탭바, 왼쪽 디렉터리나 목차 사이드바, 선택적 오른쪽 패널, 하단 터미널로 수렴함
  • Emacs에서도 그런 레이아웃을 만들 수 있지만, 화면을 한 버퍼에 집중하고 버퍼 전환으로 윈도우 전환을 대체하는 방식도 가능함
  • 두 윈도우까지만 완화하면 대부분의 단순함을 유지하면서 두 번째 윈도우를 라이브 참고 자료로 쓸 수 있음
    • Emacs 기본 설정은 scroll-other-window 같은 명령을 통해 이 패턴을 꽤 잘 지원함
  • 윈도우를 텍스트 컨테이너로만 보고 무시하는 전략도 있음
    • Avy로 화면상의 텍스트 위치로 바로 점프함
    • mark-ring, global-mark-ring으로 이전 위치를 되짚음
    • dogears는 더 세밀한 되짚기 UI를 제공할 수 있음
  • 수동 위치 고정에는 point-to-register와 jump-to-register를 쓸 수 있고, 더 영구적인 기록에는 bookmark-set과 bookmark-jump를 쓸 수 있음

자동 표시 규칙과 팝업 관리

  • display-buffer-alist는 Elisp 코드가 버퍼를 보여 주려 할 때 버퍼와 규칙을 매칭해 표시 방식을 정하는 변수임
  • 이론적으로 매일 보는 버퍼 유형마다 크기, 위치, 역할, 포커스 규칙을 만들면 윈도우 관리의 상당 부분이 해결됨
  • 문제는 설정 비용임
    • 버퍼와 모드 predicate
    • 윈도우 유형과 슬롯
    • display-buffer action 함수
    • 윈도우 파라미터
    • “내 윈도우 배치를 건드리지 말라” 같은 단순 의도를 쉽게 표현하기 어려움
  • 보조 도구도 있음
    • Shackle은 display-buffer-alist의 복잡함을 덮고 간단한 Elisp 인터페이스를 제공함
    • Doom Emacs는 set-popup-rule! 같은 편의 명령을 제공함
  • Popwin과 Popper는 모든 버퍼가 같지 않다는 관찰에서 출발함
    • 주 작업 버퍼와 임시 팝업 버퍼를 구분함
    • 문서, shell, 작업 상태, 컴파일 결과, 검색 결과, 메시지 등을 작은 보조 윈도우로 띄우고 쉽게 닫거나 순환하게 함
    • Popper는 지정한 팝업 버퍼를 한 키로 올리고 내리는 데 초점을 둠
    • Popwin은 더 오래되고 포괄적인 구현이지만, 자체 display-buffer 설정까지 함께 묶음
    • shell만 빠르게 여닫고 싶다면 shell-pop이나 vterm-toggle로 충분할 수 있음

빠져 있는 조각: 윈도우 트리 조작

  • Emacs는 프레임 안 윈도우를 트리로 표현하지만, 대부분 사용자 명령은 트리 구조가 아니라 공간 위치만 보고 동작함
  • 이 불일치 때문에 분할·삭제 시 기대와 다른 동작이 나오거나, 만들 수 있는 분할 구조에 제약이 생김
  • window-tree 같은 가상의 패키지가 있다면 내부 노드 단위 조작이 가능해질 수 있음
    • 프레임 일부만 분할·전치·미러링
    • 여러 윈도우를 부분 구성으로 선택
    • 선택한 부분을 탭이나 프레임으로 넘기기
    • 부분 구성을 복제하거나 저장
    • 특정 트리 branch를 display-buffer 계열 명령에서 보호
  • 이미 존재하는 Elisp 요소도 있음
    • window-tree는 트리 자체를 반환함
    • frame-root-window는 루트를 반환함
    • window-parent, window-child, window-*-sibling이 있음
    • walk-window-tree, walk-windows로 순회할 수 있음
  • 부족한 점도 명확함
    • 일반적인 split/delete 외에 트리를 변형하는 기본 함수가 없음
    • 내부 윈도우를 선택한다는 개념이 없어 UI로 시뮬레이션해야 함

빠져 있는 조각: 타일링 WM 통합

  • Emacs의 윈도우 트리 모델은 i3나 bspwm 같은 수동 타일링 윈도우 매니저와 매우 비슷함
  • i3, bspwm, tmux 안의 Emacs를 쓴다면 같은 키바인딩으로 Emacs 내부와 외부 윈도우를 자연스럽게 오가고 싶어짐
  • 기존 사례로 Pavel Korytov의 i3-integration과 qtile용 emacs-wm.el이 있음
  • 더 깔끔한 통합 인터페이스에는 다음 요소가 필요함
    • 윈도우 매니저가 활성 윈도우 클래스를 식별하고, 윈도우 이동·조작을 프로그래밍 방식으로 제공해야 함
    • 통신 방식은 shell 명령, 소켓, 서버 기반 IPC, Linux의 D-Bus 등이 될 수 있음
    • Emacs 쪽에는 윈도우 매니저식 조작을 흉내 내는 통신 방식 독립 인터페이스가 필요함
    • OS 윈도우 전환 시 활성 창이 Emacs인지 확인하고, 필요하면 Emacs가 내부 프레임에서 조작을 처리함

결론

  • Emacs 윈도우 관리는 other-window부터 ace-window, Avy, Popper, display-buffer-alist까지 다양한 층위의 선택지를 제공함
  • 모든 방법을 다 쓸 필요는 없고, 같은 문제를 푸는 대체 수단이 많기 때문에 하나를 골라 나머지는 무시할 수 있음
  • 기본 내장 도구는 오래 유지될 가능성이 높지만, 서드파티 패키지는 개발·방치·고아화에 따라 상태가 달라질 수 있음
  • Emacs의 윈도우 관리는 복잡한 고정 체계라기보다 재료와 조리법을 제공하는 열린 구조에 가까움
  • 적은 설정으로도 기본 식사는 가능하고, 약간의 조합과 Elisp 조정으로 훨씬 더 맞춤화된 작업 흐름을 만들 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 글이 좋고 설명과 가이드라인도 훌륭함. 균등 분할 창만으로는 부족할 때가 있어서, init.el에 아래 함수를 넣고 C-x 7에 바인딩해 현재 창과 짝 창을 세로로 70%/30% 크기로 조정함
    가로 방향도 C-x 8 바인딩으로 같은 방식으로 처리함

    (defun partial-size-window ()
    "Set the two split windows to 70% and 30% vertically."
    (interactive)
    (let ((size (- (truncate (* .70 (frame-height))) (window-height))))
    (if (> size 0)
    (enlarge-window size))))

    (defun partial-size-window-h ()
    "Set the two split windows to 70% and 30% horizontally."
    (interactive)
    (let ((size (- (truncate (* .70 (frame-width))) (window-width))))
    (if (> size 0)
    (enlarge-window-horizontally size))))

    • golden-ratio도 이런 용도로 쓸 수 있음

  • 좋은 탐구였음. 지금은 모바일이라 바로 못 해보지만 ace-window, ace-window-display-mode, frames-only-mode를 빨리 써보고 싶음
    솔직히 고백하자면 Emacs를 40년쯤 쓰면서도 대체로 next-window, 아래나 옆에 새 창 만들기, 원격 서버 작업 시 tmux에 의존하는 정도로만 써왔음

    • 나도 비슷함. 30년 동안 C-x 1/2/3, C-x o 정도가 거의 전부였음
      그래도 사실 꽤 강력하고 내 용도에는 충분해서, 여러 타일링 창 관리자도 딱 그 정도였으면 좋겠다고 느낌
    • 나도 비슷함. C-x o는 좀 번거로워서 아래 설정은 해뒀지만, 이런 추가 패키지들이 꼭 필요하다고 느끼지는 않음
      (global-set-key (kbd "M-o") #'other-window)
      그래도 이렇게 깊이 있는 참고 글이 있는 건 좋고, Karthik의 글은 늘 교육적이고 흥미로움

  • Karthink의 windmove-mode 메모에 덧붙이면, windmove-default-keybindings를 설정해서 Ctrl-<방향키>로 창 사이를 이동할 수 있음
    (windmove-default-keybindings 'control)
    내 설정에도 넣어뒀고, 미니멀한 스타터 키트에도 포함했는데 정말 게임 체인저임
    https://codeberg.org/ashton314/emacs-bedrock

    • 내 .emacs를 확인해보니 정확히 똑같이 쓰고 있었음. C-x O보다 키를 하나 덜 누르고 더 유연해서 선호함

  • Emacs가 프레임을 여러 창으로 나누지 않도록 설정해둠. 웹 브라우저가 브라우저 창을 여러 뷰포트로 쪼개지 않는 방식과 비슷함
    내 Emacs는 두 번째 프레임도 만들지 않음. 예전 방식이 더 이상 동작하지 않게 되면서 구현 방법은 해마다 바뀌었음
    지금 방식에서는 예를 들어 Emacs가 *Completions* 버퍼를 보여줄 때처럼 특정 상황에서는 프레임이 나뉘지만, 기억하기로는 두 번째 창을 없애려고 delete-window를 수동으로 호출할 필요가 없었고 항상 저절로 사라졌음

    • 웹 브라우저도 Vivaldi처럼 여러 페이지를 한 번에 보게 해주는 브라우저라면 실제로 그렇게 창을 나눌 수 있음
    • 프레임을 여러 창으로 나누지 않게 한 건 특정 문제를 해결하려는 목적이었는지 궁금함
      나는 다중 창 프레임을 꽤 많이 씀. 최신 macOS와 최신 Emacs에서 가끔 다중 창 프레임이 키보드나 트랙패드에 반응하지 않고 멈춘 것처럼 보이며, 여러 번 Ctrl-G를 눌러도 안 될 때가 있음
      그런데 C-x 5 2로 새 프레임을 만드는 건 동작하고, 멈춘 프레임으로 돌아가 C-x 5 0으로 그 프레임을 종료할 수 있었음

  • 글이 매우 깊이 있고, 작성자가 좋은 도식을 그리는 데 시간을 들인 점이 정말 마음에 듦

  • 좋은 글이고, 함께 쓰기 좋은 훌륭한 패키지를 공유하고 싶음. 내게는 zygospore가 없어서는 안 되는 도구였음
    “zygospore는 C-x 1(delete-other-window)을 다시 C-x 1을 눌러 되돌릴 수 있게 해줌”
    https://github.com/LouisKottmann/zygospore.el

    • 모든 창 구성 변경을 다시 실행하거나 되돌리려면 winner mode를 살펴볼 만함
      https://www.emacswiki.org/emacs/WinnerMode
    • 이상적으로는 undo여야 하지 않을까 싶음
      이상하긴 하겠지만 C-u C-x 1이면 일관성은 있어 보임

  • 작성자가 이걸 본다면, Acme editor에 대한 살짝의 언급이 반가웠다고 전하고 싶음

  • hledger-balance-sheet를 호출했을 때 기존 .hledger.journal을 대체하지 않고, 오른쪽에 30% 너비로 열리게 하고 싶음
    왼쪽에는 .hledger.journal이 그대로 열려 있고 선택된 상태로 남았으면 좋겠음

답변달기