2 ポイント 投稿者 GN⁺ 2023-08-19 | 1件のコメント | WhatsAppで共有
  • microはターミナルで使うテキストエディタで、nanoのようにシンプルに始められつつ、よりモダンで直感的な操作を目指している
  • 依存関係のない静的バイナリとして配布されており、インストールの負担が小さく、公式リリースのダウンロードと詳細なインストール手順も提供している
  • オプションとキーバインディングはJSON形式で変更でき、さらに深い拡張はLua設定とプラグインで扱える
  • 75以上の言語のシンタックスハイライト、7つの標準カラーテーマ、16/256/truecolorテーマ、Sublimeスタイルのマルチカーソル、マウス操作に対応している
  • 内蔵ターミナルエミュレータにより、エディタ内で対話型シェルを実行でき、分割画面でコードとbashを並べて表示できる

ターミナルエディタとしてのmicro

  • microターミナルベースのテキストエディタで、モダンで直感的な使いやすさを掲げている
  • Downloadから最新リリースを入手でき、詳細なインストール手順も確認できる
  • curl https://getmic.ro | bash方式のサードパーティ製pipe to shellスクリプトがあるが、これはmicroの管理下にはない
  • インストールの利便性のため、依存関係のない静的バイナリとして配布されている
  • 設定と拡張

    • オプション設定とキーの再バインドにはシンプルなJSON形式を使う
    • より強力な設定が必要ならLuaを使える
    • プラグインはLuaで書かれており、プラグインマネージャが自動ダウンロードとインストールを処理する
  • 編集機能

    • 75以上の言語のシンタックスハイライトに対応している
    • 標準カラーテーマを7つ提供している
    • 16色、256色、truecolorテーマを利用できる
    • Sublimeスタイルのマルチカーソルに対応している
    • bindings.jsonでキーバインディングを変更できる
  • マウスと内蔵ターミナル

    • クリックとドラッグでテキストを選択できる
    • ダブルクリックは単語単位の選択、トリプルクリックは行単位の選択に使われる
    • micro内で実際の対話型シェルを実行できる
    • 分割画面で片側にコード、もう片側にbashを表示できる
    • 全機能の一覧はGitHubの機能一覧オンラインヘルプで確認できる

プロジェクトとコミュニティ

  • バグはGitHubのイシュートラッカーで報告でき、質問や新機能の提案も可能
  • Pull requestを受け付けている
  • エディタについての非公式な議論はGitterチャットで行える
  • 関連リンク:
  • ユーザーの反応には、シンプルに動作するエディタ、マウス対応、nanoやVimの代わりに使えるという評価が含まれている

1件のコメント

 
GN⁺ 2023-08-19
Hacker News の意見
  • 全員が初心者の授業でコマンドラインプログラミングを学ぶとき、学生には nano を勧めている。
    こうしたユーザーにとって nano の最大の利点は、すべてのコマンドが画面下部に表示されることだが、micro にはそれがなくて驚いた

    • micro と nano の違いは、nano のキーボードショートカットがかなり独自なのに対し、micro は最近の多くのグラフィカルアプリで使われる Ctrl+S で保存、Ctrl+F で検索、Ctrl+Z で取り消し、Ctrl+Q で終了といった方式に従っている点だ。
      画面下部には、Alt+G を押すとショートカットを見られ、Ctrl+G でヘルプを見られるというヒントもある
    • micro の意図は、初心者向け、あるいはどこにでもあるエディタというより、モダンで拡張可能なエディタに近いように見える。
      そういう意味では、学生には今でも nano を勧めるのが正しく、micro は nano で学んだ後、より多くの機能やより良い UI を求める人に向いているようだ
    • Alt+G を押すとショートカット画面が出るようで、Ctrl+G はヘルプを表示する。
      ある種のコメントモードもあるようだ
  • Emacs を10年以上使ってきたが、今は micro をメインのコードエディタとして使っている。Coq の作成だけは例外で vscode を使っている。
    micro をモダンに折り合いをつけた acmeと見ており、acme の中核アイデアを支える機能がほぼすべて備わっている。この方向性を活用するためにプラグインも作った: https://github.com/xxuejie/micro-acme
    今のところ完全にしっくりきている

    • 最近は Emacs の機能の1%程度しか使っていないので、Emacs の代替として軽量なターミナルエディタを試し続けているが、C/C++ などの一般的な Emacs メジャーモード、特にインデント方式がかなり恋しい。
      Tab で正しいインデントを強制する慣例を、他のエディタにも採用してほしい
    • micro についてよく知らないので聞きたいのだが、ここ1〜2年で開発ペースが落ちた理由があるのか気になる。
      https://github.com/zyedidia/micro/tags
    • 同じように Emacs から Acme に移り、ターミナルでは mg を使っている。
      今では Micro をカスタマイズしてAcme っぽさが出るようにしている
  • nano をメインのコードエディタとして使っている人がいるとは思わなかった。作業中の *nix サーバーではいつも使っているし、おそらく何万回も使ったはずだ。
    長年 Linux/BSD エンジニアとして働いてきたが、サーバーに nano を入れるのを拒む職場もあった。vi 以外は絶対に使わせない古参の Linux 管理者がいるが、理解できない。20MB のパッケージで、攻撃対象領域もそれほど大きくない

    • 古参は結局、古参らしく振る舞うものだ。
      旧世代の人にどんなシステムを運用していたのか聞くと、自分の地域政府の IT 部門全体を任されていて、かなり大きな町だったのでユーザーも少なくとも500人くらいいた、と自慢げに話すことがあって、いつも笑ってしまう。
      そのシステムは郡全体で最も安全だったと105%確信しているが、同時に使用不能なシステムだったはずだ。その人が退職するか、オフィスの誰かが絶望の末に排除したら、vi は知らなくてもユーザーのことを少しは気にする新しめのエンジニアに置き換わってほしい。もちろん自分たちもエンジニアなので、そこまで気にはしないだろうが
    • Unix 管理者が vi を隅々まで知っておくべき主な理由は、Unix と Linux システムにおける最小公分母だからだ。
      *nix 技術者として働くなら、QNX、HP-UX、SGI Altix スーパーコンピュータ、Sun Ultra 2 のようなシステムを扱うことがある。Linux は自由/オープンソースソフトウェアのパッケージ管理があるので楽だったし、nano が普及する前はデフォルト構成に Emacs が入っていることもよくあった。
      ときには端末の問題で1行しか見えない状態で作業しなければならず、その場合は見えないまま vi を操作するか、sed/awk を使う必要があった。だから全員に vi を覚えさせようとする KISS 的な本能が残っているのかもしれない。自分もそうやって覚えた。
      エディタ1つが大きな攻撃対象領域を作るわけではないが、攻撃者がプラグイン機能を永続化の手段として悪用する可能性は排除しない。root で実行するときは挙動が違うだろうが、サービスアカウントではそうでないかもしれない
    • 20MB というには、nano の実行ファイルは277KBで、.deb パッケージ全体でも860KBだ。
      https://packages.ubuntu.com/jammy/nano
    • もともと nano ユーザーだったが、古参たちに押されて vim を使うようになり、今では vimrc ファイルを整理しなければならないときだけ nano に触る。
      当時は腹が立ったが、今では乗り換えてよかったと思っている。Vim や vi は、自分が作業するスイッチやルーターまで含めてどこにでもある。nano はどこにでもあるわけではなく、どこにでも簡単に入れられるわけでもない。
      古い、あるいはリソースの乏しいハードウェアに定期的に SSH 接続していなければ、この利点はあまり感じなかったと思う
    • 個人的には nano がとても嫌いなので、いつでも vi を選ぶ。
      ただしテキストエディタの選択は非常に個人的なことだ。誰かが他人に特定のエディタを使え、あるいは使うなと強要するのはまったく筋が通らない。好きなものを使わせておけばいい
  • JOE はかなり良い: https://joe-editor.sourceforge.io/
    WordStar と Emacs の混合型で、jstar として起動するとかなり本物らしい WordStar 体験を提供しつつ、初期の Borland Turbo IDE っぽさも残っている

    • JOE は本当に好きだった。おそらく WordStar の名残があったからだと思う
      今でも Linux で WordStar Diamond キーを使う方法についての記事を書いている: https://benhoyt.com/writings/wordstar-diamond/
    • 初めて使ったワープロは CP/M の WordStar で、最初のプログラミング環境は Borland Turbo Pascal だった
      後には WordStar キーを使うように設定できる QEdit も使った
      90年代初めに DOS から Unix に移ったとき、JOE を見つけてうれしかった。新しい Linux や *BSD マシン、VM に最初にインストールするプログラムだ
      最近の JOE には構文ハイライトや良い機能がいくつもあるので、vi や emacs に習熟しなければならないと感じたことはない
    • 90年代に、コード編集以外ではほとんど何でも joe を使っていた良い思い出がある
      コード編集にはあまり向いておらず、自動改行や構文ハイライト不足など、ワープロモデルに近かったからだ
      でもテキスト文書を書くには愛らしい小さなエディタだった
    • モードごとの違いやキーバインドはマニュアルに文書化されていないのだろうか?
      たぶん自分が見つけられていないだけかもしれないが、本当に見当たらない
    • よく jmacs として起動して Emacs キーボードショートカットのセットを使っている
  • micro が好きで毎日使っている
    ただ Helix を試してみたら、micro に treesitter、LSP、コンテキストヘルプが組み込まれた形が欲しくなった。Helix はその機能セットを本当にうまく実現しているが、「単一モード + コマンド」と Ctrl-C/Ctrl-V のマッスルメモリーがあまりに楽で、移行しづらい

    • Helix を6か月ほど毎日使っているが、基本機能が全部そろったエディタである点が本当に良い。素晴らしいエディタだ
  • なぜいまだに、インターネットからダウンロードしたものに sudo を実行しろと言うソフトウェアがあるのか分からない
    もっと簡単で安全で、インストール容量も小さく、すべてのディストリビューションに組み込まれている選択肢があるのに、なぜそんなスクリプトを使わせるのか疑問だ
    比較すると、Alpine の micro パッケージはインストール後 4MB だが、GitHub からダウンロードする静的コンパイル済みバイナリは 11MB だ。リポジトリのパッケージを使うほうがより micro らしいと思う

    • 本当に sudo を実行させるのか?
      https://github.com/zyedidia/micro#quick-install-script を見ると、クイックインストールスクリプトは curl https://getmic.ro | bash で、スクリプトは micro バイナリを現在のディレクトリに置く
      その後、望むならパス内のディレクトリへ移動でき、例として sudo mv micro /usr/bin を挙げている。/usr/bin に移すには sudo が必要だと知らせているだけで、それが問題なのかという気がする
    • インターネット上の任意のソースを sudo や (ba)sh にパイプしろと勧めるのは完全に無責任
      「みんなそうしている」というばかげた正当化にも、もううんざりだ
    • 個人的には、アプリケーション開発者と自分の間に仲介者が入るのは望まない
      アプリケーションは開発者から直接受け取りたい。そうすれば公式にサポートされたバージョンを使っていて、コードに誰かが手を加えていないことを確認できる
      アプリケーション開発者を信頼できないなら、そもそもインストールしない
  • Nano は Pico の現代的な代替だと思っていた

  • なぜこういう小さなエディタに関心を持つのか気になる
    vi/vimを使う唯一の理由は、どこにでもあるから。エディタをインストールするならEmacsを入れる
    リモートシステムならtrampでSSH越しにファイルを開き、ローカルEmacsのすべての性能と速度をそのまま維持する。sudoedit、git commit、C-x C-eのようなターミナルUIでの編集にはEmacsをデーモンとして起動しておくので、新しいフレームやターミナルフレームも即座に開き、nerd fontや配色まで含めてEmacs GUIとほぼ同じで、文字どおりEmacsそのもの
    用途別に複数のエディタを持つ必要はない

    • Linuxを20年以上使ってきた人間だが、viは最後まできちんと理解できず、直感的ではないと感じる
      Emacsのほうが魅力的だったし、OpenWRTが動くルーターのような低消費電力デバイスにssh接続するとEmacsがないので、使えるエディタの中で直感的に見えるNanoを使う
      EmacsとTRAMPを使えることも分かっているが、誰にでも自分なりのワークフローがある。viをけなすつもりはなく、ハッカーの一部がviに馴染めないという現象はよく知られている
    • 誰もが巨大なエディタや急な学習曲線に関心があるわけではない
      ただファイルを素早く修正したいだけの人もいる
      Windows NotepadやMac SimpleTextで既に知っている知識で使え、壊れたマシンやサーバーマシンでUnixコンソールしかない状況でも動作する
    • こういう小さなエディタそのものに関心があるわけではない
      ただしnanoのような小さなエディタには大いに関心がある。理由はこのルートコメントにある: https://news.ycombinator.com/item?id=37173126
      ここの最初の段落も参考になる: https://linuxize.com/post/how-to-use-nano-text-editor/
      viやvimとともに育ったわけでもなく、emacs陣営を選んだわけでもない今日のシステム管理者のために、大量配布イメージにnanoを入れておくことは礼儀ある選択だ
    • 自分が触れるすべてのOSにはNanoがある
      リモートで何かを頻繁に編集するわけでもなく、たいていは簡単な設定ファイルだけ
      microも使ってみて気に入ったが、Piではすぐには開かなかったし、コマンドラインエディタとしてその機能がどうしても必要になるほど大きな作業はしない
    • microを使う理由は、大した労力なしにカスタムプラグインを開発でき、まともなターミナルエディタがないシステムにもコピーするだけで簡単に配布できたから
      普段はvimを好むが、対象システムにまともな設定を配布するのにかかる労力が大きすぎる
  • microで遭遇した問題はリッチな貼り付けだった
    コード片を貼り付けるとmicroが各行でインデントしようとするが、全体の文脈を知らないため、貼り付けたテキストのインデントがどんどん無限に深くなっていった
    行ごとに書式を推測するため、処理もほとんど止まるほど遅くなる。貼り付けてマトリックスのような場面を眺めている代わりに、コーヒーを取りに行くことになる
    解決していることを願うが、その時点で離れた。解決済みならまた試してみてもいい

    • 無効化できる: Ctrl+Eの後にset autoindent off
      https://github.com/zyedidia/micro/blob/master/runtime/help/o...
      それでも有効な状態でも、ブロック全体を貼り付けるときは正しくインデントされるべき
      設定、環境、構成を共有してくれれば、パッチを作ってみることができる
    • WindowsでWezterm経由で使ったとき、一度そういうことがあった
      貼り付け方によって変わる。正確にどう動くのかは100%確信がないが、microはxclipで直接貼り付けを再実装しているようで、Windowsでは何をしているのか分からない
      Ctrl+Vで貼り付けると、クリップボードの内容をブロックとして即座に挿入し、元のインデントをコピーする。Ctrl+Shift+Vを使うと、ターミナルからクリップボードが文字単位で1文字ずつ流れ込んでくるように処理される場合があり、次の文字を知らないまま改行文字を見ると追加インデントをしてしまい、その後に素朴にタブをいくつかさらに載せてしまう
  • 他の投稿14件のうち、2020年の記事はコメント103件、2021年の記事はコメント162件だった
    [0]: https://news.ycombinator.com/item?id=23334190
    [1]: https://news.ycombinator.com/item?id=29128702