自動保存があると聞くと、直前の一文字まで必ず戻せるように感じます。しかし、自動保存が守るのは「保存タイミングを忘れにくくすること」であって、誤削除、上書き、端末故障、同期事故まで巻き戻せるバックアップではありません。さらに、保存を止める入力条件があるなら、止まったことに気づける運用も必要です。
この記事ではテキストエディタ 文章の保護を三層に分けます。第一層は公開資料にある約1.2秒後の自動保存。第二層はCLIで実測した明示書き込みと再読込。第三層は世代を残すバックアップです。今回、タイマーが発火する瞬間や警告の画面は直接測っていないため、公開仕様と利用者の確認手順として区別します。
自動保存に任せる範囲を最初に狭くする
公開資料では、編集後約1.2秒で自動保存すると説明されています。これは、数行書くたびに保存操作を思い出す負担を減らす仕組みとして役立ちます。一方で、保存された誤編集を一つ前へ戻すことや、ファイルそのものが失われたときの復元を約束する説明ではありません。
そこで作業開始前に「自動保存」「明示確認」「バックアップ」の役割を書きます。自動保存は直近編集の書き込み、明示確認は閉じて開き直した内容の一致、バックアップは過去版への復帰です。三つを同じ「保存」という言葉でまとめないことが、期待外れを防ぎます。
重要な区切りでは、自動保存を待ったつもりで閉じず、保存状態を画面で確認するか、複製ファイルで再読込を試します。公開前や大きな一括編集の前には、別場所または版管理へ世代を残します。
CLIで確認したのは明示書き込み後の耐久性
実測では /private/tmp/rune-g2c3-studio-345-gmp1b4wl/autosave-sample.txt を使いました。更新内容を updated-content.txt に用意し、まずdry-runを行った後、rune file write --path .../autosave-sample.txt --content-file .../updated-content.txt --json で明示的に書き込みました。続けて rune workspace close ... で閉じ、rune file read --path .../autosave-sample.txt --json で読み直しました。
読み戻したファイルはUTF-8、改行LF、三行、16文字で、確認用マーカーを含みました。SHA-256は 60c4d...28a90 と記録されています。これにより、明示writeの完了後に閉じて再読込しても内容が一致したことは確認できます。
ただし、この操作は編集を止めて1.2秒待ったものではありません。file write を明示実行しています。したがって、この証拠から「自動保存タイマーが動いた」「画面の警告が出た」とは言えません。タイトルの自動保存は公開仕様として扱い、CLI記録は保存内容を別経路で検算する例として扱います。
タイマーは利用者が複製ファイルで確かめる
実画面の確認では、失ってもよい複製ファイルを使います。時刻と短いマーカーを書き、キー入力を止めて1.2秒より十分長く待ちます。保存状態の表示を記録してRuneを閉じ、同じファイルを開き直し、マーカーと改行が残るか確認します。可能ならOS、Rune版、待ち時間、ファイル形式も記録します。
次に、待たずに閉じる試験を同じ内容で行ってはいけません。閉じる操作そのものが保存や確認を誘発する可能性があり、タイマーだけを切り分けられないからです。目的は危険な最短時間を探すことではなく、普段の作業で十分な停止時間と確認点を決めることです。
この節は利用者向けの確認手順です。今回の検証環境ではタイマーの発火時刻も画面表示も観測していません。したがって、約1.2秒は公開資料の値として引用し、どの環境でも厳密に同じ時刻で完了すると断定しません。
保存停止の警告を見逃さない手順を作る
公開資料には、現在の文字コードで表現できない文字が残る間は自動保存を一時停止し、赤い背景や画面右上の通知で警告するとあります。この挙動も今回は画面実測していません。試す場合は本番原稿を使わず、文字コードを確認できる複製を用意します。
確認手順は、複製へ表現できない可能性のある文字を入力し、警告と保存状態を記録し、その文字を削除または表現可能な文字へ置き換え、通常状態へ戻るかを見る、です。警告が出ない、または判断できない場合は、保存済みと推測せず、Unicodeを安全に扱える形式へ変換した複製へ内容を退避します。
失敗条件は、警告中なのに保存済みと扱うこと、あるいは原稿を閉じてから未保存に気づくことです。復旧は閉じる前に問題文字を特定し、別形式へ内容を退避し、保存後に再読込して一致を確認することです。画面の色だけで判断せず、通知文と再読込結果も残します。
再読込とハッシュで保存内容を検算する
明示確認の入力は、対象パス、更新内容、文字コード、改行形式です。失敗は、再読込したマーカー、行数、文字数、ハッシュのいずれかが期待と違うこと。復旧は元ファイルへ追記せず、更新内容を別ファイルへ退避し、エンコーディングと改行を直してdry-runからやり直すことです。
今回の合格値はUTF-8、LF、三行、16文字、指定マーカー、記録したSHAの一致です。この値はfixture固有で、別原稿へそのまま当てはめるものではありません。自分の原稿では自分の期待値を作ります。
再読込は「書き込み命令が成功した」という応答と、「次に開いた内容が同じ」という観測を結びます。自動保存の確認でも、この最後の読み直しを入れると、画面表示だけの安心から一歩進めます。
バックアップを別の時間軸として残す
自動保存が正しく働くほど、誤って消した文章も速く保存されます。そのため、章を削る前、全置換の前、公開前などに復帰点を残します。ファイル名へ日時を付けた複製、版管理、同期サービスの履歴など、現在ファイルと同時に壊れない方法を選びます。
日常の合格条件は、複製試験で自動保存の流れを確認し、警告時の退避手順を知り、重要な区切りで再読込またはハッシュを確認し、過去版へ戻る経路もあることです。自動保存だけを万能にせず、明示確認とバックアップを重ねることで、書く速度を落とさず文章を守れます。