ハクソク

世界を動かす技術を、日本語で。

Kilo: 1000行未満のコードで構築されたシンタックスハイライトと検索機能を持つテキストエディタ

371日前原文(github.com)

概要

  • Kilo は、1000行未満で構成された 小型テキストエディタ です。
  • 主要な キーバインド や機能が明確に定義されています。
  • 外部ライブラリ に依存せず、標準的な端末制御シーケンスを利用します。
  • BSD 2条項ライセンス で公開されており、カスタマイズや学習に適しています。
  • 作者は Salvatore Sanfilippo (antirez) です。

Kilo：1K行未満の小型テキストエディタ

概要・特徴

  • Kilo は、コード量が 1,000行未満 のシンプルなテキストエディタであることを強調
  • cloc コマンドで行数カウントを実施すること
  • screencast （使い方動画）はasciinemaで確認可能
  • 端末上 で動作し、追加の 外部ライブラリ （curses等）に依存しない設計
  • VT100互換端末 のエスケープシーケンスを利用すること

基本的な使い方

  • コマンド：kilo <filename>でファイルを開くこと
  • キーバインド一覧
    • CTRL-S ：ファイル保存
    • CTRL-Q ：エディタ終了
    • CTRL-F ：検索モード起動（ESCで検索終了、矢印キーで結果移動）
  • 直感的な操作性 を重視した設計であること

開発背景・活用方法

  • alpha段階 のプロジェクトであり、短時間で開発されたことを強調
  • Salvatore Sanfilippo (antirez) による執筆と公開
  • 既存のプロジェクト（ load81, linenoise）のコードを一部流用していること
  • より高度なエディタやCLIツールの 出発点 ・テンプレートとして活用推奨
    • REPL型CLI よりも発展的なインターフェースの開発に利用すること
  • BSD 2条項ライセンス で自由に利用・改変可能であること

ライセンス・著作権

  • BSD 2-Clause License に基づき公開
  • Salvatore Sanfilippo (antirez) が著作者であることを明記
  • 利用・改変・再配布に関する 権利と条件 を確認すること

Hackerたちの意見

ちょうどいいタイミングだね、さっきkiloみたいなテキストエディタをゼロから作るチュートリアルを終えたところだよ: https://viewsourcecode.org/snaptoken/kilo/index.html このチュートリアルは本当に良くできてるから、めっちゃおすすめだよ。

└

そのチュートリアルに対する2つ目のおすすめだよ。これが私が終えた初めてのコーディングチュートリアルで、本当に良かったし、自分の技術が頼っている基盤となるソフトウェアを作るのが楽しかったんだ。あのエディタは使ってないけど、作るのは楽しかったよ。

└

あのチュートリアルは懐かしいな。リリースされたときにkiloで遊んで、最終的には埋め込まれたLuaでスクリプトをサポートするマルチバッファ版を作ったんだ。もちろん、真剣なものではなくて楽しいハックだったけど、最高のプロジェクト名を選べたのは良かった: https://github.com/skx/kilua

└

これは、異なるプログラミング言語で遊ぶための好きな中程度のプロジェクトの一つだ。元のC版: https://git.timshomepage.net/tutorials/kilo Go版: https://git.timshomepage.net/timw4mail/gilo Rust版: https://git.timshomepage.net/timw4mail/rs-kilo そして、もっとRustっぽいチュートリアル版（Hecto）: https://git.timshomepage.net/tutorials/hecto PHP版: https://git.timshomepage.net/timw4mail/php-kilo ...そしてTypescript版: https://git.timshomepage.net/timw4mail/scroll

このコードを読むのは、まさに通過儀礼みたいなもんだね。Cがどう動くか、テキストエディタがどう動くか、VTコードがどう動くか、シンタックスハイライトがどう動くか、検索機能がどう動くか、便利さやエッジケース、エラーハンドリングをほとんど取り除いたときに、実際に何を作るのにどれだけ少ないコードが必要かを学べるんだ。

それがこの似たようなRustプロジェクトにもインスピレーションを与えたよ: https://github.com/ilai-deutel/kibi#comparison-with-kilo ただ、Unicodeをうまく扱うためにちょっとズルしてる部分もあるけどね: > unicode-widthを使ってUnicode文字の表示幅を決定してるんだ。残念ながら、これを回避する方法はないよ: unicode文字幅テーブルは230行もあるから。

└

それがこの似たようなRustプロジェクトにもインスピレーションを与えたよ そしてこれらのプロジェクトもね: https://github.com/antirez/kilo/forks

└

個人的には、極端なサイズ削減にはあまり納得できない理由がこれなんだ。こういうプロジェクトは、一般的に必要な機能を犠牲にしなきゃいけないから、ある程度のコード量は必要なんだよね。

面白い話なんだけど、kiloを使ったのがターミナルを諦める決定的なきっかけだったんだ。[1] 最近は、ピクセルを描けるシンプルなキャンバスの上でプログラミングするようにしてるよ。最近ずっと使ってるテキストエディタはこちらだよ（たくさんのフォークのベースにもしてる）: https://git.sr.ht/~akkartik/text2.love。1200行のコード、比例フォント、ワードラップ、スクロール、クリップボード、無制限のアンドゥ。モビー・ディックも編集できるよ。[1] https://git.sr.ht/~akkartik/teliva

└

最近は、ピクセルを描けるシンプルなキャンバスの上でプログラミングするようにしてるんだ。なんでかって？

└

ターミナルを避けてそれを置き換えた他の誰か: https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...

└

へい、アッカーティック！それ、めっちゃ面白いね！今はまだターミナルを使って個別のアプリを起動してるの？

└

これは面白いコンセプトだけど、こういうエディタはコードを書くのにどうなのかな？

Kiloは楽しい週末プロジェクトだけど、自分のテキストエディタを作る基盤には向いてないってことを痛感したよ。コアデータ構造（行の配列）が、もっと複雑な操作にはあまり適してないんだ。とにかく、これが私が作ったものだよ: https://github.com/lorlouis/cedit もしもう一度やるなら、ピーステーブルを使うかな。[1] https://en.m.wikipedia.org/wiki/Piece_table [2] https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

└

コアデータ構造（行の配列）は、もっと複雑な操作にはあまり向いてないんだよね。現代のCPUはメモリを毎秒数十ギガバイトで読み書きできるし。CPUが3桁遅かった頃でも、単一の配列を使ったテキストエディタは広く使われてた。もし操作の中に偶然に二次的、あるいはそれ以上のアルゴリズムを導入しない限り、このアプリケーションでは複雑なデータ構造は必要ないと思うよ。

└

コアデータ構造（行の配列）は、もっと複雑な操作にはあまり向いてないんだよね。どれくらいの大きさ（行数）があれば問題になるの？そして、どんな複雑な操作が問題にするの？（議論するつもりはないけど、本当に知りたい！）自分のテキストエディタ（2004年にソースを失ったやつ）では、バイトの配列を使って、構文ハイライトもあった（構文ハイライト用に単一バイトの開始・終了コードを使った）し、描画には配列の「ウィンドウ」を動かしてた。あの頃のPentium Proでは、20MBのファイルでも遅延問題は見なかったよ。VS Codeで使われているピーステーブルがそんなに速いとは思えない。今の2011年のデスクトップでは、余分なプラグインなしのVS Codeで、上矢印・下矢印キーを押し続けてスクロールすると目に見える遅延があるし、キーボードのリピート設定もすごく高い。同じコンピュータ、同じキーボードリピート、同じファイルでVimを標準のxterm/uxtermで使うと、スクロールは明らかに良い。ファイルの終わりに到達するのにかかる時間は半分（約10,000行）。

└

自分のエディタはRubyで行の配列を使ってて、今8年間毎日使ってるけど、実際のエディタがバッファストレージとIPCでサーバーとやり取りしてるから、問題にはなってないよ。100MBのテキストファイルを開こうとすると問題になるけど、メインエディタでそれをテキスト編集の問題として扱うつもりはないんだ。そんな大きさのファイルは、通常は見るだけか、コードで操作する方がいいからね。巨大なファイルを開いて操作したいなら、君の言う通りだし、そういうシンプルな方法を使ったエディタは君には合わないだろう。それはそれでいい。今のところ、私のエディタは過去8年間に開いたことのあるファイルを常にメモリに保持してる（現在5420バッファ；バッファストレージは1分ごとにディスクに保存されるから、再起動して同じファイルを開いても、明示的にリロードしない限り未保存の変更はそのまま残ってる）し、通常は私のマシンのメモリ使用量のトップ50にも入ってない（それは全部ブラウザのタブだし…）。人々が必要に応じて「もっと洗練された」データ構造を使うべきじゃないとは言ってないよ。巨大なファイルを扱えるエディタがあるのは素晴らしい。ただ、非常に単純なアプローチでも多くのユースケースにはうまくいくんだ。例えば、今私のエディタに5420のオープンバッファがあるのは、オープンバッファをガベージコレクトしないという単純なアプローチが問題になってないからで、私の利用可能なRAMはバッファストレージのサイズよりもずっと早く増えてるから、彼らを整理するメカニズムを追加する優先度がまだ上がってないんだ。

これはNanoの素晴らしい代替案のようだね；ただ、Nanoは本当に良くて、ちゃんと動くんだよね。

面白いことに、その1000行のコードの中には削除できる部分もあったりするんだよね。例えば、Cライブラリのcfmakeraw()関数を重複してるし。 https://man.freebsd.org/cgi/man.cgi?query=cfmakeraw&sektion=...

ああ、くそ。リタイアが近づいてる（絶対にそんなことはないけど、コーディングは利益や慈善のためにやるには楽しすぎる）年齢になってきたけど、エディタを作りたいんだ。必要なんだよね。vimやemacs、eclipse、vs codeをめっちゃいじったけど、全部クソだよ（新しいほどひどい：小学校を過ぎたら使わないような無駄なギミックばっかりで、パワーユーザー向けの機能が足りない）。もっと良いものを作れるかな？これはいいスタートに見えるね。

私もLazarusを使って似たようなエディタを作ったことがあるよ…シンタックスハイライトのコンポーネントがあるから…ちょっとズルいかな。考えれば考えるほど、FreepascalがNeovimのためにいいGUIを作れるかもって思う。数年前にC++でQtを使って作ろうとしたけど、シンタックスハイライトの追加方法が分からなくて止まっちゃった。Notepadみたいに動くように方向転換したから、最終的には満足してるよ。 https://github.com/Giancarlos/qNotePad