テキストエディタ マークダウンを調べているなら、Markdown完全対応という表示で選ばず、必要記法の入力・プレビュー・出力を個別に通すのが最初の答えです。対象はH1〜H3、箇条書き、番号リスト、2列の表を含む技術章です。候補比較は同じ標本を二周し、製品資料で確認済みの機能と、実際に確認する記法を別の欄へ記録します。CommonMark全仕様、GitHub固有拡張、コード実行は扱いません。
直接回答：Markdown完全対応という表示で選ばず、必要記法の入力・プレビュー・出力を個別に通す
「Markdown完全対応」という表示だけで選ばず、必要な記法が入力からプレビュー、出力まで同じ意味で通るかを確認します。見た目が似ているだけの候補は採用せず、記法ごとの結果を残します。
記録欄は必須条件、同じ標本、一周目の結果、二周目の結果、停止条件、採否根拠です。対象外の仕様を合格条件へ混ぜません。
タイトルの「目次づくりをやり直さない」を判定する入力境界も先に固定します。Markdown本文へH1〜H3を入力し、①各見出しが目次に入るか、②H1・H2・H3の親子関係が目次階層に対応するか、③各項目のリンク先が該当見出しの直後か、④目次の順序が本文の入力順と一致するかを照合します。どれか一つでも未確認なら、見出し記法が通ったことだけで目次工程を合格にしません。H4以下や見出し以外の装飾はこの判定に混ぜません。
比較表を作る前に必須条件を固定する
機能数や印象で候補を決めると、必要な記法の欠落を見落とします。必須条件、同じ標本、二周の結果、停止条件、採否根拠を独立欄にし、一つでも未確認なら保留にします。便利な別機能で欠落を相殺しません。
標本はH1〜H3、箇条書き、番号リスト、2列の表を含む技術章に統一します。候補ごとに入力や順番を変えると、慣れや素材の差を製品差として数えてしまいます。二周目では、一周目と二周目を分け、同じ条件から戻れるかも見ます。
一周目に残す五つの記録
次の五項目は、H1〜H3、箇条書き、番号リスト、2列の表を含む技術章を同じ条件で扱うための製品非依存の検査順です。特定製品で確認した操作結果ではなく、どの候補にも適用する受け入れ手順として使います。各項目の終了時に、対象、必須条件に関する確認事実、次の入力を一行ずつ残します。
一周目は入力・プレビュー・出力の差を記録し、二周目は一つだけ条件を変えて再確認します。候補ごとに標本や順番が違ったら、その地点で止め、停止理由を同じ作業票へ書きます。
- 1. 必須条件を先に固定する
- 2. H1〜H3の見出しから目次階層・リンク先・順序を照合し、箇条書き、番号リスト、2列の表を含む技術章を候補ごとに複製する
- 3. Markdown完全対応という表示で選ばず、必要記法の入力・プレビュー・出力を個別に通す
- 4. 一つだけ修正して再実行する
- 5. 二周の差と停止理由を比較する
このテーマだけの受け入れ票
H1〜H3、箇条書き、番号リスト、2列の表を含む技術章では、見た目の印象ではなく必須条件から採否根拠までを順に判定します。対象の名前、開始値、保存先または成果物IDを添えれば、古い結果を今回の結果と取り違えません。
ここで記録するのは「うまくいった気がする」ではなく、必須条件と採否根拠のどこを見て合格または保留にしたかです。未実施の欄は未実施のまま残します。
目次の欄には、見出しの入力行、目次に現れた階層、実際のリンク先、本文での順序を一組にして残します。H1からH2、H2からH3へ下がる関係が入力どおりでも、リンク先が別の見出しなら目次の受け渡しは未確認です。リストや表の結果は別の候補比較欄に置き、目次の照合結果と一つの成功数にまとめません。
- 必須条件（対象：見出し・リスト・表を使う原稿で必要な記法だけが往復できるか比べる）：対象と期待状態を先に書き、『候補ごとに標本や順番が違う』なら未合格として戻し先を示す
- 同じ標本：対象と期待状態を先に書き、『便利な別機能で必須条件の欠落を相殺する』なら未合格として戻し先を示す
- 一周目の結果：対象と期待状態を先に書き、『二周目の結果がなく最終候補を決める』なら未合格として戻し先を示す
- 二周目の結果：対象と期待状態を先に書き、『候補ごとに標本や順番が違う』なら未合格として戻し先を示す
- 停止条件：対象と期待状態を先に書き、『便利な別機能で必須条件の欠落を相殺する』なら未合格として戻し先を示す
- 採否根拠：対象と期待状態を先に書き、『二周目の結果がなく最終候補を決める』なら未合格として戻し先を示す
失敗時に変更するのは一条件だけ
止めるべき状態は、候補ごとに標本や順番が違う、便利な別機能で必須条件の欠落を相殺する、または二周目の結果がないまま候補を決めることです。三つを「使いにくい」と一括りにせず、どの入力、設定、成果物で起きたかを分けます。
H1〜H3、箇条書き、番号リスト、2列の表を含む技術章を修正した後、すべてを最初からやり直す必要はありません。ただし、変更した条件に影響する必須条件・同じ標本・一周目の結果・二周目の結果・停止条件・採否根拠は再確認します。前回の行を消さず、変更日と新しい成果物を追加すると差分が追えます。
- 停止1：候補ごとに標本や順番が違う
- 停止2：便利な別機能で必須条件の欠落を相殺する
- 停止3：二周目の結果がなく最終候補を決める
製品資料から言えること・言えないこと
製品確認済み機能の欄には、見出し、表、画像、リンク、ルビなどの挿入、縦書き・横書きプレビュー、EPUB変換という公開機能資料の範囲だけを置きます。一方、箇条書きと番号リストは資料に明記された製品機能として断定せず、H1〜H3の入力から目次へ渡る階層・リンク先・順序の一致も、この記事の候補比較で実際に確認する項目です。リスト、目次、H1〜H3の標本結果を別欄へ残し、資料上の機能範囲と混ぜません。
向くのは、必要記法を個別に確認し、原稿と設定または資料の受け渡しを減らしたい人です。リストまで含めた採否を決める場合は、製品確認済み機能の欄とは別に、箇条書き・番号リストの標本結果を確認します。CommonMark全仕様、GitHub固有拡張、コード実行や外部サービス側の受理は対象外です。
この検索から持ち帰る判断
テキストエディタ マークダウンで持ち帰る結論は、Markdown完全対応という表示で選ばず、必要記法の入力・プレビュー・出力を個別に通すことです。目次づくりをやり直さないためには、H1〜H3の入力から目次階層・リンク先・順序までを一つの境界として照合し、どれかがずれたら未確認のまま止めます。必須条件と二周の結果を別欄にし、製品確認済み機能と候補として試すリスト・目次連携を分ければ、機能数や印象ではなく記録で採否を判断できます。
まず必要な記法を六行の標本にまとめ、候補ごとの空欄表を作ります。H1〜H3の見出しから目次階層・リンク先・順序を照合する欄と、箇条書き・番号リスト・2列の表を比べる欄を分け、同じ技術章を二周します。候補ごとに標本や順番が違った地点を残してください。Rune Studioを試す場合も、製品資料で確認済みの機能欄と、リストや目次連携を実際に確認する候補欄を分けて記録します。
この記事が答えるのは『見出し・リスト・表を使う原稿で必要な記法だけが往復できるか比べる』までです。近接するSTUDIO-640（外部URLとローカルリンクの使い分け）、STUDIO-650（太字・斜体・取り消し線）、STUDIO-654（H1〜H6の見出し挿入）の中心論点は代替しません。除外範囲は『CommonMark全仕様、GitHub固有拡張、コード実行は扱わない』です。製品候補を確認するときは、Rune Studioの商品ページで現行Mac版の範囲を照合してください。
