(Neo)vimと比べてEmacsの残念なところ
- 導入コストが異常に高い
- 例えばプラグインについて、Plugとrequireだけして終わりではない場合が多い。
- しかもドキュメントのありかが、(Vimと違って)GithubのReadmeに固まっているわけではない。
- (古臭い)ホームページがあったり、ソースを直接読まないといけなかったりする。
- できることが多すぎるし、設定できることも多すぎる(というか何でもできる)。
- lispの特性上、コンフィグとパラメータが厳密に切り分けられていない。
- デザイン(Emacs本体もプラグインのホームページも)が古臭い。
- 基本、プラグインのデフォルト設定も使いにくいものが多い。
- fzfみたいにウィンドウを重ねたり、Virtual Textみたいな機能は(多分)ない。
- Python/matplotlibの出力をインラインで出す方法が無さそう。
- ein.elというパッケージはあるけど、pythonコードからsendする形だとインライン出力できない。
- emacs-jupyter.elというパッケージはあるけど、公式から落としてきた素のEmacsだと動かない。
- use-packageするとエラーを吐かれるので、.emaca.d/pacakges配下のzmqフォルダでmakeをしてやる必要がある。
- それでもやはり、少し使いにくい。
- Markdown/Orgの数式を(手軽に)リアルタイムプレビューする方法が無さそう。
- Emacsは数式の処理をtexにやらせようとするので、texを入れるところからのスタート。
- 今どきColabでもVisual Studio Codeでもデフォルトで数式出力できるのに、tex入れろって、、、
- 試してないけどgrip-modeは良さそう?
- EvilのVim再現度がイマイチ。
-
/
検索のハイライトの挙動とか、Redoの挙動とかがおかしい。バッファの種類によって、Vimのキーバインドが良く殺される。 - そしてキーバインドの設定が激ムズ。
- elispは柔軟性にあふれていて何でもできるとは言っても、既存のコードが大きくなりすぎている。
-
(Neo)vimと比べてEmacsの凄いところ
- elispに支えられた、設定の柔軟性があるのは間違いない。
- ただしできることが多すぎて、みんな変なこだわりを持って、プラグインがニッチなものにどんどんフォークしていく。
- そしてモダンな観点から当然あるべきプラグインについては、なかったりする。
- 色々ニッチなプラグインはあるけど、デザインはイマイチのものが多い。
- Vimのプラグインは人に使ってもらう前提で作られているものが多いけど、Emacsのプラグインは自分で使っているものを公開しただけ、という感覚がある。
- オレオレLispという言葉があるように、オレオレEmacsがあふれているイメージ。
- ただしできることが多すぎて、みんな変なこだわりを持って、プラグインがニッチなものにどんどんフォークしていく。
init.el
- パッケージ管理は
~/.emacs.d/init.el
に下記を書いた状態で、M-x package-install [Return] use-package [Return]
をする。
(require 'package)
(setq package-archives
'(("melpa" . "https://melpa.org/packages/")
("org" . "https://orgmode.org/elpa/")
("gnu" . "https://elpa.gnu.org/packages/")))
(package-initialize)
-
use-package
の使い方は下記。
(use-package パッケージ名
:ensure t)
- Evilのキーバインドは
use-package
の:bind
で行う。例えば下記。- 必要に応じて
C-h k
やF1 m
を駆使しながら、余計なバインドを殺す作業も行う。
- 必要に応じて
(use-package evil
:ensure t
:init
(setq evil-want-C-u-scroll t)
:bind ((:map evil-motion-state-map
("C-b" . nil))
(:map evil-normal-state-map
("C-b" . 'switch-to-buffer)))
:config
(evil-mode t)
(use-package undo-fu
:ensure t
:config
(evil-set-undo-system 'undo-fu)) ; 'undo 'undo-redo 'undo-tree 'undo-fu
(evil-ex-define-cmd "ls" 'switch-to-buffer)
(evil-ex-define-cmd "edit" 'find-file)
(evil-ex-define-cmd "source" 'eval-buffer))
- 参考までに、LSPの設定は例えば下記。
;; https://www.mattduck.com/lsp-python-getting-started.html
;; https://emacs-lsp.github.io/lsp-mode/tutorials/how-to-turn-off/
;; sudo pip3 install 'python-language-server[all]'
;; pip3 install pyls-black pyls-isort pyls-mypy
;; pip3 insetall future
(use-package lsp-mode
:ensure t
:config
(lsp-register-custom-settings
'(("pyls.plugins.pyls_mypy.enabled" t t)
("pyls.plugins.pyls_mypy.live_mode" nil t)
("pyls.plugins.pyls_black.enabled" t t)
("pyls.plugins.pyls_isort.enabled" t t)
("pyls.plugins.flake8.enabled" t t)))
:hook
((python-mode . lsp)))
(use-package lsp-ui
:ensure t
:commands lsp-ui-mode)
(setq lsp-headerline-breadcrumb-enable nil)
(setq lsp-signature-render-documentation nil)
(with-eval-after-load 'lsp-mode
(setq lsp-modeline-diagnostics-scope :workspace))
- 参考までに開発環境(elpy)の設定は例えば下記。
;; https://realpython.com/emacs-the-best-python-editor/
(use-package elpy
:ensure t
:config
(elpy-enable)
;; (setq python-shell-interpreter "/usr/local/bin/python3")
(setq python-shell-interpreter "jupyter"
python-shell-interpreter-args "console --simple-prompt"
python-shell-prompt-detect-failure-warning nil)
(add-to-list 'python-shell-completion-native-disabled-interpreters
"jupyter"))
(use-package flycheck
:ensure t
:init
(add-hook 'elpy-mode-hook 'flycheck-mode)
:config
(setq elpy-modules (delq 'elpy-module-flymake elpy-modules)))
- 参考までに補完プラグインの設定は、例えば下記。
(use-package company
:ensure t
:init
(add-hook 'after-init-hook 'global-company-mode)
:config
(setq company-idle-delay 0)
(setq company-minimum-prefix-length 1)
(setq company-selection-wrap-around t))
(with-eval-after-load 'company
(define-key company-active-map
(kbd "<return>")
#'company-abort)
(define-key company-active-map
(kbd "<tab>")
#'company-complete-selection))
- 参考までにファジーファインダーの設定は、下記。helm/ivy/verticoの3者とも試したけど、ivyに落ち着いた。
- helmはデザインがイマイチで、verticoは機能面でニッチな機能がまだ実装されていないイメージ。
- ivy-posframeを使わないと、fzf的なモダンな表示にならない。
- 作者曰く、「子ディスプレイって画面が見えなくなって邪魔じゃない?」。ミニバッファで画面が揺れる方が見にくいと思う。
(use-package ivy
:ensure t
:config
(ivy-mode)
(setq ivy-use-virtual-buffers t
enable-recursive-minibuffers t
ivy-height 20
ivy-ignore-buffers '("\\` " "\\`\\*")))
(use-package counsel
:ensure t
:config
(counsel-mode 1)
(setq counsel-find-file-ignore-regexp "\\(^\\.\\)\\|__"))
(use-package swiper
:ensure t)
(use-package ivy-posframe
:ensure t
:config
(setq ivy-posframe-display-functions-alist '((t . ivy-posframe-display)))
(ivy-posframe-mode 1))
感想
- 前述の通り、沼すぎる。エディタは手段であって目的ではない。
- 「それはあなたがEmacs/elispを理解していないからだし、そういったレベルの低い人に無理に合わせようとも思わない」とEmacs Loverには言われそう。
- ただelispを理解していても、①Readmeを読むよりソースを読む方が時間と労力を消費するのは変わらないと思う。もしそうなら、Emacs文化そのものが消費の激しい文化。
- 「そしてソースを読めば良いじゃない?」の文化だと、発展が限られると思う。
- 敷居の高さから他人のプラグインを理解する機会が限定されるので、②触発されるチャンスが限られてくる。
- またQiita記事やブログを書いたことがある人なら分かるように、人の目を意識するとクオリティは上がる。③他人の目を意識することは大事だけど、ソース読めの文化だとコレがない。
- 「こだわりが強くて世間に媚びないミュージシャン」と「歌はそこそこでも世相に合わせるミュージシャン」なら、後者の方が売れるはず。④人に合わせる感覚と成功の間には相関関係がある。ソース読めの人種には、この感覚がない。
- Emacs Loverは「別に売れるのが目的ではない」と言いそう。でもそれだと、ただのオ◯ニー。オ◯ニーで何が悪いと開き直られると、どうぞご自由に、となるのだけれど。
- 「ソースを読んだ方がプラグインが良く理解できる」と言われそう。ただ私はファイルの編集をしたいだけであって、プラグインの内々を逐一理解しようとするのは効率が悪い。
- 勉強したいことは他にも一杯ある。Emacs Loverに「俺はエディタに尽くすと決めたんだ」と言われると、どうぞ、となるけど。
- なお、SpacemacsとDoom Emacsも入れてみたけど、独自のコンフィグ要素が充実していて更に沼。
- Emacsはlispで何でもできる分、全体的に混沌としているイメージ。
- 「UNIXという考え方―その設計思想と哲学」という本にある、「直行した小さなオペレータを組み合わせる」というアプローチ(つまりVim)の方が上手くいくのだと思う。
- こちらの方が見通しが良くなり、無駄が減る。Emacsは柔軟性ゆえの利点もあるけど、総じてその利点は分散を増やして得られているだけのように見える。言い換えると、柔軟性ゆえの問題点も多々ある。
ポエム
- 上述の通り、人気があることが偉いことであるというならば、Visual Studio Codeが一番偉いということになる。
- Vimの利点は、A) マウスレスなことと、B) カスタマイズ可能な範囲が広いことだけ。
- マウスレス(やカスタマイズ性)で生産性が倍になるかというと、そんなこともない。
- そもそも生産性向上・効率向上なんて考えるより、大体の場合は、もっと考えるべきことがある。