1. うちあわせCast
  2. 第百八十回:Tak.さんと自作エ..
2025-08-28 1:15:52

第百八十回:Tak.さんと自作エディタについて

サマリー

今回のエピソードでは、Tak.さんが自作のエディタについて話し、WorkflowlyやNotionのアップデート、POMLやXML形式など、生成AIに関連する技術にも触れています。その中で、エディタの開発がどのように容易になったかに焦点を当てています。Tak.さんは自作のエディタ開発について語り、Obsidianとの違いや自作エディタの利点について詳しく説明します。また、内部リンクや日付の移動機能を持つエディタの必要性を感じ、自作に至った経緯も紹介しています。彼の考察は、自作エディタの連番の扱いやフォルダー管理の難しさ、アウトライナーとしての価値や操作性に及びます。さらに、既存のエディタと組み合わせた新たな機能の実装や情報整理のプロセスについても言及しています。Tak.さんとのポッドキャストでは、自作エディタの設計についてさまざまな視点から考察され、ショートカットキーやファイル管理の工夫、執筆スタイルの変化が議論されています。自作エディタの開発における楽しさや生成AIとの連携による新たな可能性も語られ、特にエディタの機能やその操作性に関する工夫が強調されています。自作エディタを利用することで、機能が多すぎる既存のエディタに不満を持つ人々にとっての満足度が高まる可能性があります。

最近のアップデート情報
スピーカー 1
うちあわせCast第百八十回ということで、今回もゲストにたくさんお会いしております。よろしくお願いします。
スピーカー 2
よろしくお願いします。
スピーカー 1
いくつかまずニュースがあって、ちょっと時系列は適当なんですけども、まずWorkflowlyがまた新規が追加されまして、大したことじゃないんですけども、
マークダウンの拡張機法みたいなもので、開きブラケット、スペース、閉じブラケット、スペースとすると、その行がタスクになる。
共同にチェックボックスがつくようになったので、マークダウン変換のアッシュみたいなものが追加されたということで、今までは結構めんどくさかったんですね。
その行のターンインツーとか選んで、タスクみたいなのを選ばないとできなかったのが、自然な機法でできるようになったということで、これも順当なマークダウンへのアダプテーションだと思うんですけど、
なんか最近ね、Workflowlyの開発スピードが速くて、Twitterのアカウントもあるんですけど、これまでより頻繁にツイートをしてるんですよね。
スピーカー 2
そうですね。
スピーカー 1
チームメンバーが新しく増えたのかもしれないと思いつつ、もしかしたら開発に生成AIが加わったことによってバック上がりにしてるのかなと思いまして。
スピーカー 2
なんかYouTubeチャンネルまで開設しちゃって。
スピーカー 1
メンバーの2人がYouTubeチャンネルを開発したって言って、全部は見てないんですけども、今までのゆったりとした進め方とはだいぶ違うなと思って、なんか開発環境に大きな違いが生まれたんでしょうね、きっと。
スピーカー 2
そうなんですかね。YouTubeの方でもなんかイケイケのライブコーディング的な、そういう感じで。楽しいですけどね、見てると。
スピーカー 1
おそらくそういうなんかがあって、開発が活発になっている。まあ、活発になっていること自体はあるわけではないんですけど、
なんか、たまにワークローリーがツイートしていると、他の人がこれいいですねとか言って、海外の方がリプライとかしてて、やっぱりこれを数年間使ってるけど、このツールから変えることはできないみたいなつぶやきをちらほら見かけるんですけど、やっぱりそういう扱いなんやなと思って。
スピーカー 2
まあね、そうですね。
スピーカー 1
かっこたるポジションを築いてるんやなと思いますけども。
スピーカー 2
まあ、いいことでは、いいこと80%ぐらいの感じですかね。
スピーカー 1
そうですね。そういうのと、あとね、Notionが大きいアップデートがあって、オフラインモードが追加されたらしく、アプリケーション立ち上げてるときにオフラインでも、多分ですけど、参照できるだけじゃなくて、編集も多分できる模様ですね。
で、同期が復活したら、オンラインに復帰したら、内容が同期されるというタイプやと思います。ちょっと使ってないんでわからないんですけど。
まあ、閲覧できるだけでも結構便利やと思いますが、編集が反映されるのであれば、より便利やと思いますね。
スピーカー 2
そうですね。
スピーカー 1
ノートツールって手帳的な情報を扱うことも多く、このタイミングでこれが見れないのはまずいみたいなことがあると思うので、オフラインモードがあるのはいいことだと思います。
これは結構前に、もうちょっとしたら実装するぞと告知されてたのが実装されたらしく、喜んでる方がいっぱいいましたね。
使ってないんで何とも言えないんですけど。
あとね、タイムパッドっていうサービスがありまして、ブログサービスなのかな?
で、シャットダウンするという発表がありまして、これMovable Typeの開発した会社、Six Apartやったかな?が提供していたブログサービスみたいなやつで、
月額払ってたらプロサービス使えるよみたいなやつ、海外サービスやったんですけども、それが閉まるということで、海外でもこういうブログサービスのシャットダウンが進んでいるんだなという話です。
生成AIとプロンプト技術
スピーカー 2
なるほどですね。
スピーカー 1
POMLというのがマイクロソフトかな?が提案したものがありまして、アウトライナーの標準のファイル形式あるじゃないですか。
スピーカー 2
OPML
スピーカー 1
あれのASHみたいなのでXMLなんですけど、プロンプとオーケストレーションマークアップランゲージの略。
スピーカー 2
すごい名前ですね。
スピーカー 1
簡単に言うと、生成AIに指示文を与えるときに、通常言語の平文で与えるんじゃなくて、マークアップのような感じでタグ付けするといいよという話で、
スピーカー 2
なるほど。
スピーカー 1
XMLの拡張って結局どんなタグ作ってもいいわけですから、生成AIが利用しやすい形のタグを共通基盤で作ればいいんじゃないかということで、
普通に日本人の英語レベルでわかるアウトプットフォーマットとか、ロール役割、あなたがこういう役割を演じてくださいというロールとかっていうふうに与えることで指示するということで、
生成AIに対してどういうプロンプと与えたらいいのかとかいうのがまだはっきり決着がついてなくて、平文がいいとかXMLがいいとか、JSONがいいとかっていろいろ流派があるみたいですけど、
このXML形式もいいんじゃないかという話でそれが提案されているということで、
思うんですけど、やっぱりXMLとかHTMLもそうなんですけど、やっぱり人間が見て読めるんですよね、その形式って。
当然、生成AIは人間が書いた文章を読んで学習しているわけで、読める形が理解しやすいっていうのは多分普通にナチュラルな規律なんだなとは思いますけども。
まあそうですよね。
面白いなと思って、ここにきてこのイニシーの技術が再発掘されている流れが面白いなと思うんですけど。
これ実際に多分これを出力するようなアプリケーションとかその他諸々も開発されるんでしょうけども、
まあでも本当に2ヶ月経ったらこんなものは古いということになっているかもしれないんで、この様観察ですね。
スピーカー 2
でもこれアウトライナーでいいんじゃないかって気がしたんですよね。
スピーカー 1
アウトライナーの出力でも別に、だからそうやな、アウトライナーの各行に対してロールを割り当てられるような、
つまりドラマ、ドラマってあとリビューとかの属性を与えられたと思うんですけど、ああいうものだったらほとんど同じように機能するはずですね、きっと。
スピーカー 2
そうですね、だからOPML、そもそもOPMLはアウトライナーのアウトラインの形式をXMLで表記できるように作ったもので、
それを流用することでいろんなことができたんですけど、結局そのプロンプトをどうやって作るかというときに、
結局階層を構造にするのがいいということじゃないですか。
スピーカー 1
そういうことですね、そういうことになると思います。
スピーカー 2
だからね、入り口がアウトライナーだといいなと僕なんか思っちゃうんですけど、他の人は思わないかもしれないですけど。
スピーカー 1
まあでもどうやろうな、この辺のパターンの場合はフォーマットを作って中に埋め込むだけで、
いわゆるプロセス型のような回答定義を入れ替えるような編集は多分なされないので、
ぽこぽこ埋めていくだけなんで、アウトライナーが必要かどうかは微妙だと思うんですけど、
アウトライナーの構造をそのまま使えたら便利というのはあるでしょうね。
そうですね、アウトラインの構造ですよね。
そうですね、人間の場合でも開業プラスインデントでこれが一つの従属要素だって見てわかるっていうところがあると思うんですけど、
だから、生成案の場合は開業が意味の区切りであることをわかってない時があるんですね。
その代わり例えばタグとかを入れると、当然ここはこれまでの内容とは違うなっていうのをはっとわからはるんですよ、あの人たち。
スピーカー 2
それって自然言語の話ですか?
スピーカー 1
自然言語の文章の中とか、このテキストを読めみたいな、このテキストファイルを読めっていうのを提示した時に、
個人的にはここと明らかに開業してるんだけど、その開業を区切らんと下の業務を一緒の意味として捉えとる場合があるんですね。
スピーカー 2
それを例えば、DHTメリット、Libタグでその部分を区切ると、彼らはここは別の内容だってわかってくれるわけですよ。
スピーカー 1
わかってるかどうかは知りませんけど、処理にその区別が反映されるんですね。
それの延長線上ですよね、これはね。
自作エディタの開発
スピーカー 2
なるほど、なるほど、そういうことか。
スピーカー 1
人間の場合は開業が意味としてはっきりするけども、それをより言語的に扱うとこういうタグ、XM的なタグになるんだろうなという感じですね。
スピーカー 2
要するに意図をよりはっきり伝わるよりっていうことですね。
スピーカー 1
そうですね、だからこれはある種ローコンテキストなメッセージのやり取りということですね。
はいはいはい。
その辺が今後も多分活発に行われるんでしょうというところと、あとちょっと最近読んだ本の話をしてなかったんですけど、
チェキシェさんの技術系の話っていうと、これはどこだったっけ。
講談社現代新書が出ている書くことの哲学という本が面白かったので紹介するんですけど、
書きたいとか書く気持ちがあるけど書けないでいる人に対して技術論というよりも心構えから入っていって、どう書ける身体に生成していくのかというような話です。
これは現代でモダンなチェキシェの技術の話って面白いのと、あと今並みからケアと編集という本もありまして、
ケアを開くシリーズというシリーズを出されていた編集さんが書かれた本で、8割くらいケアの内容なんですけど、
ケア的なアプローチで編集することの面白さが書かれてまして、ケアとキュア、治療するの対比がチラッと出てくるんですけど、
それに、例えば医療的にこれが人間の正常な状態やとして病気になった人そっちに戻していく、引っ張っていくっていうのがキュアだとしたら、
ケアっていうのはその人の歪みとかを肯定した上で、なんか生きやすさを少しでも手に入れていこうというような対比としてケアが用いられていて、
これは僕が考えるライフワークはこっちだなと思ったんですけど、ノウハウってキュア的なものとキュア的なものがあるよなという感じがするわけですね。
ある時代の働くビジネスパーソンイコール企業選手的なものっていうのはそのキュア的なノウハウをやったんですけど、
ここ最近のノウハウの必要性っていうのはケア的なものになってきてるんじゃないかなという観点で読みまして、
本の編集の役に立つかどうかは知りませんけど、その視点というのはちょっと面白いなとは思いました。
スピーカー 2
面白い視点ですね。
スピーカー 1
ケアを開くシリーズっていわゆる一般的な医療とかというような視点とは全然違う本をたくさん出されていて、
僕もいくつか読んでますけど、こういう観点で作られてきたんだなというのはちょっと面白い話でした。
はい。
というところがTRIHACK NEWSで本編に入るわけですけども、今回もちょっと画面共有ができるかもしれませんが、
最近私がエディターを作り始めたということで、最近って言っても多分いつからかな?8月の頭ぐらいかな?
スピーカー 2
1月ぐらいですよね。
スピーカー 1
ぐらいで作り始めて、色々面白いこととか発見したこととかメルマガで書いてるんですけども、
その辺の話をできたらなと思ってまして。
エディターを自作するなんていうのは、例えば僕10年前やったら巨大プロジェクトな感じがしたわけですが、
僕がHTMLとかJavaScriptを使えるようになって、エディター上でテキストエディターの真似事みたいなことはある程度はできてたんですけど、
それでもそのモダンなエディターを自分で実装するなんていうのもまた夢やなと。
いわゆる物書き業が一段落して、老後の趣味的なものになるかなとは思ってたんですけど、
スピーカー 2
ここでやっぱりちょっとChatGPTが出てくるわけですね。
スピーカー 1
ChatGPTに応答しながら、質問しながらやると、
ずぶの素人ではないですけど、日曜大工プログラマーレベルの僕でもエディターっていうものが作れてしまうと。
当然ゼロベースで作ってるわけじゃなくて、MacのアプリケーションにするためにElectronというのがありまして、
これはGoogleのChromeのエンジンとNode.jsっていうJavaScriptをローカルで走らせるためのアップログラムをセットで動かすもので、
要するにWebブラウザーのページとしてMacのアプリケーション表示しているというような設定を作ってくれるやつで、
ダークフローリーとかNotionとかのローカルアプリも基本的にはこのElectronでパッケージされているだけやと多分思います。
ちなみにObsidianもこのElectronで作られていまして、なぜわざわざエディターを自作しようと思ったっていう話なんですけども、
自作エディタの開発の経緯
スピーカー 1
もともとはずっと作業記録を書くときにObsidianを使ってたんですね。
基本的にローカルファイルを扱える非常に良いエディターではあるんですけど、
特にライブプレビューといってマークダウンをそのままプレビューしてくれる機能は非常に便利なんですけども、
少し前にベース機能というのが発表されまして、テキストファイルをデータベースの1ページとして扱えるようになるような機能と言えばいいのかな。
漢字で言うと5センスのインフォーボックスに近いんですけども、僕らが作るのは個々のページだけでよくて、
それをデータベース的に並び替えたりとか要素を抽出することができるよという機能がEarly Accessのところで発表されてまして、
僕はずっと横目で見てたんですけども、発表される機能を見るにやっぱりノーションとかにちょっと近い感じがするわけですね。
そういう匂いがする。もちろんノーションとは違うんですけども、やっぱりその1ページ分でも使ったみた後に気づいたんですけど、
そのようなデータビューベースで見てしまうとプロパティを入れたくなってくると。プロパティっていうのは例えば属性ですよね。
作成日とかタグとかその他諸々メタ情報みたいなのを追加したくなってくると。
それは僕の中ではデジタルノートにおける危険サインその1なんですけども、そうなってきたらちょっと本末転倒やろうなということで。
もしこのままそのベース機能っていうのが便利だってなって、OCDANがそっちの方に進んだときに、このままいくと多分僕が使いたいエディターではなくなっていくなという気持ちがあったんですね。
もしOCDANがそうなっても、このOCDAN的な便利なエディター機能だけは使いたいなという気持ちがあったので、ちょっと自作してみようかと。
そもそも僕OCDANで使えるフル機能が100あったとしたら、多分15くらいしか使ってない。15も使ってないかな。もっと使ってないですけど。
つまりそもそもそんなにいらんかったんですね。フルパッケージはいらんかったということで。だから逆に言うと、本当に小パッケージで自分が実装できるレベルの機能があるプレインテキストを扱えるエディターがあればいいんじゃないかと。
最初はそれ以前に使ってたコットエディターというのに戻ろうとしたんですけど、やっぱり不自由なんですね。
戻れなくなってしまったと。
2点不自由な点があって、1つはまず内部リンクが使えない。OCDANはダブルブラケットでページ名を書くと、ボタンを押したらリンクできるというコセンスとかと同じ機能があるんですけども、コットエディターにはないと。
もう1個が日付の前後移動ができないと。僕は作業記録を書くツールとして欲してるんで、例えば8月28日の作業記録を開いているときにショートカットキー一発で8月27日とか9日に飛びたいわけですね。
飛びたいというか、OCDANでは飛べてたわけですけど、コットエディターでそれをやろうと思ったら割と難しい問題がいっぱいあるわけですよ。できないわけじゃないけどもという感じなので、それぐらいの機能があって、リンクが踏めて前後に移動できる機能ぐらいのエディターだったら作れるんじゃないかなという気持ちがありまして、作ってたと。
機能の実装と特徴
スピーカー 1
うよ曲折になって、途中まで作った後に、1から実装は無理なんでコードミラーを使えばいいということがわかりまして、コードミラーというライバルがありまして、これも本当にモダンなエディターの機能をほとんど備えている標準で。しかもオンオフできるんですね、こっち側で。
この機能を使いたいときにそれを設定すればその機能がつくという感じで。なので、初めからフルスタックのエディターがあるわけじゃなくて、基本のエディターにプラスアルファ必要な機能を付け加えていくという形なので、僕が目指す最低限のエディターを作るのにもいいなと。
スピーカー 2
なのでそれをメインで使っていこうと思って調べたら、そもそもObsidianもそれを使っているということがわかりまして。
スピーカー 1
例えば標準について驚いたのが、ブロックの開閉がありまして、例えば構造化された過剰書きリストみたいなのをObsidianで開くと、タブを押したら子どもの階層に移動すると。
親階層のところにピチョッと矢印ができまして、それを押したら項目の開閉が行われるんですね。これは例えばちょっとアウトラインっぽく使えますし、こんな機能を付いているObsidianは便利だなと思ったんですけど、走行ドミラーに標準についているやつだったので、別に特に珍しいことでもないなと思って。
見てたら大体僕が欲しい機能は揃ってたんで、そのハイパーリンク的なリンク機能だけほとんど自前で実装したら使えるようになったというところで。だから基本的にObsidianで作業記録を書くことはなくなりまして、日中はほとんど自作エディターを使っておる次第なんですけれども。
一応画面をどんなんか共有させていただきますが、こういうエディターでして、非常に普通のエディターですね。一応行番号は付いてますが、今週中にこれのオンオフはできるようにしようかなと思って、右下にモニターがあると。
あとはただのエディターで、マークダウンの記法が使えるようになってるんで、ハイフン書いてスペースを押したらリストになってタブを押したらインデントを作るっていうのも非常に標準的な感じで。見出し抜き号のシャープマークを付けたとこは青字になるとか、あとこれをブロックとして認識するんで、これを押したら開閉できるとか、これはもうコードミラーの標準機能ですね。
これだけのことですけど、これだけのものが1週間あれをもうほとんど使えるスペックになったんで、まずそこに驚きましたね。もっと複雑な工程がいるんかなと思いますけど、ファイルを開いてマークダウンをプレビューしてファイルセーブするみたいなことの機能だけでは、たぶん1日でできましたね。
スピーカー 2
1日で。
スピーカー 1
1日で。そんなことできるんだなということがまず現代的な驚き。コードを書いたのはほぼチャットGPTかGeminiなんですけども、それでもできてしまうと。
で、あとこれメール前に書いた話ですけど、OVC案との一番の違いが自動保存であると。自動保存なんてできて当たり前やと思ってたんですけど、当然自前で実装しないとそんな機能はないわけですが、
やっぱりね、保存する。普通のエディターってコマンドSで保存したらタイトルのこのアスタリスクが消えるんですけど、保存することとテキストエディターっていうものの切り離せなさっていうのはやっぱりちょっと感じましたね。
やっぱりクラウドツールって基本的には自動保存ですけど、で、自動保存されるということはどういうことかというと、これ画面何写ってます?
スピーカー 2
今エディターの画面。
ショートカットキーとファイル移動
スピーカー 1
何も変わってないですか?
変わってないです。
スピーカー 2
あ、そうか。じゃあちょっと待ってくださいね。
スピーカー 1
あ、そうか。単一になるのか。そういうことだな。1個しか共有できるのか。今コマンドNで新しいウィンドウ開いたんですけども、これってファイルがないわけですよ、まだ。
メモリー上にしかない。ここにどんなに文字を打ってもメモリー上にしかなくて、コマンドSを打ったときに初めて実体のファイルとして保存されるんです。
例えばObsidianの場合コマンドNを押したら、もうUntitled.mdが作成されてしまうわけですよ。
作成されないと自動保存ができないんですね。自動保存っていうのはファイルに保存するようなことなんで。
だから僕たちテキストエディターを使ってたときは、この暫定的なウィンドウが使えたんですよ。
メモ帳のようにウィンドウが使えたわけですね。書くだけ書いて、でもいらんかったら全部消すなりして、ウィンドウをそのものを消してしまう。
ならどこにもメモリーから消えてしまって、パソコンのファイルには残らないという、こういうのチラシの裏的な使い方と呼んでますけど、ができたのが
Obsidian以降できなくなったんですね。できなくなったというかしなくなった。そうするとどうなるかというと、なんとなく雑多なものを書きにくくなる。
デイリーノート方式でやってる人であれば、デイリーノートに書けばある程度雑多なものは書けますけど、かといってそれが残ってしまうわけですね。
デイリーノートの場合は。残らなくてもいいけど書くことをしたいみたいな用途の場所が自動保存の場合ないんだなということに気づきまして。
もちろん書いた後にそのUntitled.mdを削除したらいい話なんですけどね。でも多分ね、それですごくしにくいと思うんですよ。
スピーカー 2
しないですよね。
スピーカー 1
僕の経験上、作成したファイルを消すという操作は結構大事で、でもそれだったらWindows保存しないでそのまま消す方がはるかに簡単なんですね。
だからエバーノート以降保存されることが当たり前になった環境で、久しぶりにコマンドSを意図的に保存しない限り残らなくなった場所っていうのを手に入れて、
こういう狭間の場所みたいなものが持つ価値っていうのはあるよなというのをちょっと思いました。
スピーカー 2
その感覚ってやっぱりちょっと世代的なものがあって、やっぱりクラウド以前に使い方を確立した世代の感覚ですよね。
そう思います。
僕もやりますけど。僕はMacのテキストエディット、あれをほとんど既に開いてるんですけど、保存したことほとんどないんですよね。やっぱり同じ使い方なんですよ。
ちょっと何か書くとか、一旦コピーして置いとくとか、そういう使い方しかしてないんですけど。だから同じですよね。
スピーカー 1
そういうことができる場所があるかないかって、小さい話に見えて案外重要やな。
机の上に小さいメモ帳とかレポートパッドが置いてあるような感じで、デジタルに書き込むことがやっぱりできなくなってたなというのはちょっと思いましたね。
スピーカー 2
そうですね。不思議なことに、なんかそういう付箋アプリみたいなのあるじゃないですか。何でしたっけ?
スティッキーズ?
そうそう、スティッキーズみたいな。そういうものを使えば良さそうな用途。なんか実は保存しないエディター画面の方が実は使いやすかったりするという不思議な文章があるんですよね。
スピーカー 1
だからやっぱり付箋の場合は貼って残すという意図を持ってないと使わない感じがしますね。
そうなんですよ。不思議だなぁと思いつつ。
一応リンク等もありまして、逆にさっき言った日付の移動もショートカットキーだけで前後の日に移動できますし、
今日28なんでこれが今最新のページですけど、多分この状態で次の日に行こうとするとダイアログが出てきて、
作るかどうか聞かれるんで、作るってダイアログをしたら自動的に次の日のファイルが作られるみたいなのが実装してますね。
スピーカー 2
この次の日前の日っていうのはこのファイル名を読んで?
スピーカー 1
そうですね。まさにその通りですね。2025.08.28を日付データに変換して、マイナス1日するプラス1日するしてファイル名を見て、
ファイルが存在してなかったら作るかどうかを聞いてくるという感じですね。
これはアルゴリズムで操作できることなんですけど、コマンドを押すとヒストリーみたいなのが開くんですね。
今まで開いたファイル一覧みたいながで飛べるんですけど、これもちょっとひと工夫がありまして、日付のファイルが出てこないようになってるんですね。
日付のファイルが一番開くのは多いんですけど、日付のファイルはもうどこにあるか分かってるんで、要はないんですけど、
特定のプロジェクトの先頭ファイルとかインデックスファイルみたいなのはここから飛びたいんで、だからヒストリーも全部必要ないなっていうのも、
例えばObsidianとかコセンスを使ってきた経験から分かってることなんですけど、どっかのインデックスファイル開いたときに、
Chapter0から1,2,3,4みたいなのがあったりとか、カード0,1、連番で振っておくとさっきと同じメカニズムが使えるようになってまして、
日付を前後に移動するショートカットキーを押すと同じようにカードもプラス1で動くようになってるんですね。
カード00って書いてあったらカード01になると。単純な加算で増えていくようになってて、同じように末尾まで行ったら新しいカードを追加するみたいなことが機能が生まれまして、
エディタの設計と課題
スピーカー 1
連番の扱いは簡単なんですけど、Chapter00とかChapter○○も簡単なんですけど、これでも連番じゃないものはできないんですよね、単純なアルゴリズムではできないと。
今そこをちょうどいろいろ考えてるんですけど、例えばカードを一つの流れに作ったとしても、読み返したときに、ニートさんの間に何か入れたいなっていう、書くべきのものはニートさんの間だと仮に思ったとしたときに、連番にやると非常に止まるんですよね、ファイル名が。
例えば0201としたら、当然ファイルリストの中では02と03の間に0201は出るんですけど、さっきやった加算で移動していく流れが壊れてしまうんですね。
単純な足す1でうまいこといかなくなるわけですよ。そうすると今度はそこのフォルダーのファイル一覧を取得して、名前順でそうとしてみたいなことで、だんだんややこしくなってくるんですよね。
スピーカー 2
僕の場合は昨日実装したんですけど、ニートさんの間にファイルを実装したくなったら、それ用のショートカットキーを押したら、3以降のファイルの名前を全部足す1すると。
スピーカー 1
空いた03に新しいのを書くっていう力技を使ったんですけど、それぐらいしか解決できない。一回ナンバリングで並べてしまった後に変えるのが非常に難しいことを考えたときに、いかにOutlinerが自由であるかということに思いを馳せられないなというふうにはちょっと思ったんですよ。
やっぱりファイル名でファイルで保存するっていうことの良さはもちろんあるんですけど、例えばワークフローリーのようなプロセス型であったりとか、スクリブラーのようなプロダクト型でもいいんですけど、なんか要素を並べるときにファイル名を持たないんですよね。
順番そのものは、ユーザーインターフェースのあの並びで制御されているわけで、名前順とかじゃなくて任意の順番で並べられるし、それ自身が並ぶためのデータセットを別に持っているので、メタ情報でソートされているわけじゃなくて、並べますよっていうメタ情報を別に持っていることで、タイトル名をどうするかっていうのは並びとは別に検討できてしまう。
そのことの価値は、自分でエディターを作ってみて、改めて感じて、ファイル名扱い難しいなぁと思いましたね。
スピーカー 2
ファイル名だけでそこまでやろうとするのはかなり難しいですよね、きっと。
スピーカー 1
何もかもを思い通りにするのは難しいなというところが1つあるのと、あともう1つ、今画面のエディター何表示されてます?そのタイトルバーに何書かれてます?
スピーカー 2
タイトルバーは202…
スピーカー 1
新しく見ないと読めないですね。
これは移動はあれじゃなかったのか。もう1個、それと関連する話なんですけど、画面を変えなきゃね。
これ、僕がツイートしたやつからピックアップしたものをまとめたMDファイルなんですけど、
途中までしかやってないですけど、1万6000字くらいあるんですね。
スピーカー 2
非常に長いんですけど、今までこういうのをどう扱うかをずっと考えてたんですね。
スピーカー 1
やっぱり標準的なのはWorkflowlyみたいなアウトライナーに入れることだったんですけど、
次点としてはEmacsのorgファイルに入れると。
orgファイルは非常に良かったんですけど、Emacsそのものの扱いの辛さに何度も挫折してしまって、結局使えてないんですけど、
今この形になってまして、当然この見出しが見出しごとに閉じられるんで、orgファイルみたいにカテゴリーで分けられるんですけど、
これもショートカットをつけまして、シフトオプションコマンド上から押すと全部が閉じるんですよね。
開いてた項目が全部閉じて、逆にシフトオプションコマンド下って逆の方向押すと、逆に全部開くと。
これがめちゃくちゃ便利でして、なんでこんなに便利なのかなって気づかなかったんですけど、
スピーカー 1
自分がここで書いて、書き終わった時に全項目を押すと全部閉じると。
全部閉じるっていうのは、アウトラインを見るっていうことですね、このファイルのアウトラインを見るということで。
だからアウトラインっていう、プロセス型で表示される別ウィンドウのアウトラインっていうのがいらなくて、
全項目を閉じるか開くかだけで、このビューの移動ができることの感動したんですけど。
たぶんアウトライナー使ってる人は当たり前話してるんでしょうけど、
エディターでこれができてしまうということで、僕は初めてこの良さをハリハリと実感してるところなんですけど。
スピーカー 2
なるほど、はい。
でもそうなると一つのウィンドウであることの良さって出てきません?
スピーカー 1
あ、そうか、確かにそうやな。
スピーカー 2
あの、ツーペインではなくて、一つのウィンドウであることの良さが、たぶんなんかそれだと出てくる。
スピーカー 1
確かに、だから。
スピーカー 2
出てくる気がするんですよね。
そうですね。
スピーカー 1
これ、いわゆる操作的には、アウトライナーの開項目の開閉に近いんですけど、
この話はたぶん、ここの項目が開くと閉じるだけではないんですよね、僕の中では。
全部が開いて、全部が閉じるということがワン操作でできると、何か違ったものに見えてくるという不思議な経験をしたんですが。
で、この話をどっかメッセージしたら、たくさんがプロダクト型的なものの良さですね、という話をされて。
確かにそうなんですよ、これ階層が揃っているから意味があるんですよ。
それは確かに気づいていなくて、これは僕は最上位項目が2で固定されていて、その内部が仮にあったとしても3で閉じていて、
ロット3までで分布されててっていうところなので、ワン操作で最下段と最上段が行き来できるということは、
この階層構造がフォーマッティングされているからこそやなというのがあって、
だからワークフローリーで自由に使っている場合、この良さはあんまり立ち上がってこないんだろうなという気も予想としてはありますね。
スピーカー 2
そうですね。それこそ流度が揃っていないと、これをやっても多分意味がなくて、
ワークフローリーの第3階層まで全部畳んだとしても、第3階層に何が入っているのかが定まっていなければ多分あんまり意味がないんですよね。
だからこれだと、要はこの見出し、同じレベルの見出しになってるんで、多分全部折り畳んだときに一瞬でこの全部が俯瞰できる形になるわけですよね。
スピーカー 1
そうですね。
同流度を作る、逆やな。こういうふうに構造を作る人間にとっては、いわゆるプロダクタ型のようなもの、実際プロダクタ型ではないですが、プロダクタ型のようなある程度フォーマッティングの構造でも全然使っていける。
ただし、例えばこのファイルで僕がワークフローリーでやろうとしていることを実現でいるかというと、それはまずできないので、全く違うものなんだなと。
だから階層とか見出しとか開閉って言ってたとしても、こんなに違いがあるんだなというのはちょっと驚きましたね。
新しい操作の実現
スピーカー 1
あとやっぱりオーグもそうなんですけど、一番下のラインが揃っているという。
一番下。
つまり本文がこのラインに次にあると。
ワークフローリーの場合、ある項目は第3階層やし、ある項目は第5階層になっていて、その下が揃わないわけですよね。
これは揃っていて、揃ってた方がある種の知的作業において、僕がここでやろうとしているようなツイートをまとめてほにゃららほにゃららしようみたいな時においては、最下層が揃ってた方がいい。
当然、階層が見出しが2、3しかない場合、下のラインが揃うのは当然なんですけど、多分そういうことじゃなくて。
だからおそらく見た目の問題もあって、インデントされてないわけね、その一番下のラインが。
インデントされてないというところも多分関係があるのかなと。
バイクでも見たことはできるんですけど、バイクでも結局本部のラインがインデント付きになってしまうんで、そこが多分僕では引っかかる点なのかなという気もしますね。
スピーカー 2
やっぱり本部の、本部というかその最下層が揃っているというのも、逆に言えば見出しの流動が揃っているからなんですよね。
だから見出しの流動が揃わない段階ではプロセス型がおそらく一番自由に考えられる。
でも考えていった結果として見出しの流動が揃ってきた段階で、それ以降その構造を使い続けるのであればむしろプロダクト型のほうが使いやすくなるイメージが僕にはあって。
あともう一個、今の倉下さんみたいに、そもそもこのプロダクト型的な形式のほうが、ある種の考える作業はやりやすいというタイプの人ももしかしたらいるかもしれなくて、
それってひょっとしてカード的なものがしっくりくる人と重なるんじゃないかと僕はなんとなく思ってるんですけど。
スピーカー 1
それは多少あると思いますね。区切りがはっきりするというところは大きいとは思いますね。
あとは、カード的なもの。あれもだから、カードを並べても本文のラインが崩れへんというところがあるのかな。
まあ難しいけども、やっぱり一つ目は先ほど言った本文っていうものが見た目としてこういう位置にないという、ここにあってほしいという感じ。
常にここにあってほしいわけじゃないですけど、ある知的作業をするときに本文レベルと同じ、本文レベルじゃない、文章を書くときと同じところに置いておいてほしいみたいな感じかな。
そうしたときに起こりやすい知的な営みがあって、だからやっぱり僕の場合はアウトライン上で文章は書けますけど、文章を書きたい気持ちになるのはやっぱりエディターの方なんですね。
その気持ちで行われる作業が今ここに並べているものに必要やっている場合に、やっぱりここに並べるのがいいという感じがするのと、あともう一個、僕、頭の方向性としていろんなことを考えすぎてしまうタイプの人間なので、
つまりまとめようとするときにはより強い強制力、切断力がないと、結局あれもこれもそうやねって言ってまとまりきらない、まとめ方向にベクトルが向かないから。
なので多分こういう流度を揃えた方が考えやすい、まとめやすいっていうのはまさにその切断力を欲しているからっていう感じがしますね。
スピーカー 2
まあ流度が揃っているってことはある程度まとまっているということですもんね、そもそも。
スピーカー 1
で、まとめようとしている。
なんか考え事しようとしたときに、ひとまずこれは情報整理として考えようと決め打ちしないと、永遠にまとまらないというか。
情報としてこれは情報整理でもあるし、読むことでもあるし、学ぶことでもあるとかって列挙していったら、永遠にまとめはできないわけですよね。
どっか決め打ちが必要で、後で変えてもいいけど、ここに置いておこうという気持ちで固めようとするときにそのフォーマットの強制力みたいなのが多分役立つんじゃないかなと。
だから普段逆にカチカチに考えている人は、プロセス型のようなもので柔らかくした方が広がりがあるみたいな言葉多分あるんじゃないですかね。
スピーカー 2
なるほど、なるほど。
スピーカー 1
この辺はやっぱり普段自分の日常的な知的傾向とか扱い方によって違ってくるんでしょうし、
ずっとこれまでワークロリ型を使ってたんで、このようなオーグ型がより斬新に感じられたのと、
あとオーグのややこしいコマンドを覚えなくても、自分が指でこうだろうと思ったショートカットになるわけですから、この場合は。
非常に身体化された知的ツールっていう感じがしますね。
スピーカー 2
そうですね。オーグモードはいいんだけど、結局全部Emacsにしないと辛いんですよね。逆にもう全てをEmacsでやる覚悟をしないとオーグを使えないんですよね。
スピーカー 1
その点、こいつは一応基本的にはただのマークダウンエディターなので、弱めのマークダウンエディターで、
今別にそこまで多機能じゃなくて、それこそテキストエディットにちょっと羽が生えたような感じのレベルのものでしかないんで、
ややこしい操作も覚えなくていいし、そもそも覚えるというか僕が決めるわけですから、全部のショートカットキーを。
そこは楽ではありますね。だからオーグモードの場合は、例えば見出しに合わせてタブキーを押すんですね。
タブキーを押すと下が開くんですけど標準操作の場合。
確かトークルするんですね。開閉、小開閉、全閉じみたいな感じで一つが操作するんだけど、
ショートカットキー、ほにゃらら上で開く、ほにゃらら下で開くもできますし、ほにゃらら下を押したらトークルしていくでもできますし、
ショートカットキーの工夫
スピーカー 1
そこの辺動作自分で考えられますけど、やっぱり機能が増えてくるとショートカットキーの競合みたいなのが起こるんですよね。
気持ち悪い押し方を強要するんやったらいくらでも設定できるんですけど、そういうショートカットキーって押さなくなるじゃないですか。
可能なショートキーの範囲って結構限られてて、だからEmacsみたいな2つのキーのセットでやるか、
Vimみたいにモードによってショートカットキー変えるとか、ああいうレイヤーを持たせないとなかなか難しいなというのも自分で出してて思いますね。
スピーカー 2
作ってみて初めてわかることってありますよね。
スピーカー 1
この行を動かすショートカットキーと行からの開口目を開くショートカットキーって上下を使いたいんですけど、
なんとなく似てくるんですよね、ショートカットキーが。
バイクは0と9を使うんですけど開閉に。使いにくいなと思ったんですけど、今ならわかるなという気がします。
矢印がいっぱいいっぱいだからもう09しかないなという感じはちょっとありますね。
スピーカー 2
そうですね。
スピーカー 1
あとこれと関連、この全項目の開閉と関連するんですけども、
例えば、執筆プロジェクトを進めるときに、章ごとでファイルを上げるっていうのが標準的な作法な気がするんですけども、
えーと、
今日画面表示を変えますが、
チャプターごとに章を当てていくやり方をして、それを連番にすると、さっきほどのような移動ができるんですけども、
2つ問題がありまして、1つ章の順番を変えたときにめんどくさいことになると。
で、もう1個はファイル名を見ただけでは何が書いてあるかわからないと。
おそらくそのチャプター1を担当していることはわかりますけど、現在どんなタイトルになっているのかがファイル名だけではわからない問題があるから、
ファイル名にしたいんですけどファイル名にするとさっきのような順番移動ができなくなるということでジレンマなんですけど、
昨日気がついたんですけど、別に分けなくていいよなと思ったんですよね。
つまり今ちょっと試しにやってるんですけど、1つのファイルにもう全部の章のテキストを入れると、
すごく長くなるわけですけど、結局全部閉じたら、これ結局アウトラインやなと気づいて。
スピーカー 2
そうです。
スピーカー 1
例えばここで章の順番を入れたかったら、これコピペして上にいっていいだけの話じゃないですか。
だからこの見出しレベルで閉じるという操作ができれば、別に章ごとで分ける必要なくて、これって多分ワードファイルでやってることなんですよねということを気づいたということなんですよ。
スピーカー 2
僕章ごとに分けたことないです。
スピーカー 1
そうなんや。
スピーカー 2
昔は容量の問題で、そもそも10万字編集できなかったから分けなきゃいけなかったみたいなのがありますけど、
今は別に30万ぐらいまでは余裕なんで。
スピーカー 1
そうか。
スピーカー 2
だから分けないですよね。
スピーカー 1
とりあえずプロセス型で章ごとにファイル分けるなんてことはまず絶対しないわけですし、
それが次にワードになったら今度は一つのファイルになってるわけで、
そのたくさんのプロセスだから章ごとでテキストファイル作るってことはほぼないわけですね。
スピーカー 2
ないです。
スピーカー 1
そうか。僕はこれまで分けることが標準だったんで、
分けたものをどう統合するかっていう話が問題として必ず出てくるわけですよ。
今までずっといろいろやってきたんですけどね。
それを前提にマークダウンでのファイルの分岐とか章ごとの移動って考えたんですけど、
この全項目の解閉を覚えたことによって、分けなくていいじゃんっていう原始的な発見をしてしまったところなんですけど、
手癖でしてるというのはあれですけど、今までのやり方を前提にプロセスを構築してるなというのを思い知らされましたね。
この一つの機能のおかげで、そもそもファイル管理そのものが変わってくるっていうのは面白い発見でした。
これができることによって、そうか、ワードってこういうふうにできるんだっていうのを初めて分かったという感じですね。
そうですね。ワードの欠点はワードであることだけであって、ワードでさえなければワードは本当に素晴らしいという。
スクリブナーを使うのはこの体験じゃない感じがするんですよね。なんか不思議なことに。
スピーカー 2
スクリブナーはやっぱりね、ファイルなんですよ。あれ一つ一つ。
スピーカー 1
なるほど。
スピーカー 2
一つのファイルを、一つのファイルとして扱っている、扱える感覚を作ろうとしてるけれども、実際には一つ一つはファイルなんですよね。
なるほどね。
わざわざそれを選択すると連続表示して便利でしょって言ってるんですけど、そもそも一つのファイルならそんな必要ないっていうこともあって。
ただまあ、その方式だからできることももちろんあるし。
一つのファイル方式の欠点は何か事故が起こった時にあっという間に全体に及んでしまうという、その問題はありますよね。
確かに。
編集失敗した時も一つのファイルでは一部で済まなくて全体がなんかおかしくなっちゃったりとか、そういうことはありますけど。
そこもね、今それこそバックアップ。昔と違ってね、バックアップがちゃんとタイムマシンとかで取れているのであれば、そんなに恐れなくてもいいかなという気もしますね。
スピーカー 1
だからまあ、ショータイムで分けるという常識を見直す必要が。個別のファイルでやった方が書きやすいみたいなことがあったとしたら、例えばズーム機能をつけたりすることが多分今度は必要になってきますけども。
スピーカー 2
でも逆にズーム機能があれば、ファイルを分ける必要はほとんどなくなってくるということですけど。
まあそうですよね。
だってそういう意味では、プロダクト型でいうズーム機能みたいなものっていうと、それこそオーグみたいに、
EMACSのナローイングの機能をそのまま使ってオーグだとその一部分だけ表示するっていう方式ですよね。
他の部分を隠すっていう形になるわけですね。
スピーカー 1
それだけでも別に問題なくて、実際例えばこの1万字とかがあるファイルで項目を開いたらほぼ他の項目も見えなくなるんで、ズームしてるようなもんなんですけどね。
スピーカー 2
だからそれがやりたいときって、例えば編集とかの時間とかをその範囲内だけでやりたいとか、そういう需要はあるかもしれないですね。
スピーカー 1
そうですね。
例えば僕の場合、スクリプターの一つのチャプターを表示してるときに、オプションコマンド上とかで押したら、前後の章にそのまま移動できるっていう機能がありまして、
あれがいいなと思ってたんですけど、一つのファイルでやってる場合だったら、ショートカットキーで次の見出しに移動するみたいな。
次の見出しの下とか上に移動するっていうショートカットキーを設定すれば、ほとんど同じことになるんで。
どう長くなってもテキストファイル本で10万字だったとして、使えないことはないでしょうね。いくらなんでも。
スピーカー 2
現在だったらテキストファイルの10万字っていうのは全然問題はないですよね、きっと。
スピーカー 1
そう考えたら分ける必要がなくなれば、もっとやり方が変わってくるな。
例えばiPhoneとかで第4章とか直したいっていうときに、ちょっと面倒が出てくるかもしれないですけど、パソコンが使える環境であれば何も問題はなさそうですね。
スピーカー 2
やっぱりこれ、ファイルで分けていたものを分けなくなると、多分書き方というか内容にも影響してくるんですよね。
境目をまたがった編集をやることが増えてくると思うんですよ。
スピーカー 1
確かに。それが良いことか悪いことか。
良いことか悪いことか分かんないですね。
僕の場合は先ほど言った切断を求めるところがあるので、4章を書いているときに3章のことは気にしたくないからファイルを分けているところがあるのかもしれないですね。
スピーカー 2
だとするともしかしたら良くない面もあるかもしれないですね。
スピーカー 1
ここは難しいところで。
でも、この1つのファイルをやると順番を変えるときとか、新しいところを変更するときとか、見出しの名前を変えたくなったときに、
いちいちファイル的何かを考えなくていいというのは非常に重度が高いなとは思いますね。
スピーカー 2
そうですよね。前にリビジョンの編集、合体して修正してたときに、
言われたんですよね、倉下さんに。
ここからここに動かすのか、みたいな。
スピーカー 1
そうそうそうそう。
スピーカー 2
僕にとっては、こっちの章の段落をあっちの章のあそこに移動するというのは全然当たり前の感覚だったんですけど、
あ、そんなに上下動かすんだ、みたいな感想を倉下さんが持ったということがあって。
スピーカー 1
そうですね。あれは僕の中で言うと、近所に移動するというよりは海外に引っ越しするぐらいの感じですね、フィーリングで言うと。
スピーカー 2
たぶん今思ったのですが、それってファイルが分かれていたらやらないかもしれないですね。
スピーカー 1
たぶんやらないと思います、それは。やらないというかやっぱり、
スピーカー 2
やろうとすると代行時間が。
スピーカー 1
そうそう、変えていきません、当然のように。
スピーカー 2
そうなると実は結構内容に影響してきちゃうんですよね。
スピーカー 1
でもそうか、面白いな。だから僕は1個1個の章をファイルで分けて、1章を終わらせたらもう2章のことしか考えないしっていう切断的前進を繰り返すことで、
自分の執筆を進めてきた節があるんですけど、この段階で書き方が変わったとしたら逆に面白いなと思いますけども。
スピーカー 2
そうですね。それがエスカレートして、第2章と第4章の偶数章の最初の段落の終わりでインオフみたいなことを始めるともうダメなんですよ。
新しいエディタの可能性
スピーカー 1
それは切断が効いてないですよね。
スピーカー 2
それはもう行的な。
スピーカー 1
このまま難しいところで、ツールとかOSとかの事情に人間が合わせなければならないのが良いことかどうかっていう問題もありつつも、
1つでファイルやるのは自然だなという気もしてまして、だからこの開閉とか今ブロック単位での移動ができないんですよ。
例えばこの状態で行を移動させてもこの行だけが上に行くだけで、いわゆるアウトライン的操作ができない。そこはまた機能を書こうかなと思うんだけど。
仮にショートカットキー1行でこのブロックが1つ上に移動できるとしたら、ほとんどこれでいいよなという感じがしますね。
スピーカー 2
そうなったらもうほとんどプロダクト型アウトラインなんですよね。
スピーカー 1
テキストライン、テキストエディターとして機能を持っているほぼオーグっぽい感じになりますね。
スピーカー 2
ちなみに今の状態でこの折りたたまれた状態でカットしてペーストしたらどうなるんですか?
スピーカー 1
まずどうかな。選択しようとした時に、この最後の行の文字までか、1個を後ろに行った瞬間に。
多分普通にしたらこの行だけが。
スピーカー 2
これできるんじゃないですか、ひとして。
スピーカー 1
いやどうやろう。
できてるわ。できてましたな。
この下のやつは後ろがまとまってますよという情報なんだな。
スピーカー 2
だからそこまで行くと後ろごとコピペできるわけですよね。
スピーカー 1
だからキーで移動しようとしなければもうすでにできるわけですね。
スピーカー 2
多分これ元の機能に入ってるんですよ。
スピーカー 1
多分そうでしょうね。おそらくそうだと思います。
この折りたたんで出てくるこれが全文字の代表みたいなことになってるんでしょうねきっとね。
スピーカー 2
だからできるんですよ。普通にコピペすれば。
スピーカー 1
あとはショートカットキーだけがある。僕はキーで動かしたいのでショートカットキーを付けますけど。
じゃあこれでだいぶできてしまうな。
スピーカー 2
できてるんじゃないですか。
スピーカー 1
エディターを一から作るって言っても、
例えば僕が考えた最強のエディターみたいなイメージがあって、
それを淡々と実装していくというんじゃなくて、
もう探り探りなんですよね。
スピーカー 2
そうですね。でも探り探りでもこれだけのものが短期間でできるってことですよね。
スピーカー 1
僕がこれを自慢したいということもある方面、
これぐらいのことで最低限のコンテンツを1週間でもうできてしまうということ自体が、
スピーカー 2
新しいライフハック時代がやってきてるなという感じがあるというのが今回の本題なんですけども。
スピーカー 1
一家に一台、一書き手に一エディターみたいな時代が
スピーカー 2
とうとうやってくるんじゃないかなという気がするんですけども。
自作エディタの魅力
スピーカー 1
もちろん例えばEmacsはその理念ですよね、ある意味で言うと。
スピーカー 2
まあそうですね。
スピーカー 1
ただEmacsの拡張って言語が難しいんですよ、あれ。
ちょっと名前忘れましたけど、書き方が難しいんですよね。
スピーカー 2
Emacs Lispですか。
スピーカー 1
そうそう。
あれをちょっと見た目も分かりにくいですし。
スピーカー 2
いやあれは大変ですよね。カッコカッコカッコカッコみたいなのね。
スピーカー 1
そうそう。
エレクトロンであればJavaScriptをTypeScriptで書けて、やっぱりChatGPTが一番得意な言語の一つなので、
PythonとJavaScriptは。
なので、僕はこれのコード自身をほとんど書いてないんで、
コピペとちょっと合わせて修正するぐらいのレベルしかやってないんで。
たくさんのノードツールとかエディター使ってるんで、
アイディアだけは無限にあるんですよね。
こういうのがいいんじゃないかっていうのは。
それをいろいろ相談しながら書いていくだけでできてしまうし、
今ここにステータスバーがあって文字数だけしか表示されてませんけど、
ショートカットキーを押すとタイマーが出まして、
こうしたらタイマースタートでタイマーストップとかできるんですよ。
素敵。
これまたしょうもない自慢話なんですが、
今作業記録のファイルなんですけども、
上にタスクリストがありまして、
ウィンドウごとにタイマーがあるんで、
ここでも表示された別のタイマーが出てくるんですけど、
タスクを選択というボタンを押すと、
タスクリストの中でここの左の上に表示されたタスクリストで、
未着手のタスクが出るぐらいですね。
これを押すと妄想のタイマーが始まってしまうと。
これを押すと自動的にここが終了になってしまうという、
ミニ作業記録タイマーがエディターに内蔵されているという、
しょうもない自慢なんですけど、
結局思いついたありとあらゆることがエディターの中で実装できるし、
Obsidianのようなプラグインの知識も別に必要なくて、
エディターの元々の画面、機能そのものを、
チャットリピーターと一緒に作っているので、
こういうのを作りたいんだけどって言ったら、
じゃあこう書けばいいんじゃないですかみたいなやり取りで、
実装できてしまう良さがあって、
趣味として非常に楽しいですね。
スピーカー 2
それが楽しい人にとっては本当にいい時代というか、
機能の実装と工夫
スピーカー 2
そうですよね。
結果的に役に立つものができるわけですもんね。
スピーカー 1
やっぱりある種のツールでないと体験できない体験っていうのを、
さっきのオーグモードのようなことを僕は体験しましたけど、
そういう想像力の育成のバーとしてもいいかなという気がしますけどね。
こうなってたら面白いんじゃないかなっていうのを、
エディターとかノートツール使ってて思う時があると思うんですけど、
それを実装してみると。
ダメだったら元に戻すと。
それがやっぱり簡単にできる。
自分でコードを書くじゃないですか。
実装した機能を削除しにくいんですよ。
スピーカー 2
自分で書いたから。
スピーカー 1
でもGPTが書いたやつだとサンクコストが低いんで、
まあいいかっていう風になりやすいのもいいところだと思います。
スピーカー 2
そうですね。
スピーカー 1
試しやすいところはいろいろありますね。
あと最近はメモとか、メモ場所をどうするかみたいなことも
いろいろアイディア考えてまして、
また次回お見せするときその辺が出てくると思うんですけど、
そんな感じで。
一応リンク機能とかオブシリアンにある機能からスタートしたんですけど、
一番感動したのは全項目の開閉というオーグモードの機能で、
たぶんね、通常のオブシリアンでは全項目の開閉はキーではできるんじゃないかな。
ちょっとやったことないですけど。
できるだけでもすごいですね、それが。
というところかな。
他にもいろいろ細かい機能あるんですが、
それは細かいので、またどこかの機会にしたいと思います。
とりあえず自分で作りたい方はMacでもWindowsでもLinuxでも
エレクトロンは使えるんで、
ノードJSでCodeMirrorっていうのをインストールしたら、
あとはかなり自由度の高いエディターが作れます。
そしてボタンとかが付いてないいいエディターはやっぱりいいです。
いろいろ表示されないエディターの良さっていうのは、
スピーカー 2
何週回っても色あせない感じがしますね。
スピーカー 1
オブシリアンはね、やっぱりちょっとボタンとかサイトバーがいろいろ表示されすぎですね。
スピーカー 2
確かにね。
スピーカー 1
その手の作業をするにはいいんですけど、
やっぱり集中して書きたいっていう時にやっぱりちょっと邪魔な時があって、
もちろんそういうモードにするやつを選べば多分できると思うんですけど、
全モード的なのが多分あると思いますが、
でもシンプルに始めから無い方が無くてもいいんじゃないかなと思いますけども。
スピーカー 2
そうなんですよね。ツールバー隠してもあるじゃないですか。
隠してもあるから。
確かにそうですよね。
スピーカー 1
必要な時は出しちゃうわけですもんね。
始めから無くて全てキーでやるというVimとかEmacsが取ってる方針は、
多分正しいと思いますね、あれは。
モダンじゃないけど。
スピーカー 2
そこが難しいところでね。
結局そのままだと一般のコンピューターにそんなに気持ちがない人が使うには厳しいだろうということで、
いろいろアイコンつけたりボタンつけたりメニューつけたりするようになっていった先が、
無いといいよねみたいなことを言われるようになってしまうという。
ことごとでやめられないでしょうね、結局。
それが極限までいってしまったのがマイクロソフトのリボンですよね。
スピーカー 1
でも確かに最近大学生にワードを教えてるんですけど、
ウェブ版で使えるワードとダウンロードして使うワードの機能が違うんですけど、
ウェブ版の方が制限されてて縦書きとかが多分設定できないみたいな感じで、
この前ダウンロード版の使い方を教えようとしたんですけど、ほとんど教える人なくてリボンから勝手に見つけてたんですよ。
そこはやっぱりすごいなと思いましたね、リボンの力強さ。
スピーカー 2
そこを探せばあるっていう。
スピーカー 1
そうそう、まさにそういう感じ。
ここのどっかにあるだろうっていうスキームがちゃんと確立されてるって、
他のUIはある段階にいる人にとっては非常に便利だったなというのは思いました。
スピーカー 2
そうですね、その代わりリボンにない機能はないことになってしまった。
スピーカー 1
確かにそうか、そういうことになってしまった。
スピーカー 2
膨大なリボンにない機能が本当はあるわけですよね。
確かにそうだよな。
今それVBAから呼び出さないと使えない機能みたいな。
スピーカー 1
さすがにマニアックすぎる。
ほどほどのエディターっていうところが、エディターっていうかアプリケーションですね。
ほどほどのアプリケーションの難しさですよね。
スピーカー 2
だからそれこそ今は、それこそAI使ってこういう機能ないですかってアプリ自体に聞いてみて、
それはこのショートカットこれですよって教えてくれるみたいな。
あるいはその機能ないんですみたいな。
そういうふうになって、いちいちごちゃごちゃボタンで表示するっていうのはもうやめるという。
そういうふうにならないものかと妄想してるんですが。
スピーカー 1
コーパイロットはおそらくある程度はそれの需要に答えてくれるはずですけどね。
確かにパソコンわからない人がメニューの右にあるヘルプとかを使ってるのを見たことがないですし、
自分も使ったことはほぼないんですけど。
スピーカー 2
使わないんですよね。
スピーカー 1
あれ見つからないですからね、求めてるものが。
スピーカー 2
そうなんですよ。
スピーカー 1
あるってわかってても見つからなかったりするんですよね。
本来はイルカ君がその役割を担うはずだったんですけどね。
そうそう。
スピーカー 2
カイル君でしたっけ。
スピーカー 1
カイル君がユーザーのヘルプしてくれるはずだったんですけど、
スピーカー 2
ようやく現代にやって初めて機能するものが出てくるんでしょうね、ギト。
僕もパイロットが使えるようになってから、
ワードでVBAを使ってグレップ風のことをできるようにするみたいなことが
特に意識しなくてもやれちゃうことが出てきたりとかしますもんね。
スピーカー 1
だからね、生成AIを使うと人はバカになるみたいな話がある一方で、
明らかに今まで知識はあったけど、概念は知ってたけどやってなかった人が
ChatGPTに相談してミニプログラマーみたいなことをしてるという事例をよく聞くんですよ。
だからやっぱりエンファンスしてる力は確実にあるなぁと思いますけどね。
スピーカー 2
そうですね。
そこの部分と、そこはAI使わない方がっていうところの兼ね合いというか。
スピーカー 1
そうですね。
スピーカー 2
一方でね、パイロットさんにこの構成、書きかけのこの文章の構成、アウトラインの構成どうですかって聞くと、
直してくるんですけど、何と言うか、嫌がらせかと思うような直し方をしてくるんですよね。
スピーカー 1
文法がおかしいとかではないわけですよね?
スピーカー 2
ではないです。この構成がダメだと。
事実と意見が混ざってるみたいなことをやってます。
それわざとやってんだよみたいな、そういうのあるじゃないですか。
スピーカー 1
なるほど。
スピーカー 2
混ざってるんじゃなくて。
そこもね、使い方の良し悪しで、そこの辺りももう少しこう、上手く使えるってのは当然あると思うんですけど。
そうですね。
難しいですよね、逆に。それを上手く使うために時間を食っちゃって。
スピーカー 1
ありそう。
スピーカー 2
だったら自分で考えた方が良かったなっていうことも結構ありますが。
スピーカー 1
そうですね。だから、やりたい適正作業と適切なプロンプトの応答というのが当然あって。
人類はまだそれほど経験を積んでいない以上、プロンプトの模索から始まるんですね、当然のように。
例えば今20歳だったら、そういうのを経験積んどくことに価値があるかもしれませんけど。
おっさんになればなるほど残り時間がかかってくるんで。
もっとこう、いわゆる本質的なことをしたいなという感じはしますが。
難しいですね。
難しいですね。
スピーカー 2
でも一方では思い入れがない作業はどんどんそっちにぶん投げるっていう風になりますよね、やっぱり。
それはもうなってくると思います。なってくるべきやとも思います。
スピーカー 1
最初の冒頭で言ったオブシリアンがベース機能をつけたことによって、プロパティをつけたくなってくるっていう病気が発病するんじゃないかって話しましたけど。
あれはもう全部生成案がするといいと思うんですね。
ファイルを作った日とかその手のもの、自然なメタデータは人間がいちいち入力する必要は全くなくて、全て生成案にしてもらったらいいし、もしつけるんであれば。
最終的にはそんなものがなくても動くデータビューみたいなのがいるはずで。
メタ情報を自分で付与しなくてもファイルから勝手に読み取ってくれるインフォボックス、コセンスのインフォボックスがやってるのはまさにそれなんですけど。
タグ付けみたいなのはもうそれはいらなくて、あなたは文章を書きなさいっていうのがコセンスなんですけど。
デジタルノートの楽しさ
スピーカー 1
それがデジタルノートにおける生成案の使い方の一番有効性が高いものじゃないかなと思いますが。
スピーカー 2
なるほど。
スピーカー 1
でもね、タグ付けしていく作業とかって地味に楽しいんですよ。
なんていうかな、ちまちましたことをやっていくくらい楽しみみたいなのがあるんですよね。
心の半分では無駄なことしてるなと思いつつ、心の半分では充足感を感じてるんですよね。
だからね、ついついやっちゃうんですね、あれ。
スピーカー 2
だからそのモードに自分がなってるときはいいんですけど、続かないんですよね。
スピーカー 1
そのモードは一生は続かないんですけど。
そうですね、この辺は難しいとこなんですけども。
そんな感じで、自分のエディターを作ってて非常に良いという話と、皆さんもちょっと作って、もし既存のエディターに不満足を得てると。
その満足の大半が機能が多すぎるという不満足の場合は、自作されると非常に満足度が高い結果になると思います。
機能が足りないという場合はやめた方がいいと思いますけど。
VS Codeで満足できひんという場合はVS Codeのエクステンションを変えた方がいいと思うんですけど。
こんなにいらないよという場合は、原始的なエディターを作ってみられるのがいいんじゃないかと思います。
スピーカー 2
原始的なエディターでも相当な機能を持ってますからね、そもそも。
スピーカー 1
それはそうでございます。
というところかな。
というところで何かお知らせしたいことがございますでしょうか。
スピーカー 2
今日は特にないです。
スピーカー 1
エディターでこんな話で困ってるというのがあれば、明日はぐちわせキャスト。
だからぐちわせアルファベットキャストまでいただければと思います。
では今回はこれまでにしたいと思います。お疲れ様でした。
スピーカー 2
お疲れ様でした。
01:15:52

コメント

スクロール