emacsのシンタックスハイライトを無効化

まずは切り方。これを気になってこのブログを見た人がいるかもしれないので。 (global-font-lock-mode 0) こちらの設定で全てのシンタックスハイライトが無効になります。簡単ですね。 切ろうと思った理由 プログラムの中にはシンタックスハイライトを切っている人が一定数います。 不思議ですよね。僕も不思議でした。 そこでちょっと理由を調べてみました。そこで出会ったのがこのブログです。 こちらの内容は面白いので是非読んでみて欲しいのですが、要約すると 「シンタックスハイライトはプログラムを読みやすくするために開発されたはずだが、 開発者はコードの内容の理解よりもコードの形を見てしまい、コードの正しい理解から遠ざけてしまう。」 といった内容です。 好きな文を抜粋すると 色の付いたテキストは文章をつなぎ合わせるため、より脳を使う。 補助輪付きの自転車で練習しても自転車に乗れるようになるわけではない。 (コメントアウトを)色を変えて見えなくすることは、敷物の下に隠すようなものだ。 上記のようなものは過激ですが、成程なぁと思いました。 そんなこんなで感銘を受けて切ってみました。 使ってみて さすがに全てのシンタックスハイライトを切ると diff が見辛すぎたので以下のものだけ有効化しました。 (add-hook 'magit-mode-hook #'font-lock-mode) (add-hook 'diff-mode-hook #'font-lock-mode) 使用イメージ こんな感じになりました。 全然読めると思います。 感想 全然問題なく使える、というのが感想の一番です。むしろシンタックスハイライトを復活すると見辛く感じます。 個人的に良かったポイントは以下です。 コメントが読みやすいので読む習慣が付く。変なコメントに気付けるようになりました。 シンタックスハイライトの色で微妙な気持ちになることがなくなった。テーマで悩むこともなくなりました。 シンタックスハイライトが逆に付かなくなることによるイライラが失くなった。だって最初から付いてないんだから。 おわりに これを見てくれた人も試しに切ってみると世界が変わるかもしれません。 追記 ちなみに、flyspell を使う場合はコメントアウトにシンタックスを当てないと、flyspell が反応しません。 そのため、以下のように一回有効かしてからコメントアウト以外を無効にする必要があります。 (add-hook 'prog-mode-hook #'(lambda() (turn-on-font-lock) (setq-local font-lock-keywords nil)))

2021/11/21(作成日) · 2022/09/26(更新日)

コードの保存時にスペルチェック

プログラムを書いているさい、スペルミスで恥をかいたことがある人は多いと思います。 特に日本人の方は普段馴染ないため、違和感に気付きにくかったりします。 emacs ではデフォルトでスペルチェックを行なう機能が搭載されていますが、プログラムのように実際の単語ではない単語や書き方が多いと大量に余計なものにヒットしてしまい鬱陶しいです。 そこで、go の linter として使ったりもする、misspell という Go のツールを使用していい感じにできないかを考えました。 emacs で misspell の使用 探したら、すでにやっている人がいました。考えることは一緒ですね。 https://syohex.hatenablog.com/entry/2016/02/15/105101 ただ、これだとバッファが立ち上がってうざいので、minibuffer に結果が出るようにして最初は運用していました。 また、コードを書いている最中に何度もコマンドを実行して確認するのも面倒なので、save-hook に入れて楽をしようと考えました。 (defun run-lint () (interactive) (let ((current (file-name-nondirectory (buffer-file-name)))) (let ((err (with-temp-buffer (call-process "misspell" nil (current-buffer) nil current) (buffer-string)))) (message (string-trim err))))) (add-hook 'after-save-hook 'run-lint) しかし、interactive に呼ぶときはいいのですが、save-hook で呼ばれるときは、体感一瞬しか表示されないので、すごい見辛く感じました。 間違えている箇所のハイライト そこで、今度は間違えている所をハイライトして、目視で確認しやすくしようと考えました。 以下のようなハイライトコードを用意します。 (defun highlight-word (line col) "Highlight Word" (interactive) (save-excursion (goto-line line) (let* ((begin (progn (forward-char col) (point))) (end (progn (forward-word) (point))) (overlay-highlight (make-overlay begin end))) (overlay-put overlay-highlight 'face '(:background "OrangeRed4")) (overlay-put overlay-highlight 'line-highlight-overlay-marker t)))) (defun remove-all-highlight () "remove all line highlight" (interactive) (remove-overlays (point-min) (point-max))) 次に misspell から行と列の情報を抜き出して上記の関数に食わせます。これをフックさせる感じです。...

2021/04/10(作成日) · 2022/09/26(更新日)

spacemacs を辞めた理由

はじめに spacemacs を使い半年、限界を感じたので emacs の設定を 0 から行ないました。 その移植に思い立った理由を述べていきたいと思います。 嫌なとこたち master の更新が止まっている デフォルトのインストール先が master になっていましたが(現在は devleop になっていました)、最終更新は 2018 年であり、最新の機能が欲しい場合は devlop ブランチにする必要がありました。 spacemacs を使っている人はみなさん develop を使用していたようで、issueでも問題になっていました。 ですが、develop の問題もあります。 spacemacs の変更に振り回される 上記のことから、develop を使用していたのですが、いかんせん更新に振り回されます。develop を更新したらキーバインドが変わった、パッケージでエラーが出たなんてよくあります。 修正の PR がマージされるまで動かないので、しょうがないから PR の変更をローカルに反映したりしたりと、色々と更新時の面倒が多いです。 原因特定が面倒 どのレイヤーが原因なのか、どの設定値が原因なのか調べるのが難しいというのがあります。mac であまりにもフリーズするので調べてみたら、dotspacemacs-mode-line-unicode-symbols を nil にしたら直るという解決策だったことがあります。spacemacs 固有の問題なのか、それとも拡張側の問題なのか、これの線引きが難しく調べるのに難航するというのが結構しんどいです。 重い なんか重いです。結局原因は不明でしたが、特定のモードによってはフリーズすることがよくあり、issue でも似たような報告がちらほらあります。 spacemacs は所謂おらおら設定集なので、余計な設定も結構入っています。そのため、自分が必要なものだけ入れたときに比べ、余計な処理が走りやすいんだと重います。 ですが、滅茶ストレスです。 拡張性 spacemacs には様々なオプションが用意されており、自由に拡張することができます。 しかし、拡張するといっても spacemacs の範囲という感覚です。もう一歩先に行こうとするとかなりつまずきます。 せっかく設定しても spacemacs によって上書きされたりして反映されなかったり、オプションが効かなかったりと、できないことが多いです。 僕はこれが嫌で乗り替えました。オラオラ設定は楽しかったですが、何でもできるという emacs らしさが spacemacs の上でしか成り立たなかったので、嫌になりました。 よかった所 ファイルから自動で適した layer(簡単にいうと設定集)をダウンロードしてくるのには痺れました。これは本当に素晴らしいと重います。 新しい拡張子を開くたびに、拡張を調べてインストールするというのが面倒な人、初めて emacs を触る人、emacs の設定をするのが面倒な人は、spacemacs がとても刺さると思います。 また、オラオラ設定のため、いきなり emacs が vscode になったかのような錯覚を受けるぐらい初期設定が充実しています。 あまり、設定を凝ったことがない人は是非とも試してみてほしいです。...

2020/12/08(作成日) · 2022/09/26(更新日)

emacs と vim の lsp をdocker で試す

はじめに language server(以下 lsp)の登場でどのエディタでも、統合環境のような高機能エディタとなることが可能になりました。 みんな大好き emacs や vim でも lsp をサポートし、言語ごとの設定が大分楽になり敷居が下がってきたんじゃないかなって思います。しかし、如何せん試してみるのも面倒だなーって思う人は結構いるはずです。試してみる気力があったらとっくに入門してますしね…。 そこで、今回は emacs と vim の lsp 設定が内包した docker を使ってみて最新エディタ気分を味わっていきたいと思います。 emacs + lsp on docker まず、emacs + lsp です。最近は spacemacs が流行っていますが今回は普通の emacs でやっていきます。最初に、以下のコードで emacs + lsp on docker のコードをローカルに落としてきます。 git clone https://github.com/emacs-lsp/lsp-docker.git 権限を与えて実行します。 cd lsp-docker chmod u+x start-emacs.sh ./start-emacs.sh 立ち上がったら、パッケージのインストールを聞かれるのでyで進んで行きます。 インストールが終わったら、C-x C-f で Project の適当な言語のファイルを開いて見ます(C-x は windows だと Ctr+x、mac だと ⌃+x です)。 ファイルが開けたら、適当に色々試して見ながらコーディングすると楽しいと思います。 補完が効いているのとかがよく分かると思います。 ただ、定義ホバーがオンになっているせいか docker との相性なのか、少し重いですね…。 詳しい挙動やできることなどは以下を見ていただけると助かります。 https://github.com/emacs-lsp/lsp-mode vim + lsp on docker 次に vim + lsp です。こちらも流行りの neovim でなく普通の vim でやっていきます。今回も同じようにコードを落としてきます。今回は公式で用意されていなかったため自前で用意しました。...

2020/07/22(作成日) · 2022/09/26(更新日)