Emacsウィンドウ管理百科事典

 (karthinks.com)
1 ポイント 投稿者 GN⁺ 2024-05-13 | 1件のコメント | WhatsAppで共有
  • Emacsのウィンドウ管理は、バッファとウィンドウが分離された柔軟な構造の上に、やや無骨な基本操作が載っているため、ユーザーがツールと習慣を組み合わせてワークフローを作る必要がある
  • この記事の焦点は、display-buffer のルールやタブベースのワークスペースではなく、1つの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は両者を分離することで、より柔軟な配置を可能にしている
    • 同じファイルを2回表示するのが簡単
    • ファイルと直接対応しないバッファも自然に扱える
    • 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 を操作するのが最も抵抗の少ない経路になり得る
  • マウスジェスチャーでできる操作もある
    • フレームの垂直・水平分割
    • ウィンドウの削除
    • ウィンドウ内のバッファ循環
    • 右・左へのウィンドウ交換
    • 1 つのウィンドウ内で直近 2 つのバッファをトグル
  • 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 を 2 つのウィンドウの親ノードに変える
    • 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 の例では、Issue 一覧で 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: 誤って閉じたフレームやタブを復旧する
  • Emacs が見当違いの場所にバッファを表示した後、毎回 winner-undo で後始末する用途に使うのは、その場しのぎに近い
    • 根本的な問題は、バッファ表示ルールが意図どおりに定まっていないことにある

頻繁に行き来する 2 つのウィンドウに最適化する

  • 実作業では画面に複数のウィンドウがあっても、ほとんどは 2 つのウィンドウ間 を頻繁に行き来する
    • Code & REPL
    • Code & Grep
    • Prose & Notes
    • Listing & Item
  • 他のウィンドウは、ドキュメント、デバッグ情報、ログ、コマンド出力、目次、ファイルエクスプローラー、プレビューのように頻繁に見るものの、ほとんど切り替えない参照領域である場合がある
  • get-mru-window を使って最も最近使ったウィンドウへ切り替える other-window-mru の例がある
    • 2 つ目のウィンドウをマウス、ace-window、winum などどの方法で選んでも、その後は素早く往復できる
  • other-window 自体を改善する方式もある
    • ウィンドウが 1 つだけなら自動で分割するようにする
    • switchy-window のように最近使用した順で巡回する
    • other-window-alternating のように、連続呼び出しでないたびに方向を反転させ、2 つのウィンドウ間の往復を自然にする

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 である

ウィンドウを必ず切り替える必要はあるのか

  • ウィンドウ切り替えの目的は大きく2つに分けられる
    • Switch and stay: 移動先のウィンドウで編集や作業を続ける
    • Switch and return: 一時的にスクロール、検索、コピー、削除などを行い、元の位置に戻る
  • 1つ目の場合、Avyはウィンドウ切り替えとカーソル移動を1つにまとめられる
    • avy-goto-char-timerは、画面に表示されている複数のEmacsウィンドウとフレームを、1つのジャンプ候補プールのように扱う
    • 特定の文字列や文字位置へジャンプしながら、自動的にウィンドウも切り替わる
    • Avyがウィンドウやフレームをまたがない場合は、avy-all-windowsの設定を確認する必要がある
  • pop-global-markは以前の位置に戻る手段であり、必要ならウィンドウ切り替えも同時に起こり得る
    • デフォルトでは現在のウィンドウでバッファを切り替えるため、pop-to-bufferを使わせるadviceがある
  • 2つ目の場合は、「切り替え → 操作 → 復帰」という流れをコマンドで包んで自動化できる
    • ace-window-one-commandは汎用的な方法の1つ
    • 特定の操作は専用コマンドやマクロとして作れる

別ウィンドウのスクロール・検索・バッファ切り替え

  • scroll-other-windowとscroll-other-window-downは、現在のウィンドウを離れずに別のウィンドウをスクロールする
    • デフォルトの対象は、現在のウィンドウから時計回りの「次のウィンドウ」
    • ウィンドウが3つ以上あると、期待していた参照ウィンドウではなく別のウィンドウがスクロールされることがある
  • 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は、おおむね1つのメインウィンドウ、上部タブバー、左側のディレクトリまたは目次サイドバー、任意の右側パネル、下部ターミナルへと収束している
  • Emacsでもそうしたレイアウトは作れるが、画面を1つのバッファに集中し、バッファ切り替えでウィンドウ切り替えを代替する方法も可能
  • 2ウィンドウまでに緩和すれば、大半のシンプルさを保ちながら、2つ目のウィンドウをライブ参照資料として使える
    • 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は、指定したポップアップバッファを1キーで上げ下げすることに焦点を置く
    • 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まで、さまざまなレイヤーの選択肢を提供している
  • すべての方法を使う必要はなく、同じ問題を解く代替手段が多いため、1つを選んで残りは無視できる
  • 基本の組み込みツールは長く維持される可能性が高いが、サードパーティパッケージは開発状況・放置・孤児化によって状態が変わり得る
  • Emacsのウィンドウ管理は、複雑な固定体系というより、材料とレシピを提供する開かれた構造に近い
  • 少ない設定でも基本的な作業環境は作れるし、少しの組み合わせとElispによる調整で、はるかにカスタマイズされたワークフローを構築できる

関連記事

1件のコメント

 
GN⁺ 2024-05-13
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よりキーを1回少なく押せて、より柔軟なのでこちらを好んでいる

  • Emacsがフレームを複数のウィンドウに分割しないように設定している。Webブラウザがブラウザウィンドウを複数のビューポートに分割しないのと似たやり方だ
    自分のEmacsは2つ目のフレームも作らない。以前のやり方がもう動かなくなってから、実装方法は年ごとに変わってきた
    今のやり方では、たとえばEmacsが*Completions*バッファを表示するときのような特定の状況ではフレームが分割されるが、記憶が正しければ、2つ目のウィンドウを消すためにdelete-windowを手動で呼ぶ必要はなく、いつも自動で消えていた

    • Webブラウザでも、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がそのまま開かれ、選択された状態で残っていてほしい