いまだにEmacsを使っている人はいるのか？

 (jmmv.dev)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 1997年にLinuxを使い始めて以降、VimとEmacsを行き来していたが、2015年には VSCode と IntelliJ へ移り、その後 2022年に Snowflake のリモート Linux VM 環境で Doom Emacs に戻ってくる流れとなった
  • VSCode はモダンな UI、軽量さ、JSON ベースの設定、Go・Rust の LSP 統合 によって学習と開発を容易にし、Java 開発では IntelliJ のほうがより現実的な選択肢だった
  • Snowflake の古い Linux VM では shell script と Bazel build file の作成が中心で、リモートのグラフィカル環境よりも SSH ベースの作業 が適しており、再び Emacs が必要になった
  • Doom Emacs は合理的なデフォルト、言語統合、Vim スタイルのキーバインド、space ベースのポップアップメニュー、単純な設定ファイル構成により、Emacs を IDE のように感じさせる
  • MacBook、Linux laptop、Linux cloud workstation、FreeBSD server のどこでも shell・tmux・Emacs だけで 同一の開発環境 を維持できることが、Emacs を使い続ける最大の理由になっている

DOS/Windows IDE から Linux エディタへ

  • 1997年ごろ、Caldera OpenLinux 1.1 で Linux を使い始めた
  • それ以前は Borland Turbo C++ や Visual Basic を多く使っており、当時の完成度の高い IDE に慣れていた
  • Linux 入門書 2 冊を通じて Vim と Emacs に触れ、どちらのエディタも上級者向けの選択肢として紹介されていた
  • 以前使っていた IDE のほうがより完成されているように見えたが、Vim と Emacs の基本的な使い方とチュートリアルはそれぞれ習得した
  • 2015年ごろまで Vim と Emacs を交互に使っていた
    • Emacs は長時間のコーディングセッションにより向いていた
    • Vim は pkgsrc 作業のように複数ファイルをすばやく行き来して修正するときに強みがあった

VSCode と IntelliJ に移った理由

  • Vim と Emacs でも十分動いていたが、言語統合 が弱く、よりモダンなエディタに関心が向いた
  • macOS に移行してから Atom や Brackets も試したが、機能や設定が多すぎて脆弱で負担が大きいと感じた
  • 2015年に登場した VSCode は、最初からしっくりくるツールのように感じられた
    • モダンに見え、比較的軽量だった
    • 当時の設定エディタは設定パネルではなく JSON ファイルベースで、制御しやすいと感じた
  • Go と Rust を学び始めると、VSCode の各言語向け LSP 統合 が大いに役立った
    • コード補完
    • リアルタイムのエラー強調
    • 学習速度の向上
  • Google で Bazel を使う Java プロジェクトを扱っていたときは、IntelliJ が自然な選択肢だった
    • Emacs で Java 開発を試したこともあったが、IntelliJ が非常に優れていたため、現実的な選択肢は IntelliJ だった
  • Microsoft で C++ コードベースとリモート Windows マシンを扱っていたときも、VSCode と Vim プラグインを使い続けていた
    • 多くの人は RDP でリモートマシン上で直接作業していた
    • ローカルデスクトップで VSCode を起動し、SSH でリモートマシンに接続するやり方のほうを好んだ

Snowflake で Doom Emacs に戻ったきっかけ

  • 2022年に Snowflake へ移ってから、開発は古い Linux VM の中で行われ、日常業務は shell script と Bazel build file の作成が中心だった
  • この環境では VSCode や IntelliJ は問題を解決してくれず、リモートのグラフィカル環境の制約も嫌だったため、SSH でローカル VM に接続するやり方へ戻った
  • 長時間作業向けのエディタが再び必要になり、選択肢は Emacs だった
  • 以前の init.el には長年積み上がった数百行の設定があったが、内容を十分理解できていなかったため、すべて捨ててやり直したいと思った
  • この時点で Doom Emacs に出会った
    • Doom Emacs は Emacs をあらかじめ構成した「ディストリビューション」である
    • 合理的なデフォルトを提供する
    • 事前定義された言語統合を提供する
    • 元 Vim ユーザーにとって親しみやすい体験を提供する
    • IDE だとは主張していないが、実際の使い心地は IDE のように感じられる

Doom Emacs が変えた利用体験

  • Doom Emacs を設定したあと、Emacs は 2015年の VSCode のように再び「しっくりくるツール」だと感じられた
  • 多くの Emacs 機能が space ベースのショートカット の先にある対話的なポップアップメニューとして現れ、発見しやすくなった
  • Vim スタイルのキーバインドと共存しながら、手首への負担が少ないショートカットの流れを提供する
  • 設定は 3 つの単純なファイルに分かれている
    • config.el: theme、font などのグローバル設定を指定
    • init.el: 有効化する Doom 専用モジュールを選択
    • packages.el: Doom に含まれていないパッケージをインストール
  • デフォルトは合理的で、調整できる細部には十分なコメントが付いている
  • LSP の進化と tree-sitter のようなモダンな機能により、Emacs は今では IDE のように感じられる
    • 扱う必要のあるほとんどの言語で、適切な言語統合が得られる

どこでも同じ開発環境を使える価値

  • 最も強力な機能は、どのマシンで作業していても 同一の開発環境 を得られることだ
  • 作業対象には MacBook、Linux laptop、Linux cloud workstation、個人の FreeBSD server まで含まれる
  • 必要なのは shell、tmux、Emacs だけだ
  • さまざまなマシンで働くとき、同じ環境と 筋肉記憶 は生産性に直結する価値を持つ
  • この必要性のため、Emacs は過去よりもさらに重要なツールになっている

Doom Emacs はやりすぎなのか

  • Doom Emacs には「やりすぎだ」という不満もあるが、実際に多くのことをやってくれるからこそ便利でもある
  • いずれは Emacs 自体をもっと学ぶために、構成を減らせるかもしれないと考えるようになった
  • 近年では、さまざまなモダンなサードパーティモジュールが標準の Emacs パッケージへ取り込まれていく流れも、こうした考えを強めている
  • 最近は Bedrock や Emacs Solo ディストリビューションも試してみたいと思っている
  • ただし移行に必要な 起動エネルギー は高く、その道を選んだとしても、結局なぜ「raw」Emacs まで行かないのかを再び自問することになりそうだ

Elisp、Org mode、Magit への距離感

  • Emacs が Elisp ベースであることで、人々のワークフローをどれほど大きく変えるのかはいまだ完全には理解できていない
  • Emacs の中でより多くのロジックやワークフローを実装することはできるが、すでに shell script でほとんどすべてを簡単に処理できている
  • script のほうが「Unix is my IDE」という観点では、より Unix らしく感じられる
  • Org mode や Magit が独立したアプリケーションではなく Emacs の背後に縛られている点は気に入らない
  • 異なるリモートマシンで作業を続ける必要がある限り、Emacs は依然として重要なツールであり続ける

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見

  • この文章は、テーマがあまりにもおかしくて書いたもの
    特定の質問が理由ではなく、会社の上の職位の人たちがCLIベースのコーディングエージェントを使う中で、コマンドラインツールを「発見」し、その新発見がいかに便利かを見せようとしている様子を見ているから
    これまでの代表例はtmuxで、次はVimやEmacsの存在にも気づくのを待っているところ
    こうしたツールはずっと前からそばにあり、会社の「上級10x開発者」に聞けば、おそらく使っていると言うはず
    それなのによく「はは、それ古代の遺物でしょ。Webに行こう!!11」みたいな扱いを受けてきた。もしかすると、その開発者たちがこうしたツールを使い続けているのには理由があったのかもしれない ;P

    • 「低品質な生成物バブル」のよい点のひとつは、プレーンテキストが再び有効で重要な媒体になっていること
      CLIがより一般的になり、口伝えだった知識の多くが文書化されることも含まれる。もちろん、人間が作った知識であることが前提
      今の困った時期を過ぎても、こうしたよい部分は残ってほしい
    • Emacs利用者の大半は、おそらくGUIで使っている気がする。数字はないけれど、圧倒的多数だと思う

  • 自分もようやく学び始めた側に入る
    数年前にDoom Emacsを使ってみたが、遅延が気になるほど遅くて離脱した。ネイティブコンパイルのおかげで今では過去の話なのかは分からないし、まだ設定なしの素のEmacsなので体感しにくい。Nixpkgsの30.2を使っていて、デフォルトでネイティブコンパイルが有効になっているようだ
    Emacsでメールを書く機能のようなものにはあまり興味はなく、自分の望む形に作り込めるエディタが必要。あとでLispを学びたくなったときにも使えるとよくて、たぶんJanetになると思う。Helixはまだプラグインがないので、Lisp系は選択肢がほとんどない。「すべてはテキスト」という哲学も気に入っているが、実際に自分に合うかはまだ分からない
    2026年に学ぶには敷居が高い面もある。何十年も積み上がった暗黙知のせいで、記事を読むとパッケージ名やコマンド名などが次々に出てきて、こちらはただ $THING をやりたいだけなのに圧倒される。だから案内付きの学習ルートとして Mastering Emacs を手に取った
    デフォルトのキーバインドもかなり変わっている。全部再バインドできるのは分かっているが、やることが増える。しかも分離型のエルゴノミクスキーボードを自作し、修飾キーを作業の中心に使わないVim/Helix風の作業スタイルに合わせてファームウェアも調整済み
    MacBook Pro、PC、カスタムキーボードの3種類を行き来するので、頭が溶けない一貫したキーバインドを見つけなければならない。hjkl はどのキーボードでも同じ位置だが、Ctrl のようなキーはそうではない

    • キーバインドが難しくてVim系に慣れているなら、evil を見てみる価値がある
      evilは「Emacsの真の福音」を学びたくないVim難民向けだと説教されるかもしれないが、Emacsの真の福音® とは、自分にいちばん合う方法で使うこと
      1998年からEmacsを使っていて、Vim愛好家ではまったくなかった。2011年ごろに手首の反復運動障害の問題が少し出て、それを減らしてくれるパッケージを試し、数年間は god mode をかなり使ったが、それでもなお不自然だった
      そこで「うまくいかないことを証明するために」、それまで一度もVimを使ったことがない状態でevilを試したところ、1週間でgod modeと同じくらい使いこなせるようになり、1か月後には公式のEmacsキーバインドを使っていたときより速くなっていた
      だからといってデフォルトのキーバインドが間違っているという意味ではない。自分は手首が弱いので、経験は違うかもしれない。boon や meow のほうが合うこともある
      ただ、evilが合うなら罪悪感を持つ必要はまったくない。Emacsがユーザーを変えることもあるが、それ以上にEmacsはユーザーのために大きく変わってくれる
    • Doomはどう設定するかで本当に変わる。その点も時間とともに改善され続けている
      いちばんよいのは自分で構成することだが、手間はかかるし、Doomのようなプロジェクトは新規ユーザーの導入を確実に楽にしてくれる
    • デフォルトのキーバインドが変わっている点が、むしろDoom Emacsで気に入っていた部分だった
      以前はデフォルトのEmacsキーバインドをかなり知っていたが、自然だと感じたことはなく、とくに発見しやすさが低かった
      Doom Emacsはほとんどすべての操作にSPCプレフィックスキーを使い、少し止まると可能な補完を説明する一時メニューが出るので、かなりよかった。知らなかった機能を見つけられるし、Vimのモーダルモードとも衝突しない
      だからテキスト編集はVimモード、Emacsの操作はSPCの組み合わせ、という構成がよいバランスに感じられる
      Emacsデフォルトのキーバインドにも利点はある。基本的なテキスト操作キーはreadlineや、さらにはmacOSとも共有されている。macOSのEmacs風テキスト編集キーがVSCodeにも広がっていて、標準のクリップボードキーとも衝突しないので、macOS上のVSCodeはかなりよかった
      WindowsとLinuxに移ってからは、VimプラグインなしのVSCodeには到底耐えられなかった
    • Helixから来たなら、meow を見てもよい
      KakouneやHelixに近い機能を素で提供すると聞いていて、あまり邪魔をしない方向らしい。どちらも自分で使ったことはないので、聞いた話に基づく
      勧められていたevilパッケージはキーバインドをあまりに多く掌握し、外部パッケージとうまくなじまないので、「アダプター」パッケージがたくさん必要になるという問題があると思う
      meowは一度設定してしまえば、かなり手がかからないほうだった

  • 33年使っているが、エディタやIDEに必要なことは全部やってくれる

  • Doom と (n)vim の間を行ったり来たりしていたが、最近はほとんど Neovim に落ち着いた。
    Emacs を使っていて感じた最大の問題は、皮肉なことにメンテナンスがつらいことだった。Doom をアップグレードするとパッケージ同期がずれて、完全再インストールという核爆弾級の選択肢しか残らないことがよくあった。
    もちろん、もっと「初心者っぽくない」やり方で直せたのかもしれないが、ある時点からは単に道具が動いてくれることだけを望むようになった。やるべき仕事があるのに設定が壊れ、エディタに過度に依存している状況はなかなか耐えがたい。
    それでも org-mode と Emacs 全体のナビゲーションの流儀は恋しくなる。
    VSCode や CLion のような「現代的」な解決策を試すたびに、同じ問題をもっと多く経験する。まともなアクセシビリティ機能がないせいで、純粋なキーボード操作ではなく不格好にクリックしなければならず、「Vim」動作も本物と比べれば不完全だ。
    今 Neovim を使っている理由は、単にちゃんと動くからというだけ。正直、コーディングエージェントに設定を直してくれと 2 分頼んでいれば、今の Emacs についても同じことが言えた気がする (:

    • Doom の update 機能は何度か試したが、いつも問題が起きた。
      最近はアップグレードしたくなった時や Emacs のアップグレードで必要になった時に、そのたびに rm -rf ~/.emacs.d/ で消して Doom を最初から設定している。~/.doom.d/ はバージョン管理に入れてある。
      このやり方では問題は起きていない。

  • 開発も、文章書きも、メールも Emacs でやっている変わり者で、そうしてもう 15 年くらいになるが、elisp を学ぶ時間や余裕は結局見つけられなかった。
    設定ファイルをいじる時でさえ、自分が実際に何をしているのかよく分かっていない。それでもなお一番生産的な環境であり続けるというのは、このエディタがどれほどすごいかを物語っている :-)
    Mastering Emacs をきちんと読むことは、認めるのも恥ずかしいほど長い間やることリストに残っている。

    • 私もほぼ同じだ。設定を直したり編集したりしているうちに、浸透するように elisp を少し覚えたが、実際に知っている量が少なすぎてちょっと気まずい。
    • M-x high-five
      自分の場合もパッケージはごく少ししか使わず、元のキーバインドを使っている。実際には high-five 関数なんて存在しないが、これを機にようやく elisp を掘ってみるかもしれない。

  • Vim のレンダリングが気に入らず、Electron/VSCode 系にも飽きて、2 年ほど前に Emacs に移った。
    avy といくつかのジャンプ系プラグインに惹かれたが、使い続ける決め手になり、今でもコード変更の主力ツールとして使っているのは magit だ。

  • 仕事で相手にしている顧客企業は、事業全体が非常に大きな CSV ファイルの活用に依存しているのに、そちらでは 1GB ファイル のデータを開いたり確認したりする方法を知っている人がいないように見える。
    CSV ヘッダーを送ってほしいと言う時に使う head コマンドすら知らない。

  • 何年も X/GUI で使っていたが、たった今 -nw に切り替えた。
    発表する時だけ Pgtk バージョン を使っている。