ファイラー機能とテキストエディタ

『PileLink』は、ローカルで動作する、ファイラー機能をもつテキストエディタです。

ファイラー機能とは、ふつうならシェルGUI（CUI）のもつ、ファイル作成、ファイル削除、ファイル検索、ファイル起動などの機能をもつ、という意味です。リンクやファイル操作の機能をもつため、テキストファイルとは異なります。

普通、テキストエディタとシェルは分かれていることが多いようです。目的が異なるのであれば、分かれていても別に問題はないです。

パンを焼くときに刺身包丁を使わないように、雨の日に雨避けとして鉛筆削りを持ち歩かないように、目的のことなる道具を別のシチュエーションで使うのは、かえって効率を妨げるからです。雨の中出かけるときに、手に鉛筆削りをもっていても、たぶんずぶ濡れになるだけです。

ただし、目的とは違っていても、目的外に役にたつものもあります。アポロ13は、存在しなかったフィルターを作ったわけです。

ところで、テキストエディタとシェルの目的は、雨の日の鉛筆削りほどに異なるのでしょうか、と考えました。

シェル機能をテキストエディタで

シェルで行う作業のうち、新規にファイルを作るとか、フォルダを作ってファイルを分けるなどは、ごく日常的なものです。

新規にファイルを作るとなると、必要なのがファイル名をつける作業ですが、それはシェルで行うよりも、テキストエディタで行ったほうが楽なのではないか、得意なのではないか、と考えます。

メニューから新規作成して、ファイル名をつけるなんて、けっこうかったるいです。

そうであれば、テキストエディタで新規にファイルを作る処理を実行したほうが、シェルで新規にテキストファイルを作るよりも、楽なのではないか、と。

それなら、テキストエディタにファイラー機能を実現した方が、より使いやすい道具なのではないでしょうか。きちんと使ったことはないのですが、たぶんUNIXのEmacsは、同じような発想でできているのではないかと思います。

『PileLink』の実装

そこで、『⁠PileLink』に、ファイラー機能を順次実装し始めました。まず最初に実装したのは次の機能です。

• 実行
• 新規ファイル作成（⁠『⁠超リンク!』機能）
• ファイル読み込み
• 新規フォルダ作成

それぞれの機能をざっくりと説明すると、次のようになります。

実行

選択範囲の[[ ]]の文字列のファイルを実行する。たとえば現在開いているファイルが日記で、その日記に書籍名が書いてあり、書籍がすでにデジタル化ずみである場合には、リンクを実行することで日記から書籍を読むことが可能になる。

実装上はさらに拡張し、URLや人名ならそれぞれ該当するファイルを開き、辞書があればそれにしたがって処理するようになっている。

実行メニューは、単に文字列を選択するだけで行えるように簡略化し、メニュー操作は不要にしてテストしている。

『PileLink』で文字列を選択すると、文字列に応じて処理を行います。たとえばイチローを選択すると、イチローをGoogle検索します。普通は、選択して処理をする、という2段階の操作が必要ですが、その手間を軽減しました。

新規ファイル作成（『超リンク!』機能）

選択範囲を新規のファイルとして作成保存し、選択部分を[[ ]]に置き換える。新規のファイルにはもとのファイルへのリンクを追記し、相互にリンクした状態にする。

ファイル読み込み

選択範囲の[[ ]]の文字列のファイルを、選択範囲に読み込み置き換える。

新規フォルダ作成

選択範囲の文字列のフォルダを作成する。

『PileLink』の応用プラン

これらにより、『⁠PileLink』は一種の統合型ファイルシステムや階層型のアイデアプロセッサとして利用可能になると考えられます。

たとえば、1行1項目で目次案を作り、新規ファイル作成を実行すると、その目次のファイルを一括して作成できるはずです。また、階層型のファイルは、任意に読み込むことができますし、開いて別ファイルとして、マルチウィンドウで整理することもできます。

さらに、フォルダのなかにあるテキストファイル群を、自動的に相互リンクする機能もテストしています。検索機能と統合すると、プレーンなテキストファイルを与えて自動実行して、ハイパーテキストを取得することも可能です。

これらはかなり使いでがあると思います。今後、フォルダや画像ファイルにも対応していき、画像や文字をシームレスにリンクしていくファイルシステムに拡張していく予定です。

実装と辞書

ふと思うに、たしか同じようなリンク型のシステムを、慶應大学の増井俊之教授がかつてPalmで実装していたようなおぼろげな記憶があります。

じっさいに実装してみたところ、5行ほどのコードでリンク機能を、辞書から読み込む実行機能も、辞書ごとの条件分岐が多いだけで、100行ほどで実装できています。おなじようなものがないのが不思議なほどシンプルです。

むしろ、条件を列挙した辞書を作るほうが手間のかかる作業です。テストのために、料理レシピ辞書、人名辞書(アドレスシステムを流用)などのほかに、仮面ライダー辞書と作家ごとの所有／既読チェックリストを作ってみました。

仮面ライダー辞書といって最初に想定したのは、7人とか12人の仮面ライダーの名前（仮面ライダークウガとか）の一覧だったのですが、調査してみると、ライダーマンは番組タイトルにはなっていないとか、仮面ライダーG3にはG3-XやG4のバリエーションがあるとか、映画版はどうするのかとか、変身前の場合はどうするかとか、未確認生命体第2号は仮面ライダーに含めるのかとか、劇中の略語である「ミカクニン」はどうするかとか、考え始めるときりがないくらいなんか細かな作業に突入しました。

できあがったら160行。仮面ライダーがのべ160人もいるなんて、なんだかびっくりです。

このような辞書を約10種類以上用意して、システム全体で運用しています。

また、作家リストも片岡義男など著作の多い作家は苦労しました。

数えたら、すくなくとも18人以上をコンプリートめざしてるんですね。道理で読む本が減らない…。

今後さらに条件を整理して、iPadやAndroidなどをターゲットにしようかと画策しているところです。