Markdownテーブルのソースを読みやすく保つには、セルにスペースを加え、長めの編集をした後に各列を再整列します。MacでObsidianを使う場合は、標準のテーブルエディターで編集してから、ソースモードを確認します。ソースのスペース調整と、表示されたテキストの配置は別々に確認する必要があります。

このワークフローは、読書リスト、文房具の在庫表、プロジェクトのチェックリストなど、デスクトップのメモにある小さなMarkdownテーブルを管理する人向けです。目的は、項目が変わっても実際のテキストを見やすく保ち、想定したレンダラーで正しく機能するテーブルを維持することです。

Markdownテーブルのソースを読みやすくするには？

読みやすいソーステーブルには、識別しやすい列の境界、一貫したスペース、1行に1つの完全な行があります。等幅フォントで表示すると、パイプが縦に揃います。GitHubのドキュメントでは、セル幅を揃えたり、ソース内の列を完全に整列したりする必要はないと明記されています。そのため、この整列は有効なテーブルに必須の条件ではなく、編集をしやすくする工夫です。表を使った情報の整理。

たとえば、次の架空のテーブルは簡潔ですが、長い項目名を入力するとスキャンしにくくなります。

| Item | Finish | Count |
| --- | --- | ---: |
| Pencil | Matte | 4 |
| Large sketchbook | Linen | 12 |

スペースを加えると、同じ内容をプレーンテキストとして確認しやすくなります。

| Item             | Finish | Count |
| ---------------- | ------ | ----: |
| Pencil           | Matte  |     4 |
| Large sketchbook | Linen  |    12 |

GFMでは、パイプの境界とセルの内容の間にあるスペースはトリミングされます。したがって、余白を加えても、表示上の列幅は決まりません。----:のコロンは表示される列の右揃えを指定します。一方、4の前のスペースは、このソース例をスキャンしやすくするだけです。GitHub Flavored Markdown仕様、テーブル。

この2つは別々に決めます。ソースを読みやすくするために余白を選び、表示テキストの配置には区切り行のコロンを選びます。エディターでパイプが揃っていないことだけが問題なら、コロンを変えても解決しません。

このテーブルを読むのはどのレンダラーですか？

パイプテーブルは拡張機能であり、CommonMarkのコア機能ではありません。現行のCommonMark仕様はバージョン0.31.2で、GitHubが公開しているGFM仕様では、テーブルをCommonMarkの拡張として明示的に定義しています。CommonMark互換とだけ記載されたレンダラーが、パイプテーブルに対応しているとは限りません。テーブル拡張にも対応しているか確認してください。CommonMark仕様、GitHub Flavored Markdown仕様。

メモを別のアプリケーションに移すときは、次の違いが重要です。

移行先 ドキュメントに記載された動作 実用上の選択
CommonMarkコア コア仕様にパイプテーブルの構文はない テーブル拡張が利用できるか確認する
GitHub テーブルガイドでは、区切りセルごとに3つ以上のハイフンが必要 ---以上を使う
Obsidian テーブルガイドでは、ハイフンは最低2つでよく、ソースセルの整列も不要 GitHubも対象にする場合は3つ以上を使う

上記のハイフン要件は、それぞれの製品ガイドに基づいています。両方の移行先で使う簡便な共通ルールとして、3つ以上を使えます。ただし、これによってすべてのMarkdownレンダラーが同等になるわけではありません。GitHubのテーブルに関するドキュメント、Obsidianの高度な書式構文。

ObsidianとGitHubの両方で使うテーブルには、先頭と末尾にパイプを置き、通常のスペースで余白を加え、テーブルの前後に空行を入れます。GitHubのガイドではテーブルの前に空行を置くよう定めており、GFM仕様では空行によってテーブルが終了すると説明しています。両端を明示しておくと、ソースからテーブルを見つけやすくなります。GitHubのテーブルに関するドキュメント、GFMのテーブル境界。

Mac版Obsidianでテーブルを管理する方法

Obsidianでは、セルを手軽に編集してから、読みやすいMarkdownに整えることができます。デスクトップ版1.5.8のリリースノートでは、入力中のテーブル自動整形が導入され、ソースモードで列が見やすくなると明記されています。これはMarkdown構文の機能ではなく、エディターの動作として文書化されたものです。Obsidian 1.5.8デスクトップ版リリースノート。

通常のメモでは、次の手順を使います。

  1. メモをLive Previewで開きます。必要なら、エディターのステータスアイコンからこのモードを選びます。
  2. Insert Tableコマンドを使うか、右クリックしてInsert → Tableを選び、テーブルを挿入します。
  3. テーブルエディターでセルの内容を入力または修正します。行や列の追加、削除、移動、並べ替えには、テーブルを右クリックします。
  4. ステータスアイコンからSource modeを選び、生成されたMarkdownを確認します。
  5. Reading viewに切り替えて、表示されるテーブルを確認します。

モードの切り替え方法は表示と編集モード、テーブルの挿入とコンテキストメニューの操作は高度な書式構文に記載されています。

モードを頻繁に切り替える場合は、Toggle Live Preview/Source modeにホットキーを割り当てます。macOSでは、Cmd+Eで閲覧ビューと編集ビューを切り替えられます。2つの編集モードを切り替える場合は、専用のモード切り替えコマンドを使ってください。Obsidianの表示と編集モード。

Source modeで直接入力してスペースが不揃いになったら、標準のテーブルエディターに戻って編集し、後でソースを確認します。引用したドキュメントではテーブルの自動整形と正確なソース確認が説明されていますが、任意のソース編集後に必ず余白が再調整されるとは示されていません。小さなテーブルの整列が崩れたままなら、以下の手動方法で直接調整できます。

長めの編集の後にソースの列を再整列する方法

シンプルなルールを使います。ソースの各列を、その見出しも含め、現在の最長項目が収まる幅にします。同じ列のほかのセルに余白を加えます。項目が既存のスペースより長くなったら、幅を計算し直します。

以下はプレーンなASCIIテキストだけを使った例です。まず、次のテーブルを用意します。

| Item   | Finish | Count |
| ------ | ------ | ----: |
| Pencil | Matte  |     4 |
| Folder | Linen  |    12 |

次に、FolderをLarge sketchbookに置き換えます。新しい項目は16文字なので、最初の列には16文字分の領域が必要です。各境界パイプのすぐ内側にスペースを1つ残し、その後ろに領域を埋める分のスペースを加えます。

  • Itemは4文字なので、その後に余白スペースを12個加え、さらに境界用のスペースを1つ置きます。
  • Pencilは6文字なので、その後に余白スペースを10個加え、さらに境界用のスペースを1つ置きます。
  • Large sketchbookは16文字分の領域を満たすため、その後に必要なのは境界用のスペースだけです。
  • 見た目のガイドとして、最初の区切りセルのハイフンを16個に増やします。

これが先ほどの、余白を加えたテーブルです。幅を広げる必要があったのは最初の列だけです。他の列のスペースと配置マーカーはそのままです。

これは、ここで示したASCIIの例に対する手動の書式設定方法であり、あらゆる文字幅に対応する一般的なアルゴリズムではありません。日常的な編集では、等幅フォントのソース表示で結果を確認してください。セルにインライン書式が多く含まれる場合は、バッククォートやアスタリスクなどの句読点も含め、実際に記述された文字に基づいてソース上の幅を判断します。

編集をまとめて行った後に一度テーブルを整列し、キーを打つたびに各行を調整するのは避けます。項目が頻繁に段落ほど長くなるなら、テーブルには短いラベルだけを残し、説明をその下の通常の文章に移すことを検討してください。これにより、元の情報を短くすることなく、余白の調整を減らせます。

テーブルが崩れたときに確認すること

スペースを調整する前に、まず構造を確認します。GFMでは、ヘッダー行と区切り行のセル数を一致させる必要があります。本文行のセルが足りない場合は空のセルが補われ、多すぎる場合は余分なセルが無視されます。そのため、表示結果では内容が欠落していても、テーブルが正しく見えることがあります。GFMのテーブル解析ルール。

大幅な編集後は、次の順序で確認します。

  1. ヘッダー行と区切り行を比較します。 各見出しに対応する区切りセルを用意します。
  2. 本文の各行を確認します。 値が空でも、意図したセル数を保ちます。
  3. 内容に含まれるパイプを確認します。 エスケープされていないパイプは、別の境界として解釈されることがあります。
  4. 行の境界を確認します。 テーブルの各行をソース上の1行に収め、テーブル内に空行を入れないようにします。
  5. 移行先でプレビューします。 テーブルの見た目だけでなく、表示される値も確認します。

リテラルのパイプについて、GitHubではその文字の前にバックスラッシュを置く方法を案内しています。次の完全な例では、Blue | Greenを1つのセルに保持しています。

| Item   | Options       |
| ------ | ------------- |
| Folder | Blue \| Green |

このエスケープは構造に関わるものです。エスケープされていないパイプの前後にスペースを追加しても解決しません。GitHubのリテラルパイプの例。

Obsidianでは、テーブル内の内部リンクの別名に使うパイプもエスケープするよう案内しています。これはObsidian固有の構文上の考慮点です。したがって、別名をエスケープしても、GitHubで同等のリンク動作になるとは限りません。Obsidianのテーブル書式ガイド。

ソースを狭く見せるために、長いセルの途中でEnterを押さないでください。GFMのテーブルではインラインコンテンツを使えますが、ブロック要素は使えません。また、ソース上でセルを複数行にする一般的な形式もありません。1行に収めるのが現実的でなくなったら、長い説明をテーブルの外に移してください。GFMのテーブル内容ルール。

メンテナンスの手順は簡潔に保ちます。内容の変更を終え、セルの境界を確認し、影響を受けた列の余白を調整して、表示されたテーブルを見直します。Obsidianでは、標準のテーブルエディターで編集してからSource modeを確認するのが実用的な出発点です。プレーンテキストに特定の配置を求めるときは、手動で余白を調整する方法も役立ちます。

参照資料