最近、c-modeが超絶重い問題にぶち当たるファイルを弄ってる事が多くストレスマッハなので真面目に調べることにした。といっても、調べだすとキリがないので深みにはまらないように気を付ける。

まずはfont-lock-support-mode変数を評価して、Font Lockの現在の動作モードを調べる。デフォルトではjit-lock-modeになっているハズ。歴史的(?)に他のモードもあるようだけど、今は殆どJit Lockのようだ。詳細→emacs/font-lock.el

JIT Lockはその名の通り、バッファに表示中の部分のみハイライト処理を行う。M-x customize-apropos RET jit RETでJIT関連の設定項目を表示してみる。

更にそこから関係ありそうな設定を抜き出したのが以下。

• jit-lock-chunk-size
• jit-lock-context-time
• jit-lock-contextually
• jit-lock-defer-time
• jit-lock-stealth-load
• jit-lock-stealth-nice
• jit-lock-stealth-time

説明を読んでjit-lock-context-timeとjit-lock-defer-timeが効きそうかなーと思い適当に値設定してみたけど、目立った改善は見られず…。前回のプロファイル結果と合わせて考えると、Font Lockが重いのではなくFont Lockに付随するc-modeの構文解析が重い予感？

ここまでで2時間ほど費やしてしまったので、今日はここまで。仕事しないと…。

EmacsでC++を書いてるとバッファが超重くなることがある。キー入力やスクロールがツーテンポくらい遅れる感じ。他のバッファには影響しないので物凄く困ってるわけではないが、地味にストレスでござる。

発生条件がさっぱりわからんのが困りどころ。重くなるファイルでも開いた直後は大丈夫だったりして、編集しているうちに何かの拍子で重くなる。ファイルの大きさ自体はさほど関係ないようだ（起きないやつは行数が多くても起きないし、起きるやつは100行程度のソースでも起きる）。何となく、コメントないしマルチバイト文字成分多めのファイル、C++11なコードで発生しやすいような感じ。

ほぼ間違いないのはc-modeが原因であるということ。他のmodeでは発生しないし…。恐らくFont Lockがらみが原因と思われる

（2019-07-09 追記）
M-x font-lock-modeでFont Lockの有無を切り替えると明らかに速度が変わるので、Font Lockがらみなのも間違いない。

未だ解決には至ってないが、毎度profileとるのが面倒なのでメモがてら記事にしとく。

Function                                                  CPU samples    %
- redisplay_internal (C function)                                 736  68%
 - jit-lock-function                                              731  68%
  - jit-lock-fontify-now                                          731  68%
   - jit-lock--run-functions                                      725  67%
    - run-hook-wrapped                                            725  67%
     - #<compiled 0x1b94275>                                      725  67%
      - font-lock-fontify-region                                  725  67%
       - c-font-lock-fontify-region                               722  67%
        - font-lock-default-fontify-region                        658  61%
         - font-lock-fontify-keywords-region                      647  60%
          - c-font-lock-declarations                              320  29%
           - c-find-decl-spots                                    313  29%
            - #<compiled 0x1c22bc1>                               234  21%
             - c-get-fontification-context                        125  11%
              - c-back-over-member-initializers                    64   5%
               + c-just-after-func-arglist-p                       18   1%
               + c-parse-state                                     16   1%
               + c-back-over-compound-identifier                   14   1%
               + c-at-toplevel-p                                   10   0%
               + c-backward-sws                                     5   0%
              + c-looking-at-or-maybe-in-bracelist                 47   4%
              + c-backward-token-2                                  6   0%
              + c-back-over-compound-identifier                     3   0%
             + c-forward-decl-or-cast-1                            60   5%
             + c-font-lock-single-decl                             15   1%
             + c-backward-sws                                      14   1%
             + c-backward-token-2                                   4   0%
               c-syntactic-re-search-forward                        2   0%
             + c-forward-label                                      1   0%
            + c-bs-at-toplevel-p                                   52   4%
            + c-beginning-of-macro                                  5   0%
            + c-forward-sws                                         3   0%
            + c-literal-start                                       1   0%
            c-font-lock-<>-arglists                                77   7%
          + #<compiled 0x1c2637d>                                  44   4%
          + c-font-lock-cut-off-declarators                        41   3%
          + c-font-lock-enclosing-decls                            34   3%
          + c-font-lock-enum-body                                  24   2%
            #<compiled 0x1c26351>                                  19   1%
          + c-font-lock-complex-decl-prepare                       11   1%
          + c-font-lock-enum-tail                                   8   0%
            #<compiled 0x1c272e7>                                   8   0%
          + c-font-lock-invalid-single-quotes                       7   0%
            #<compiled 0x1c272af>                                   6   0%
            #<compiled 0x1c2631b>                                   6   0%
            #<compiled 0x1c27285>                                   4   0%
            #<compiled 0x1c2633d>                                   4   0%
            #<compiled 0x1c263a3>                                   4   0%
            #<compiled 0x1c2630b>                                   3   0%
          + c-font-lock-raw-strings                                 3   0%
            whitespace-trailing-regexp                              1   0%
         + font-lock-fontify-syntactically-region                   7   0%
         + font-lock-unfontify-region                               1   0%
        + c-before-context-fl-expand-region                        64   5%
 + file-remote-p                                                    4   0%
 + eval                                                             1   0%
- ...                                                             232  21%
   Automatic GC                                                   232  21%
+ command-execute                                                 103   9%

御覧の通り、c-modeのFont Lockが原因なのは間違いないんだよなー。解決方法分からんけど。

以前はそれほど気にならなかったし設定も大して変えてないので、単にマシンがしょぼいだけって線も捨てきれない。一応マシンスペックも書いておく。

前はUnreal Engine 4での開発に耐えられるようなデスクトップマシンだったのよねー。

Windows 10 + PuTTY(plink) + Emacs 26.1な環境でLinuxターゲットのSSH TRAMPがいい感じに使えてたんだけど、PuTTYをmsys2のものに置き換えたら、rgrepが「find: paths must precede expression: ^^!^」なるエラーを吐いて使えなくなってしまった。これじゃ仕事にならん！ってなもんで前のPuTTYに戻したものの状況は変わらず…オワタ＼(^o^)／

とりあえずemacs/share/emacs/26.1/lisp/progmodes/grep.el.gzの1153行目付近、-prune -oと(shell-quote-argument “!”)から文字列を結合してるあたりを削り、M-x byte-compile-file grep.el.gzして、超無理やり解決した。

同様の問題が起きた時の参考として、解決に至るまでの顛末をメモ。

• lgrepやgrep-findは動くのでrgrepの問題と判断。
• エラーメッセージと*grep*バッファのコマンドログから -prune -o ^“^!^” -type d あたりが怪しいと判断。実際、^“^!^”の先頭のサーカムフレックスは引数の文字としておかしくない？
• M-x describe-function rgrepでrgrep関数の定義を探す→grep.el.gzと判明
• ファイル内を「rgrep」をキーワードに流し読み。rgrep-default-command関数で実行するコマンドを組み立ててる予感！
• 一応scratchバッファで(rgrep-default-command “XXX” “YYY” “ZZZ”)を実行して結果を見てみる→あたり！
• rgrep-default-command関数の中で「!」を使ってるところを探す→(shell-quote-argument “!”)発見
• scratchバッファで評価してみる→変なエスケープのされ方をされている！
• 「!」は結合しない方向で、findの引数の関係が正しくなるように前後の処理を調整
• M-x byte-compile-file grep.el.gzしてEmacs再起動
• rgrepが使えるようになっていることを確認

根本原因はshell-quote-argumentの挙動が変わった(?)ことっぽいけど、なぜ変わったのかは不明のまま。PuTTYを差し替えたこと以外、何もいじってないはずなんだけどな…。

同様にshell-quote-argumentの実装を見てみても、OSによって処理を分岐させてるだけで変なところはない。……ん？待てよ、TRAMPの場合はOSはどういう扱いになるのこれ？ちゃんとリモート側のシステムにあわせてsystem-typeの中身が変わるのこれ…？

サーカムフレックスはコマンドプロンプトでのエスケープシーケンスらしいので、TRAMPしてるにもかかわらずshell-quote-argumentがWindows用の挙動を示すのが根本原因のようだ。

先の回避策では除外ディレクトリの指定が効かなくなってしまうので、grep.el.gzの1153行目あたりを以下のように変更した。

    (and grep-find-ignored-files
         (concat (shell-quote-argument "!") " -type d "

↓

    (and grep-find-ignored-files
         (concat " '!' -type d "

Emacs上でソースコードのコンパイルを行うにはM-x compileコマンドを使う。するとmakeが走り、結果がCompilatinバッファに表示され、M-x next-errorなどでエラー行に一発ジャンプ出来て超便利ッ……という所までは良く語られる。が、しかーし、肝心のMakefileの指定方法に触れている解説が少ない。

実際のところ、M-x compileのmakeの引数指定のところで書いてやればいいのだが、カレントパスや取り掛かっているプロジェクトごとにアレコレ考えてMakefileを指定するのは現実的ではない。それする位なら、Compilationの利点を捨て、ターミナルのコマンドヒストリーでコンパイルした方がよっぽどマシである。たいてい、Makefileはソースフォルダのトップなりに置くので、編集中のファイルから上に辿り、見つかったMakefileでmakeしてくれれば済む話。

で、ようやくそれを実現する方法を見つけた。Recursively go up to find Makefile and compileに載ってるelispを使う。万が一消えた時用に転載。

(defun desperately-compile ()
  "Traveling up the path, find a Makefile and `compile'."
  (interactive)
  (when (locate-dominating-file default-directory "Makefile")
  (with-temp-buffer
    (cd (locate-dominating-file default-directory "Makefile"))
    (compile "make -k"))))
 
; C-x mでMakefileを探してコンパイル
(global-set-key (kbd "C-x m") 'desperately-compile)

上記サイトの回答に書いてあることだが、指定ファイルが見つかるまでディレクトリを遡って検索する打って付けのlocate-dominating-fileなる関数があるそうで。今回の用途だけではなく、様々な場面で役に立ちそう。

通常、EmacsでTAB補完の時とかに表示されるCompletionsバッファは、フレーム¹⁾下部を分割した一時的なウィンドウ²⁾として表示される。言葉じゃわかりにくいので、スクショを張っとくと↓こんな感じね。

自分のEmacsの使い方は垂直分割した2つのウィンドウ表示が基本で、Completionsバッファは非アクティブな方のウィンドウに出て欲しい。その方が補完候補の一覧性が圧倒的だし、ウィンドウがパカパカしないのがいい。スクショを張（ｒｙ

ここの回答に載ってるelispを参考に、ウィンドウが1つの時はウィンドウ幅に応じて分割方向を変えるようにしてみた。

(defun display-on-side (buffer &optional not-this-window frame)
  (let* ((window (or (minibuffer-selected-window)
                     (selected-window)))
         (display-buffer-function nil)
         (pop-up-windows nil))
    (with-selected-window (or window (error "display-on-side"))
      (when (one-window-p t)
        (if (> (window-pixel-width) (window-pixel-height))
            (split-window-horizontally)
          (split-window-vertically))
        )
      (display-buffer buffer not-this-window frame))))
(setq display-buffer-function 'display-on-side)

水平2分割した状態で使うと、非アクティブなウィンドウの方がCompletions表示時に勝手にリサイズされる問題があったりする…。自分は水平分割使わないので放置してます、すいません。えらいひと直して教えてください。

• emacs - Display compilation in inactive buffer - Stack Overflow
• How to force completions buffer to appear in a side window? - Emacs Stack Exchange
• Window Sizes - GNU Emacs Lisp Reference Manual