VS Code + Git + Markdown で小説を書く
Visual Studio Code
Microsoft 製のテキストエディタ
プラグイン
textlint
Git Graph
執筆作業動画を配信するときは、 https://vscode.dev を使う
Git
バージョン管理
共同作業せず、自分だけで使っている。いまのところ。
GitHub に置いてるけど、強い理由はない。BitBucket でもいい
ひとつのリポジトリだけを持っている
いわゆる monorepo
ひとりだしね
VS Code でだいたい操作する
genron-6-3-synopsis みたいなブランチを作って作業する
ちょっと複雑なことするときは、Sourcetree を使う
Dropbox 系の自動同期は使わない
手癖でしょっちゅう commit , push するから
main ブランチにマージするときだけ、コミットをまとめる
でも、まとめないほうがいいかな、と思い始めている
Markdown
ツールではなく、フォーマットだけど
--- で囲まれた frontmatter 部分にメタ情報を入れる
ゲンロンSF創作講座の場合は、提出済みの梗概とアピール文も、frontmatter に入れる
ゲンロンSF創作講座の梗概を提出するまでは、梗概を本文として記述する
空行が段落の切れ目。
行頭の禁則処理は、ここではやらない。
ディレクティブ拡張形式 で文章の構成に関する情報を記述する
Scrivener を使っていたとき、便利だったので。
::act[…] が幕・場、
::seq[…] がシーケンス
::scene[…] がシーン
::separator が、後述のフォーマットしたときの、空行
::todo, ::note はメモ
整形
自作のツールで、Markdown 形式の原稿を、提出用のプレーンテキストに変換する
HTML（正確には React アプリ、Next.js アプリ）を出力する HTTP サーバーが立ち上がる
Markdown の Frontmatter や汎用ディレクティブは、この段階で strip する。
段落最初の文字の字下げや、そのときの禁則処理もする。段落間の空行も、ここでやる。
ざっくり文字数カウントする。
印刷するとき用に、行間を多めに開けたりできる。
ゲンロンSF創作講座 WordPress 用に、文頭文字の調整をしたりする。
縦書きモードとかは必要になったことがないので、ない。でも、星々ワークショップの提出では必要なので、実装する予定。
Working Copy
iOS の Git ツール兼エディタ
2年ほど在宅勤務だったので、ほとんど電車で書くことはなかった。
これから出勤が発生するので、エディタを探すかも。
その他、お気持ち
設定関連情報、梗概、実作は別のファイルにしてもいいかもな、とは思っている。
なんかの音声配信で、たぶん橋本輝幸さんが、「提出・編集ツールを作って運用しているアメリカの作家がいる」って言ってた気がする。そういうのいいなぁって思う。
Markdown で編集アノテーションをする、っていう試みがあったとおもう。
なんかツールをかませたら、データは git + markdown で保持して、UIをリッチにするとかはできるかも知れない。
出版社ラムダノートの鹿野さんの考察
> 「内容をすべて書き出した」状態から「じっくり読まなければ何となくいい感じ」ゾーンにもっていくまでの間は、各コミットに必要以上に意味を持たせることはあきらめましょう。 完全に正史モデルを採用する必要はありませんが、この段階は開墾地をブルトーザーで整地するようなものです。 「木を抜く」作業と「穴を埋める」作業は並行してできるわけではないし、あとから一方の作業だけをやり直したいことも通常はありません （将来もし穴が必要になるとしたら、それは別の作業として考えるべきでしょう）。 それなりの規模の区画ごとに、全体の出来を眺めつつ、もくもくと均していくのが現実的なはずです。
> 一方、「じっくり読まなければ何となくいい感じ」ゾーンまで到達した原稿は、問題とその対処がコミットとして明確に切り分けられるので、修正の意図をはっきりさせた最低限のコミットを作り、それをmasterにマージするようにしましょう。
この記事が気に入ったらサポートをしてみませんか？