Org-Mode Include Patterns for Long Research Pages
Table of Contents
1. Problem
Research pages grow. A single index.org with case studies, diagrams, and data tables hits 500+ lines. Editing becomes slow, the narrative is hard to navigate, and adding a new case study means touching the entire file.
2. Solution: #+INCLUDE with subdirectory
Split case studies (or any large section) into separate .org files
under an includes/ subdirectory. The parent index.org uses
#+INCLUDE to pull them in at publish time.
research/my-topic/
index.org # 80 lines — thesis, #+INCLUDEs, resources
includes/
case-001-first.org # 45 lines
case-002-second.org # 175 lines
case-003-third.org # (add later — one file, one #+INCLUDE line)
diagram-foo.png
diagram-bar.png
data/
measurements.csv
In index.org:
* Case Study: First #+INCLUDE: "includes/case-001-first.org" * Case Study: Second #+INCLUDE: "includes/case-002-second.org"
3. Image Path Resolution
The critical gotcha: #+INCLUDE changes the base directory for
[[file:...]] references. An included file's [[file:diagram.png]]
resolves relative to the include file's location, not the parent.
3.1. Rule
Images live in the parent directory (next to index.org). Include
files reference them with ../:
;; In includes/case-001-first.org: [[file:../diagram-foo.png]] ← resolves to parent dir [[file:../data/measurements.csv]] ← resolves to parent/data/
3.2. Why this works for both editing and publishing
- Editing the include file directly: Emacs resolves
../fromincludes/, which points to the parent directory. Inline image display (C-c C-x C-v) works. - Publishing via #+INCLUDE: org-publish expands the include into
index.org's context. The../in the HTML output resolves from the includes subdirectory on the server, pointing back to the parent where the images are deployed. - Editing index.org: The includes are opaque until expanded. Use
C-c 'on the #+INCLUDE line to open the included file.
4. Heading Levels
#+INCLUDE preserves heading levels from the included file. If your
include starts with ** subheadings (because the * heading is in
the parent), the structure is correct. If it starts with *, it
becomes a peer of the parent's heading.
Pattern: the parent has the * heading, the include file starts with
content or ** subheadings.
;; In index.org: * Case Study: Storm ← * heading in parent #+INCLUDE: "includes/case-002-storm.org" ;; In includes/case-002-storm.org: On May 19, 2026... ← body text, no * heading ** The Signal ← ** subheading (correct level) ** Holding Patterns ← ** subheading
5. Cross-references Between Includes
An include file can reference another include's content if the anchors are in the published output. But for editing, treat each include as self-contained. Cross-references should go through the parent file or use absolute URLs.
6. When to Split
Split when:
- A section exceeds ~100 lines
- The section is a self-contained case study or analysis
- You expect to add more sections of the same type later
- Multiple people (or agents) edit different sections concurrently
Don't split:
- Sections under 50 lines
- Tightly coupled content that references adjacent sections by line
- Tables of contents (the parent owns the ToC)
7. Naming Convention
includes/case-NNN-slug.org for numbered case studies. The number
controls ordering; the slug is human-readable. Examples:
case-001-baw48.orgcase-002-storm.orgcase-003-winter-storm.orgsection-architecture.orgsection-methodology.org