の作業記録

ゆっくりしたい日曜日

8:00

おはようございます。今日はややゆっくりのスタート。来週の予定を確認し、いくつか書き物をしたらあとはゆっくりしておきましょう。

来週のSTL確認:

まずは来週の予定の確認を。

＊　＊　＊

タスクの設定。

＊　＊　＊

だいたいOKです。

今週の週報:

今週はとにかく忙しかったです。作業が多かった、あるいは締め切りが決まっている作業が多かった、という感じでしょうか。

LMは初稿の最後の追い込み作業ということで、なんとか今週中に編集者さんに提出できました。いくつかリテイクのメッセージが返ってくるかもしれませんが、それを除けばおおがかりな作業は一段落というところでしょう。あとは、ゲラと色校の確認などを8月に向けて進めて行くことになりそうです。

THは、chapter13を進めようと思っていましたが、LMの作業に忙殺されていたのでほぼ進まず。一応アウトラインだけは検討できたので、それをベースに文章の書き下ろしを進めます。二週間でchap二つ分進めたかったですが、今週は欲張らない方が良さそうです。とりあえず、来週の木曜日までにchap13を送信できるようにしておく、というのが目標です。

PTは、chap3を一応書き終えました。あとは、おまけてきなコンテンツを残すばかりで、こちらは過去原稿のアレンジでいく予定なので、作業量はそう多くないと予想します。やってみないとわからりませんが。それが終わったら、全体のまとめのようなものを添えて、それで初稿は終わりとできるでしょう。あるいは初稿の手前くらいかもしれませんが。

今週は法事があり、次は8月にお盆のイベントがあります。それを除けば、しばらくは安定ですかね。

なんとなく「テキストエディタ作りたい良く」が生まれていますが、最近Textboxで作っているcurrentTextの具合も合わせて検討したいところです。

9:00

BCB:

作成したドラフトepubの確認があと少しだけですので、それを進めておきましょう。

Mn:

作成していただいたPDFを確認します。

＊　＊　＊

PDFを確認して、全体的なコメントを返しました。

拡張型テキストエディタ構想について:

emacsやObsidianのような、機能を拡張していけるエディタを自分でも作ってみたいという欲望があります。拡張機能というよりは、そのままエディタの機能を書き換えていけるもの。そのベースとなるプライマリーなエディタを作る、というコンセプトです。

ようは必要最低限のエディタ機能だけを作って、あとは自分でなんとかしてね、というもの。それだったらまあ、Obsidianを使えよ、という話なのですが、あくまで自分でやりたいという趣味的欲求です。

ただし、Textboxそれ自体が拡張型ツールなわけでして、わざわざ別に作るよりは、Textbox内でテキストエディットの機能を作る込む方が、プロジェクトが分散せずに済む利点はあります。

その代わりショートカットキーの衝突の問題があって、自由度が下がります。ただ、最近思ったのはvimのように「モード」を切り分けることで、ショートカットキー空間を別途設定できる可能性がありますね。そういう方向を検討してみてもいいでしょう。

ただし、Textboxに内包してしまうと、他の人に使ってみてよ、というのはさらに難しくなります。TextboxそのものをElectronでアプリケーション化する方法もありますが、はじめからエディタをElectronで作っておくのも悪くない選択です。

内部的にmdファイルを扱うのであれば、Textboxとエディタが別アプリであっても問題はありません。なんなら、二つを連携させることすら可能でしょう。

という感じで、お互いにメリットがあるのでなかなか決めづらいですね。

Textboxにエディタを実装する場合、ファイルエクスプローラーをどうするのか、という問題がありますね。

Textboxでは最初にファイル名を決めて、そのリンクを作り、そこからファイルを生成するという手順ですが、普通のテキストディタでその運用はよいのかどうかも気になります。

＊　＊　＊

理想のイメージについて考えましょう。

まず新しい領域を立ち上げます。その段階ではファイルに名前をつける必要はありません。で、中身を書いて保存する。このとき、特定のフォルダになるのか、どこを選べるのか。選べるとして、たとえばプロジェクトAの作業をしているときに、プロジェクトAのフォルダに保存するようにするのか。

そうですね。まず、この段階で課題が見えてきます。

Textbox型では、フォルダ分けをしません。しかし、Textbox以外の場所では、私はプロジェクトごとにフォルダを分けています。Gitやmakeコマンドの利用などがあるので、分かれている方が合理的なのです。

この思想とTextboxをどうマッチさせるのか。Obsidianでは、vault内にフォルダを作れるので大きな問題にはならないのでしょうが。

10:00

R-style:

記事を書きます。

＊　＊　＊

publish:モードとプラグインとコミュニティー | R-style

14:00

奈良に新しくできた、「ほんの入り口」という書店にお邪魔してきました。小さな本屋さんですが、個人の書店という感じで実によかったです。

KW:

Workflowy連載を続けましょう。

＊　＊　＊

Workflowy入門 | Knowledge Walkers

拡張型テキストエディタ構想について:

Electronにすると、若干開発が面倒になる点はありますね。コンパイル後でないとエラーが出る、みたいなものもありますので。

Flutterは結構回りくどいので遠慮するとして、これはアプリをどう開発するのか、という話につながってきます。

で、ファイル・フォルダ問題。

執筆作業、特に書籍の執筆においてはフォルダ分けしておくと便利なことは多い。もちろん、便宜的なフォルダア分けというやり方もあるだろう。パソコンの内部には均一のフォルダ内に入って入るのだけども、どこかでインデックスを持っておき「このファイルと、このファイルはプロジェクトAのもの」という情報を管理する（実際、パソコンのフォルダがやっているのがこれだ）。でもって、そのファイル群に対して、アウトラインを作ったり、PDFを作ったりする。そういうやり方。

そのインデックスへの操作が、簡単であれば、フォルダを作っているのと大差な環境になるだろう。でもって、一つのファイルを複数のプロジェクトに紐付けることもやりやすくなる。

とは言え、ごく普通にフォルダ管理していると、他のツールとの共存がしやすい。特にGitはそうだろう。フォルダ分けしておかないと、なかなか面倒になるように思われる。もちろん、「書き物全体」のリポジトリを作っておけば、問題ないわけだが。

一応GitHubは、一つのリポジトリが10GBまでいけるらしい。テキストだけならばほぼ無限のサイズと言える。

テキスト全体を管理することも不可能ではない。

＊　＊　＊

両方を合わせることはできるか。

パソコン上ではフォルダ式で管理しておき、そのエディタ上ではそれを無視して管理する、というような。ふむ。