の作業記録
原稿を進める水曜日
- 作業記録の共有
- Textbox+シャッター機能
- ツールの整理
- 大きな活動をまとめる手法検討
- 新エディタアイデアの検討
- メルマガ+原稿2
- KW+ミニエッセイ
- 環読プロジェクト+読書メモ
8:00
おはようございます。本日は細かい作業をたくさん進めましょう。
Textbox:
シャッターの開け閉め機能を実装します。
＊ ＊ ＊
できました。
あとは設置してあるシャッターボタンのデザインですね。
＊ ＊ ＊
とりあえずOKとしておきましょう。
ツールの整理:
ツールの役割を俯瞰的に整理しておきます。
だいたいこんな感じですかね。
＊ ＊ ＊
publish:ツールの生態系図 - 倉下忠憲の発想工房
9:00
大きな展望をまとめる手法:
昨日は、紙にラフに書きましたが、ある種の書式化ができたらな、と思います。
＊ ＊ ＊
うまくまとまらず。
＊ ＊ ＊
publish:「方法」のカード - 倉下忠憲の発想工房
新しいエディタについて:
CotEditorは単発の文章を扱うのには手軽だが、複数の文章を並行的に扱うのは苦手。
VS Codeはプロジェクト単位で情報をまとめるのは得意だが、プロジェクト横断的に文章をまとめるのは苦手。
この辺をなんとかしたい。
Ulyssesあたりが一つの解なのだが、それとは別の手法を考えたい。
Workflowyは情報を操作する具合は抜群だが、バレット形式が主体で、リスト上に並ぶのでちょっと考えたい（でも最終的にはWorkflowyでいいかもしれないという思いはある）。
＊ ＊ ＊
最終的にElectronでデスクトップアプリ化するのか、それともTextbox上で実装するか、あるいはTextboxと似た仕組みでローカルサーバー上で実装するかはまだよくわからない。自分にとってはTextboxかそれに準じる仕組みが一番楽だが、他の人には簡単に使えないものになってしまう。Electronなら配布が可能だ。
しかしそうなると、考えなければならないものが大量に出てくる。もっとちょっとしたことでやっていきたい。
＊ ＊ ＊
ファイルについて。
たぶん、一番の検討課題がファイルの扱い。
文章の塊を一つのファイルとして扱うなら、そのエディタはビュアー的なものになるだろう。それはそれで構わない。ただし、名前が付けがたい対象、便宜的な名前しかないものの扱いが厄介になる。特に、Textboxはファイル名でリンクを作るので、ファイル名が変わってしまうとリンクが機能不全を起こす。
Scrapboxのようにテキストの置換を行えばよいわけだが、それはそれで大仕事になりそう。
もし個別にファイルを作らず、大きなJSONで管理するならば、IDが付与されるのでそこまで大きな問題はない。
あと、Textboxの他のファイルのように、あるファイルから別のファイルへの名指しはほとんど行われない。せいぜいインデックスと「次のセクションへ」くらいだろう。であれば、個別のファイルの名指しはそこまで重視しなくてもいい、とは考えられる。
ただしそうなると、そのツール外で編集中のデータは扱えなくなる。ファイル形式ならばDropboxなどを経由して他の端末でも扱えるわけだが、その自由度がなくなってしまう。
Scrivenerは本体用のファイルと、エクスポートしたテキストデータを持っていたが、まあそこまではやりたくない。
ツール上での扱いを考えれば、JSONがよく、ユーザーの利便性で考えればテキストファイル単位が良い、ということか。
＊ ＊ ＊
Dropboxなどでの扱いを考えると、やはりTextbox/listフォルダに一緒に入れる形ではない方がよいかもしれない。でないと、目視で探すのが難しすぎる。
ふむ。
二つのローカルサーバーを立てるのは面倒なので、Textboxと同じフォルダの中でそれ用の仕組みを作るのが面白いか。
それかTextbox/list/document/とかにするか。
＊ ＊ ＊
index.htmlと同じ階層にdocumentprocessor.htmlなどを置き、そこからファイルを操作をできるようにする？
リンクによってファイルを開く仕組みはまったく同じでよい。扱うファイルのフォルダが違うだけ、という感じ？
トップページが二つある形になる。それが好ましいのかどうか。
というか、もともとエディタ的な構想もあったのだ。文章と、引用文と、書誌情報とをすべて統一的に扱えるツールとして。
現状もjsonなどで情報がまとまっているわけで、documentprocessor.htmlにおいても実装はできる。が、わざわざツールを分けるのが、人間がファイルを扱う上でフォルダが分かれていた方がよい、という話なのが虚しい。iPhone上でTextboxが動けば何も問題はないわけだが。
＊ ＊ ＊
確認してみたが、1writerでも、インデックス用の頁を開けばなんとかなる。ということは、このままTextbox上でやっても問題なさそう。その方向でちょっと考えてみよう。
ただ、文章を書くときには画面も「それ風」の佇まいをしていて欲しいことはあり、その点ではトップページを分けた方がいいかもしれない。
13:00
DP:
ちょっとだけ雛形を作っておきましょう。カスタマイズ可能なエディタ、並行的な原稿を扱うのに適したエディタ。そういうコンセプトでTextboxとは別のhtmlで構築していきます。
＊ ＊ ＊
最初の問題は、エディタ領域をどうするか。Textareaにするか、編集可能なDivにするか。
＊ ＊ ＊
とりあえず、Textareaで実装した。で、考える。
まず、プレビューモードが欲しい。編集とプレビュー。で、アウトラインモードもあったら良いかも。あるいは、プレビューモードがアウトラインモードを兼ね備えている？いや、そうはいかないか。
この動作に合わせて、TextareaかDivかが決まりそう。
たとえば、文章の入力中にマークダウンで見出しを入れたとして、その行の色を変えたり、文字サイズを大きくしたいのかどうか。
画像なりなんなりの挿入をしたいのかどうか。いや、それはプレビューでいい。
とりあえず、Textareaでいいか。
＊ ＊ ＊
Textareaのマークダウンから、編集可能なDivでのHTMLの変換は簡単にできました。
問題は、逆変換。これはTextboxでは実装しておらず、単にもともとのファイルをもう一度読み込む形です。
つまり、previewを押したらいったんその内容で保存しておき、editに戻るときにその保存した内容を再読み込みする。こういう形。preview上で編集しないのでこれはうまくいきます。
もしそれを可能にするならば？
h3をマークダウン記法に戻すこと自体は問題ありません。しかし、それ以外の要素が直にHTMLで書き込まれていると厄介です。
あとはPタグの除去などですか。
どうしようか。
プレビュー上の編集をしたいかどうかがまずあるのと、もしアウトラインモードを付けるならば、同種の処理はまず必要になりそうです。
アウトライン操作をするならば、要素はDivに入っていないとかなり厳しいでしょう。ULの形になっているのが一番楽です。
で、そうした操作を経て、保存するときにどうするのか。
まあテキストをフラットに並べればいいわけですが。
＊ ＊ ＊
ものすごく簡単な逆変換ができました。まだ不都合は多いでしょうが、これくらいのことであればリッチテキストとマークダウンの行き来はできそうです。
あとはアウトラインモード。
おそらくこれが一番面倒。テキストからアウトラインにするのか、HTMLからアウトラインにするのか。どちらにせよ、再帰的な探索が必要になりそうです。
で、その結果からUL/liを構築することで操作可能にするか、あるいは入れ子上のdivとして実装するか。こちらの逆変換は簡単そうですが、変換が面倒そうですね。
14:00
KW:
ミニエッセイを更新しましょう。
＊ ＊ ＊
OKです。
16:00
メルマガ:
原稿を書きます。
＊ ＊ ＊
2800文字ほどの原稿が書けました。これで全体の半分くらい。