自分が入力したバイトだけが保存されるよう、ファイルを唯一の真実とした

マークダウンの表で単語を一つだけ直したのに、Gitでは文書全体が変わったように見えることがあります。

エディターが保存するときに、表の間隔と改行を整え直したためです。ユーザーが入力していない空白までファイルに書き込んだのです。Typoraが表の列幅を揃えるためにパイプの間を空白で埋めるのが、その一例です。

moteは違う方法で保存します。ファイルの原文はそのままにして、太字や表、数式といった画面上の効果だけをその上に表示します。そのため、保存するときはユーザーが変更したバイトだけが変わります。

保存前に変更量を確認できます

moteは、保存すると変更されるバイト数をステータス行に表示します。

ファイルを最初に開いたときの原本と現在の内容を比較し、実際に異なる部分だけを計算します。編集すると17 B 保存待ちと表示され、すべて元に戻すと保存済みファイルと同一に変わります。保存した後は、保存完了 · 17 Bが次に編集するまで残ります。

この数字はGitとは関係なく動作します。Gitリポジトリではないフォルダーでも確認でき、ステージングやコミットの状態にも影響されません。

ただし、Git diffに表示される変更量とは同じです。保存する前から、自分が直した部分だけが変わるのか確認できるのです。

表の一つのセルを直せば、そのセルだけが変わります

違いは、表を編集するときに最もよく分かります。

ライブモード（Live）では、表がグリッドとして表示されます。カーソルがあるセルだけが原文に変わります。その中の単語を一つ直して保存すると、ステータス行には+8 −6 Bと表示されます。Git diffにも該当する行だけが上がります。

列の整列とパイプ間の空白はそのままです。*の箇条書き記号や行末の二つの空白にも触れません。最終改行がなかったファイルに、新しく改行を入れることもありません。

貼り付けも同じです。クリップボードのテキストを別の形式に変えず、そのまま挿入します。追加された量はステータス行ですぐに確認できます。気に入らなければ、一度元に戻して、保存済みファイルと同じ状態に戻ることもできます。

ファイルのほかの特徴も維持します。CRLFはCRLFのまま残り、LFとCRLFが混在するファイルもそのまま保存されます。BOMと最終改行も原本に従います。リリースごとに往復保存テストを行い、この動作を確認しています。

ファイルの変更はユーザーの操作からのみ始まります

moteが文書にバイトを追加する場合は三つあります。

ユーザーが文章を入力または貼り付けたとき、クリップボードの画像を確認してから保存し、リンクを挿入したとき、画像の隅をドラッグしてサイズを変え、その値を代替テキストに記録したときです。

すべてユーザー自身が始めた編集です。何が変わったのかも変更履歴で確認できます。

文書の隣に別のファイルを作ることもありません。表の列幅のようにマークダウンに含められない情報は別途保存せず、その機能自体を提供しません。

設定や最近使ったファイル、20個のバックアップといったアプリ情報は、ユーザーのホームにある状態フォルダーにのみ保存します。そのため、文書フォルダーはGitやDropbox、Syncthing上で、moteが存在しないかのように動作します。

その代わり、ファイルを自動で直してはくれません

ファイルをそのまま守るということは、誤った構文も勝手に直さないという意味です。

崩れた表や閉じられていないコードフェンス、ずれたリストのインデントは、CommonMarkが解釈した姿のまま表示されます。望む形と異なる場合は、ソースモード（Source）で自分で直す必要があります。

保存時に何が変わるか分からないエディターは、ファイルを借りて使います。moteは、私が渡したファイルをそのまま返します。