Org Syntax

DRAFT v2_β

1. Introduction

Org is a plaintext format composed of simple, yet versatile, forms which represent formatting and structural information. It is designed to be both intuitive to use, and capable of representing complex documents. Like Markdown (RFC7763), Org may be considered a lightweight markup language. However, while Markdown refers to a collection of similar syntaxes, Org is a single syntax.

Should markdown be mentioned at all?

This document describes and comments on Org syntax as it is currently read by its parser (org-element.el) and, therefore, by the export framework.

2. Terminology and conventions

2.1. Objects and Elements

The components of this syntax can be divided into two classes: “objects” and “elements”. To better understand these classes, consider the paragraph as a unit of measurement. Elements are syntactic components that exist at the same or greater scope than a paragraph, i.e. which could not be contained by a paragraph. Conversely, objects are syntactic components that exist with a smaller scope than a paragraph, and so can be contained within a paragraph.

Elements can be stratified into “headings”, “sections”, “greater elements”, and “lesser elements”, from broadest scope to narrowest. Along with objects, these sub-classes define categories of syntactic environments. Only headings, sections, property drawers, and planning lines are context-free¹^,², every other syntactic component only exists within specific environments. This is a core concept of the syntax.

Expanding on the stratification of elements, lesser elements are elements that cannot contain any other elements. As such, a paragraph is considered a lesser element. Greater elements can themselves contain greater elements or lesser elements. Sections contain both greater and lesser elements, and headings can contain a section and other headings.

2.2. The minimal and standard sets of objects

To simplify references to common collections of objects, we define two useful sets. The minimal set of objects refers to plain text, text markup, entities, LaTeX fragments, superscripts and subscripts. The standard set of objects refers to the entire set of objects, excluding citation references and table cells.

2.3. Blank lines

A line containing only spaces, tabs, newlines, and line feeds (\t\n\r) is considered a blank line. Blank lines can be used to separate paragraphs and other elements.

With the exception of list items, blank lines belong to the preceding element with the narrowest possible scope. For example, if at the end of a section we have a paragraph and a blank line, that blank line is considered part of the paragraph.

2.4. Indentation

Indentation consists of a series of space and tab characters at the beginning of a line. Most elements can be indentated, with the exception of headings, inlinetasks, footnote definitions, and diary sexps. Indentation is only syntactically meaningful in plain lists.

2.5. Syntax patterns

2.5.1. General form

Most elements and objects will be described with the help of syntax patterns, consisting of a series of named tokens written in uppercase and separated by a space, like so:

TOKEN1 TOKEN2

These tokens are often named roughly according to their semantic meaning, For instance, “KEY” and “VALUE” when describing Keywords. Tokens will be specified as either a string, or a series of elements or objects.

Unless otherwise specified, a space in a pattern represents one or more horizontal whitespace characters.

Patterns will often also contain static structures that serve to differentiate a particular element or object type from others, but have no semantic meaning. These are simply included in the pattern verbatim. For instance, if a pattern consists of two plus signs (+) immediately followed by a TOKEN it would be written like so:

++TOKEN

Since tokens are written in uppercase, any letters in static structures are distinguished by being written in lowercase.

2.5.2. Special tokens

In a few cases, an instance of an element or object must be preceded or succeeded by a certain pattern, which is not itself part of the element or object. There patterns are specified using the PRE and POST tokens respectively, like so:

PRE TOKEN POST

2.5.3. Case significance

In this document, unless specified otherwise, case is insignificant.

3. Elements

3.1. Headings and Sections

3.1.1. Headings

A Heading is an unindented line structured according to the following pattern:

STARS KEYWORD PRIORITY TITLE TAGS

STARS: A string consisting of one or more asterisks (up to org-inlinetask-min-level if the org-inlinetask library is loaded) suffixed by a space character. The number of asterisks is used to define the level of the heading.
KEYWORD (optional): A string which is a member of org-todo-keywords-1³. Case is significant. This is called a “todo keyword”. ⁴
PRIORITY (optional): A single alphanumeric character preceded by a hash sign # and enclosed within square brackets (e.g. [#A] or [#1]). This is called a “priority cookie”.
TITLE (optional): A series of objects from the standard set, excluding line break objects. It is matched after every other part.
TAGS (optional): A series of colon-separated strings consisting of alpha-numeric characters, underscores, at signs, hash signs, and percent signs (_@#%).

Examples

*
** DONE
*** Some e-mail
**** TODO [#A] COMMENT Title :tag:a2%:

If the first word appearing in the title is COMMENT, the heading will be considered as “commented”. Case is significant.

If the TITLE of a heading is exactly the value of org-footnote-section (Footnotes by default), it will be considered as a “footnote section”. Case is significant.

If ARCHIVE is one of the tags given, the heading will be considered as “archived”. Case is significant.

All content following a heading — up to either the next heading, or the end of the document, forms a section contained by the heading. This is optional, as the next heading may occur immediately in which case no section is formed.

3.1.2. Sections

Sections contain one or more non-heading elements. With the exception of the text before the first heading in a document (which is considered a section), sections only occur within headings.

Since sections are usually thought of as a larger group that includes nested content (e.g. “section 3”), and this isn’t what Org sections are, maybe this should be called something slightly different?

Example

Consider the following document:

An introduction.
* A Heading
Some text.
** Sub-Topic 1
** Sub-Topic 2
*** Additional entry

Its internal structure could be summarized as:

(document
 (section)
 (heading
  (section)
  (heading)
  (heading
   (heading))))

3.1.3. The zeroth section

All elements before the first heading in a document lie in a special section called the zeroth section. It may be preceded by blank lines. Unlike a normal section, the zeroth section can immediately contain a property drawer, optionally preceded by comments. It cannot however, contain planning.

3.2. Greater Elements

Unless otherwise specified, greater elements can directly contain any greater or lesser element except:

Elements of their own type.
Planning, which may only occur in a heading.
Property drawers, which may only occur in a heading or the zeroth section.
Node properties, which can only be found in property drawers.
Items, which may only occur in plain lists.
Table rows, which may only occur in tables.

3.2.1. Greater Blocks

Greater blocks are structured according to the following pattern:

#+begin_NAME PARAMETERS
CONTENTS
#+end_NAME

NAME

A string consisting of any non-whitespace characters, which is not the NAME of a lesser block. Greater blocks are treated differently based on their subtype, which is determined by the NAME as follows:

center, a “center block”
quote, a “quote block”
any other value, a “special block”

PARAMETERS (optional)

A string consisting of any characters other than a newline.

CONTENTS

A collection of zero or more elements, subject to two conditions:

No line may start with #+end_NAME.
Lines beginning with an asterisk must be quoted by a comma (,*).

Furthermore, lines starting with #+ may be quoted by a comma (,#+).

3.2.2. Drawers and Property Drawers

Drawers are structured according to the following pattern:

:NAME:
CONTENTS
:end:

NAME: A string consisting of word-constituent characters, hyphens and underscores (-_).
CONTENTS: A collection of zero or more elements, except another drawer.

3.2.3. Dynamic Blocks

Dynamic blocks are structured according to the following pattern:

#+begin: NAME PARAMETERS
CONTENTS
#+end:

NAME: A string consisting of non-whitespace characters.
PARAMETERS (optional): A string consisting of any characters but a newline.
CONTENTS: A collection of zero or more elements, except another dynamic block.

3.2.4. Footnote Definitions

Footnote definitions must occur at the start of an unindented line, and are structured according to the following pattern:

[fn:LABEL] CONTENTS

LABEL: Either a number or an instance of the pattern fn:WORD, where WORD represents a string consisting of word-constituent characters, hyphens and underscores (-_).
CONTENTS (optional): A collection of zero or more elements. It ends at the next footnote definition, the next heading, two consecutive blank lines, or the end of buffer.

Examples

[fn:1] A short footnote.

[fn:2] This is a longer footnote.

It even contains a single blank line.

3.2.5. Inlinetasks

Inlinetasks are syntactically a heading with a level of at least org-inlinetask-min-level⁵, i.e. starting with at least that many asterisks.

Optionally, inlinetasks can be ended with a second heading with a level of at least org-inlinetask-min-level⁵, with no optional components (i.e. only STARS and TITLE provided) and the string END as the TITLE. This allows the inlinetask to contain elements.

Urgh, this syntax is ugly. — Tom G, Timothy

Examples

*************** TODO some tiny task
This is a paragraph, it lies outside the inlinetask above.
*************** TODO some small task
                 DEADLINE: <2009-03-30 Mon>
                 :PROPERTIES:
                   :SOMETHING: or other
                 :END:
                 And here is some extra text
*************** END

Inlinetasks are only recognized after the org-inlinetask library is loaded.

3.2.6. Items

Items are structured according to the following pattern:

BULLET COUNTER-SET CHECK-BOX TAG CONTENTS

BULLET

One of the two forms below, followed by either a whitespace character or line ending.

An asterisk, hyphen, or plus sign character (i.e., *, -, or +).
Either the pattern COUNTER. or COUNTER).

COUNTER
Either a number or a single letter (a-z).

COUNTER-SET (optional)

An instance of the pattern [@COUNTER].

CHECK-BOX (optional)

A single whitespace character, an X character, or a hyphen enclosed by square brackets (i.e. [ ], [X], or [-]).

TAG (optional)

An instance of the pattern TAG-TEXT :: where TAG-TEXT represents a string consisting of non-newline characters that does not contain the substring "\nbsp{}::\nbsp{}" (two colons surrounded by whitespace, without the quotes).

CONTENTS (optional)

A collection of zero or more elements, ending at the first instance of one of the following:

The next item.
The first line less or equally indented than the starting line, not counting lines within other elements or inlinetask boundaries.
Two consecutive blank lines.

Since it is stated that CONTENTS will end at the next item, Examples

- item
3. [@3] set to three
+ [-] tag :: item contents

3.2.7. Plain Lists

A plain list is a set of consecutive items of the same indentation.

At a glance it may appear as though nested lists are not possible. They are, as items may themselves contain lists.

If first item in a plain list has a COUNTER in its BULLET, the plain list will be an “ordered plain-list”. If it contains a TAG, it will be a “descriptive list”. Otherwise, it will be an “unordered list”. List types are mutually exclusive at the same level of indentation, if both types are present consecutively then they parse as separate lists.

For example, consider the following excerpt of an Org document:

1. item 1
2. [X] item 2
   - some tag :: item 2.1

Its internal structure is as follows:

(ordered-plain-list
 (item)
 (item
  (descriptive-plain-list
   (item))))

3.2.8. Property Drawers

Property drawers are a special type of drawer containing properties attached to a heading or inlinetask. They are located right after a heading and its planning information, as shown below:

HEADLINE
PROPERTYDRAWER

HEADLINE
PLANNING
PROPERTYDRAWER

Property Drawers are structured according to the following pattern:

:properties:
CONTENTS
:end:

CONTENTS: A collection of zero or more node properties, not separated by blank lines.

The failure mode for malformed contents needs to be determined more clearly here. We don’t want property draws to suddenly become plain drawers just because a user has a malformed line, that could be disastrous if certain settings in the property drawer mask settings from further up the tree. In short, malformed contents should not poison the whole property drawer. — Tom G

Example

:PROPERTIES:
:CUSTOM_ID: someid
:END:

3.2.9. Tables

Tables are started by a line beginning with either:

A vertical bar (|), forming an “org” type table.
The string +- followed by a sequence of plus (+) and minus (-) signs, forming a “table.el” type table.

Maybe drop table.el from the spec?

Tables cannot be immediately preceded by such lines, as the current line would the be part of the earlier table.

Org tables contain table rows, and end at the first line not starting with a vertical bar. An Org table can be followed by a number of #+TBLFM: FORMULAS lines, where FORMULAS represents a string consisting of any characters but a newline.

Table.el tables end at the first line not starting with either a vertical line or a plus sign.

Example

| Name  | Phone | Age |
|-------+-------+-----|
| Peter |  1234 |  24 |
| Anna  |  4321 |  25 |

3.3. Lesser Elements

Lesser elements cannot contain any other element.

Only keywords which are a member of org-element-parsed-keywords⁶, verse blocks, paragraphs or table rows can contain objects.

3.3.1. Blocks

Like greater blocks, blocks are structured according to the following pattern:

#+begin_NAME DATA
CONTENTS
#+end_NAME

NAME

A string consisting of any non-whitespace characters. The type of the block is determined based on the value as follows:

comment, a “comment block”,
example, an “example block”,
export, an “export block”,
src, a “source block”,
verse, a “verse block”. The NAME must be one of these values. Otherwise, the pattern forms a greater block.

DATA (optional)

A string consisting of any characters but a newline.

In the case of an export block, this is mandatory and must be a single word.
In the case of a source block, this is mandatory and must follow the pattern LANGUAGE SWITCHES ARGUMENTS with:

LANGUAGE
A string consisting of any non-whitespace characters

SWITCHES
Any number of SWITCH patterns, separated by a single space character

SWITCH
Either the pattern -l "FORMAT" where FORMAT represents a string consisting of any characters but a double quote (") or newline, or the pattern -S or +S where S represents a single alphabetic character

ARGUMENTS
A string consisting of any character but a newline.

CONTENTS (optional)

A string consisting of any characters (including newlines) subject to the same two conditions of greater block’s CONTENTS, i.e.

No line may start with #+end_NAME.
Lines beginning with an asterisk must be quoted by a comma (,*).

As with greater blocks, lines starting with #+ may be quoted by a comma (,#+). CONTENTS will contain Org objects when the block is a verse block, it is otherwise not parsed.

Can we drop switch support? This seems like a fairly good idea.
“For the love of all that is sane” — Tom G

Example

#+begin_verse
    There was an old man of the Cape
   Who made himself garments of crepe.
       When asked, “Do they tear?”
      He replied, “Here and there,
 But they’re perfectly splendid for shape!”
#+end_verse

3.3.2. Clock

A clock element is structured according to the following pattern:

clock: INACTIVE-TIMESTAMP
clock: INACTIVE-TIMESTAMP-RANGE DURATION

INACTIVE-TIMESTAMP

An inactive timestamp object.

INACTIVE-TIMESTAMP-RANGE

An inactive range timestamp object.

DURATION

An instance of the pattern => HH:MM.

HH: A number consisting of any number of digits.
MM: A two digit number.

Example

clock: [2024-10-12]

3.3.3. Diary Sexp

A diary sexp⁷ element is an unindented line structured according to the following pattern:

%%SEXP

SEXP: A string starting with an open parenthesis (, with balanced opening and closing parentheses.

Example

%%(org-calendar-holiday)

3.3.4. Planning

A planning element is structured according to the following pattern:

HEADING
PLANNING

HEADING

A heading element.

PLANNING

A line consisting of one or more KEYWORD: TIMESTAMP patterns (termed “info” patterns).

KEYWORD: Either the string DEADLINE, SCHEDULED, or CLOSED.
TIMESTAMP: A timestamp object.

PLANNING must directly follow HEADING without any blank lines in between.

When a keyword is repeated in a planning element, the last instance of it has priority.

Tom G has requested adding a OPENED keyword to track task creation/registration.

Example

*** TODO watch "The Matrix"
    SCHEDULED: <1999-03-31 Wed>

3.3.5. Comments

A “comment line” starts with a hash character (#) and either a whitespace character or the immediate end of the line.

Comments consist of one or more consecutive comment lines.

Example

# Just a comment
#
# Over multiple lines

3.3.6. Fixed Width Areas

A “fixed-width line” starts with a colon character (:) and either a whitespace character or the immediate end of the line.

Fixed-width areas consist of one or more consecutive fixed-width lines.

Example

: This is a
: fixed width area

3.3.7. Horizontal Rules

A horizontal rule is formed by a line consisting of at least five consecutive hyphens (-----).

3.3.8. Keywords

Keywords are structured according to the following pattern:

#+KEY: VALUE

KEY: A string consisting of any non-whitespace characters, other than call (which would forms a babel call element).
VALUE: A string consisting of any characters but a newline.

Perhaps this should be changed to be #+KEY[OPT]: VAL? It would make the syntax more regular, considering affiliated keywords. I can’t see any backwards compatibility concerns.
This was suggested by Tom G, but I’m a fan — Timothy.

When KEY is a member of org-element-parsed-keywords⁶, VALUE can contain the standard set objects, excluding footnote references.

Note that while instances of this pattern are preferentially parsed as affiliated keywords, a keyword with the same KEY as an affiliated keyword may occur so long as it is not immediately preceding a valid element that can be affiliated. For example, an instance of #+caption: hi followed by a blank line will be parsed as a keyword, not an affiliated keyword.

Babel Call
Babel calls are structured according to one of the following patterns:
```
#+call: NAME(ARGUMENTS)
#+call: NAME[HEADER1](ARGUMENTS)
#+call: NAME(ARGUMENTS)[HEADER2]
#+call: NAME[HEADER1](ARGUMENTS)[HEADER2]
```
NAME
A string consisting of any non-newline characters except for square brackets, or parentheses ([]()).

ARGUMENTS (optional)
A string consisting of any non-newline characters. Opening and closing parenthesis must be balanced.

HEADER1 (optional), HEADER2 (optional)
A string consisting of any non-newline characters. Opening and closing square brackets must be balanced.

Should this be distinguished from other keywords at the AST interpretation stage, instead of the base syntax? — Tom G
Affiliated Keywords
With the exception of comments, clocks, headings, inlinetasks, items, node properties, planning, property drawers, sections, and table rows, every other element type can be assigned attributes.

This is done by adding specific keywords, named affiliated keywords, immediately above the element considered (a blank line cannot lie between the affiliated keyword and element). Structurally, affiliated keyword are not considered an element in their own right but a property of the element they apply to.

Affiliated keywords are structured according to one of the following pattern:
```
#+KEY: VALUE
#+KEY[OPTVAL]: VALUE
#+attr_BACKEND: VALUE
```
KEY
A string which is a member of org-element-affiliated-keywords⁸.

BACKEND
A string consisting of alphanumeric characters, hyphens, or underscores (-_).

OPTVAL (optional)
A string consisting of any characters but a newline. Opening and closing square brackets must be balanced. This term is only valid when KEY is a member of org-element-dual-keywords⁹.

VALUE
A string consisting of any characters but a newline, except in the case where KEY is member of org-element-parsed-keywords⁶ in which case VALUE is a series of objects from the standard set, excluding footnote references.

Should this even be described at a syntax level instead of an AST processing level? — Tom G

Repeating an affiliated keyword before an element will usually result in the prior VALUEs being overwritten by the last instance of KEY. The sole exception to this is #+header: keywords, where in the case of multiple :opt val declarations the last declaration on the first line it occurs on has priority.

Maybe this should be first-line-wins for all affiliated keywords? This would be a breaking change though. — Timothy

There are two situations under which the VALUEs will be concatenated:
1. If KEY is a member of org-element-dual-keywords⁹.
2. If the affiliated keyword is an instance of the pattern #+attr_BACKEND: VALUE.
When no element immediately follows an instance of the “affiliated keyword” pattern, the keyword is a normal, non-affiliated keyword.

The following example contains three affiliated keywords:
```
#+name: image-name
#+caption: This is a caption for
#+caption: the image linked below
[[file:some/image.png]]
```

3.3.9. LaTeX Environments

LaTeX environments are structured according to the following pattern:

\begin{NAME}
CONTENTS
\end{NAME}

NAME: A non-empty string consisting of alphanumeric or asterisk characters
CONTENTS (optional): A string which does not contain the substring \end{NAME}.

Examples

\begin{align*}
2x - 5y &= 8 \\
3x + 9y &= -12
\end{align*}

3.3.10. Node Properties

Node properties can only exist in property drawers, and are structured according to one of the following patterns:

:NAME: VALUE
:NAME:
:NAME+: VALUE
:NAME+:

NAME: A non-empty string containing any non-whitespace characters which does not end in a plus characters (+).
VALUE (optional): A string containing any characters but a newline.

3.3.11. Paragraphs

Paragraphs are the default element, which means that any unrecognized context is a paragraph.

Empty lines and other elements end paragraphs.

Paragraphs can contain the standard set of objects.

3.3.12. Table Rows

A table row consists of a vertical bar (|) followed by:

Any number of table cells, forming a “standard” type row.
A hyphen (-), forming a “rule” type row. Any non-newline characters can follow the hyphen and this will still be a “rule” type row

Table rows can only exist in tables.

4. Objects

Objects can only be found in the following elements:

keywords or affiliated keywords VALUEs, when KEY is a member of org-element-parsed-keywords⁶,
heading TITLEs,
inlinetask TITLEs,
item TAGs,
clock INACTIVE-TIMESTAMP and INACTIVE-TIMESTAMP-RANGE, which can only contain inactive timestamps,
planning TIMESTAMPs, which can only be timestamps,
paragraphs,
table cells,
table rows, which can only contain table cell objects,
verse blocks.

Most objects cannot contain objects. Those which can will be specified. Furthermore, while many objects may contain newlines, a blank line often terminates the element that the object is a part of, such as a paragraph.

4.1. Entities

Entities are structured according to the following pattern:

\NAME POST

Where NAME and POST are not separated by a whitespace character.

NAME

A string with a valid association in either org-entities¹⁰ or org-entities-user.

POST

Either:

The end of line.
The string {}.
A non-alphabetic character.

Example

\cent

4.2. LaTeX Fragments

LaTeX fragments are structured according to one of the following patterns:

\NAME BRACKETS
\(CONTENTS\)
\[CONTENTS\]

NAME

A string consisting of alphabetic characters which does not have an association in either org-entities or org-entities-user.

BRACKETS (optional)

An instance of one of the following patterns, not separated from NAME by whitespace.

[CONTENTS1]
{CONTENTS1}

CONTENTS1: A string consisting of any characters but {, }, [, ], or a newline.
CONTENTS2: A string consisting of any characters but {, }, or a newline.

CONTENTS

A string consisting of any characters, so long as it does not contain the substring \) in the case of the second template, or \] in the case of the third template.

Examples

\enlargethispage{2\baselineskip}
\(e^{i \pi}\)

Org also supports TeX-style inline LaTeX fragments, structured according the following pattern:

$$CONTENTS$$
PRE$CHAR$POST
PRE$BORDER1 BODY BORDER2$POST

PRE: Either the beginning of line or a character other than $.
CHAR: A non-whitespace character that is not ., ,, ?, ;, or a double quote (").
POST: Any punctuation character (including parentheses and quotes), a space character, or the end of line.
BORDER1: A non-whitespace character that is not ., ,, ;, or $.
BODY: A string consisting of any characters except $, and which does not span more than three lines.
BORDER2: A non-whitespace character that is not ., ,, or $.

Example

$$1+1=2$$

It would introduce incompatibilities with previous Org versions, but support for $...$ (and for symmetry, $$...$$) constructs ought to be removed.

They are slow to parse, fragile, redundant and imply false positives. — NGZ

Strong support for removing these. — Tom G

I’m strongly in support of dropping $-syntax. — Timothy

4.3. Export Snippets

Export snippets are structured according to the following pattern:

@@BACKEND:VALUE@@

BACKEND: A string consisting of zero or more alphanumeric characters and hyphens.
VALUE (optional): A string containing anything but the string @@.

4.4. Footnote References

Footnote references are structured according to one of the following patterns:

[fn:LABEL]
[fn:LABEL:DEFINITION]
[fn::DEFINITION]

LABEL: A string containing one or more word constituent characters, hyphens and underscores (-_).
DEFINITION (optional): One or more objects from the standard set, so long as opening and closing square brackets are balanced within DEFINITION.

If the reference follows the second pattern, it is called an “inline footnote”. If it follows the third pattern, i.e. if LABEL is omitted, it is called an “anonymous footnote”.

Note that the first pattern may not occur on an unindented line, as it is then a footnote definition.

4.5. Citations

Citations are structured according to the following pattern:

[cite CITESTYLE: GLOBALPREFIX REFERENCES GLOBALSUFFIX]

Where “cite” and CITESTYLE, KEYCITES and GLOBALSUFFIX are not separated by whitespace. KEYCITES, GLOBALPREFIX, and GLOBALSUFFIX must be separated by semicolons. Whitespace after the leading colon or before the closing square bracket is not significant. All other whitespace is significant.

CITESTYLE (optional)

An instance of either the pattern /STYLE or /STYLE/VARIANT

STYLE: A string made of any alphanumeric character, _, or -.
Variant: A string made of any alphanumeric character, _, -, or /.

GLOBALPREFIX (optional)

One or more objects from the standard set, so long as all square brackets are balanced within GLOBALPREFIX, and it does not contain any semicolons (;) or subsequence that matches @KEY.

REFERENCES

One or more citation reference objects, separated by semicolons (;).

GLOBALSUFFIX (optional)

One or more objects from the standard set, so long as all square brackets are balanced within GLOBALSUFFIX, and it does not contain any semicolons (;) or subsequence that matches @KEY.

Examples

[cite:@key]
[cite/t:see;@foo p. 7;@bar pp. 4;by foo]
[cite/a/f:c.f.;the very important @@atkey @ once;the crucial @baz vol. 3]

4.6. Citation references

A reference to an individual resource is given in a citation reference object. Citation references are only found within citations, and are structured according to the following pattern:

KEYPREFIX @KEY KEYSUFFIX

Where KEYPREFIX, @KEY, and KEYSUFFIX are not separated by whitespace.

KEYPREFIX (optional): One or more objects from the minimal set, so long as all square brackets are balanced within KEYPREFIX, and it does not contain any semicolons (;) or subsequence that matches @KEY.
KEY: A string made of any word-constituent character, -, ., :, ?, !, `, ', /, *, @, +, |, (, ), {, }, <, >, &, _, ^, $, #, %, or ~.
KEYSUFFIX (optional): One or more objects from the minimal set, so long as all square brackets are balanced within KEYPREFIX, and it does not contain any semicolons (;).

4.7. Inline Babel Calls

Inline Babel calls are structured according to one of the following patterns:

call_NAME(ARGUMENTS)
call_NAME[HEADER1](ARGUMENTS)
call_NAME(ARGUMENTS)[HEADER2]
call_NAME[HEADER1](ARGUMENTS)[HEADER2]

NAME: A string consisting of any non-whitespace characters except for square brackets or parentheses ([]()).
ARGUMENTS (optional), HEADER1 (optional), HEADER2 (optional): A string consisting of any characters but a newline. Opening and closing square brackets must be balanced.

4.8. Inline Source Blocks

Inline source blocks follow any of the following patterns:

src_LANG{BODY}
src_LANG[HEADERS]{BODY}

LANG: A string consisting of any non-whitespace characters.
HEADERS (optional), BODY (optional): A string consisting of any characters but a newline. Opening and closing square brackets must be balanced.

4.9. Line Breaks

Line breaks must occur at the end of an otherwise non-blank line, and are structured according to the following pattern:

\\SPACE

SPACE: Zero or more tab and space characters.

4.10. Links

While links are a single object, they come in four subtypes: “radio”, “angle”, “plain”, and “regular” links.

4.10.1. Radio Links

Radio-type links are structured according to the following pattern:

PRE RADIO POST

PRE: A non-alphanumeric character.
RADIO: One or more objects matched by some radio target. It can contain the minimal set of objects.
POST: A non-alphanumeric character.

Example

This is some <<<*important* information>>> which we refer to lots.
Make sure you remember the *important* information.

The first instance of *important* information defines a radio target, which is matched by the second instance of *important* information, forming a radio link.

4.10.2. Plain links

Plain-type links are structured according to the following pattern:

PRE PROTOCOL:PATHPLAIN POST

PRE: A non word constituent character.
PROTOCOL: A string which is one of the link type strings in org-link-parameters¹¹.
PATHPLAIN: A string containing any non-whitespace character but (, ), <, or >. It must end with a word-constituent character, or any non-whitespace non-punctuation character followed by /.
POST: A non word constituent character.

Example

Be sure to look at https://orgmode.org.

4.10.3. Angle links

Angle-type essentially provide a method to disambiguate plain links from surrounding text, and are structured according to the following pattern:

<PROTOCOL:PATHANGLE>

PROTOCOL: A string which is one of the link type strings in org-link-parameters¹¹
PATHANGLE: A string containing any character but ], <, > or \n.

The angle brackets allow for a more permissive PATH syntax, without accidentally matching surrounding text.

4.10.4. Regular links

Plain-type links are structured according to one of the following two patterns:

[[PATHREG]]
[[PATHREG][DESCRIPTION]]

PATHREG

An instance of one of the seven following annotated patterns:

FILENAME               ("file" type)
PROTOCOL:PATHINNER     ("PROTOCOL" type)
PROTOCOL://PATHINNER   ("PROTOCOL" type)
id:ID                  ("id" type)
#CUSTOM-ID             ("custom-id" type)
(CODEREF)              ("coderef" type)
FUZZY                  ("fuzzy" type)

FILENAME: A string representing an absolute or relative file path.
PROTOCOL: A string which is one of the link type strings in org-link-parameters¹¹
PATHINNER: A string consisting of any character besides square brackets.
ID: A string consisting of hexadecimal numbers separated by hyphens.
CUSTOM-ID: A string consisting of any character besides square brackets.
CODEREF: A string consisting of any character besides square brackets.
FUZZY: A string consisting of any character besides square brackets.

Square brackets and backslashes can be present in PATHREG so long as they are escaped by a backslash (i.e. \], \\).

DESCRIPTION (optional)

One or more objects enclosed by square brackets. It can contain the minimal set of objects as well as export snippets, inline babel calls, inline source blocks, macros, and statistics cookies. It can also contain another link, but only when it is a plain or angle link. It can contain square brackets, so long as they are balanced.

Examples

[[https://orgmode.org][The Org project homepage]]
[[file:orgmanual.org]]
[[Regular links]]

4.11. Macros

Macros are structured according to one of the following patterns:

{{{NAME}}}
{{{NAME(ARGUMENTS)}}}

NAME: A string starting with a alphabetic character followed by any number of alphanumeric characters, hyphens and underscores (-_).
ARGUMENTS (optional): A string consisting of any characters, so long as it does not contain the substring }}}. Values within ARGUMENTS are separated by commas. Non-separating commas have to be escaped with a backslash character.

Examples

{{{title}}}
{{{one_arg_macro(1)}}}
{{{two_arg_macro(1, 2)}}}
{{{two_arg_macro(1\,a, 2)}}}

4.12. Targets and Radio Targets

Targets are structured according to the following pattern:

<<TARGET>>

TARGET: A string containing any character but <, >, or \n. It cannot start or end with a whitespace character.

Radio targets are structured according to the following pattern:

<<<CONTENTS>>>

CONTENTS: One or more objects from the minimal set, starting and ending with a non-whitespace character, and containing any character but <, >, or \n.

4.13. Statistics Cookies

Statistics cookies are structured according to one of the following patterns:

[PERCENT%]
[NUM1/NUM2]

PERCENT (optional): A number.
NUM1 (optional): A number.
NUM2 (optional): A number.

4.14. Subscript and Superscript

Subscripts are structured according to the following pattern:

CHAR_SCRIPT

Superscripts are structured according to the following pattern:

CHAR^SCRIPT

CHAR

Any non-whitespace character.

SCRIPT

One of the following constructs:

A single asterisk character (*).
An expression enclosed in curly brackets ({, }), which may itself contain balanced curly brackets.
An instance of the pattern:
```
SIGN CHARS FINAL
```
With no whitespace between SIGN, CHARS and FINAL.

SIGN
Either a plus sign character (+), a minus sign character (-), or the empty string.

CHARS
Either the empty string, or a string consisting of any number of alphanumeric characters, commas, backslashes, and dots.

FINAL
An alphanumeric character.

4.15. Table Cells

Table cells are structured according to the following pattern:

CONTENTS SPACES|

CONTENTS: Zero or more objects not containing the vertical bar character (|). It can contain the minimal set of objects, citations, export snippets, footnote references, links, macros, radio targets, targets, and timestamps.
SPACES: A string consisting of zero or more of space characters, used to align the table columns.

The final vertical bar (|) may be omitted in the last cell of a table row.

4.16. Timestamps

Timestamps are structured according to one of the seven following patterns:

<%%(SEXP)>                                                     (diary)
<DATE TIME REPEATER-OR-DELAY>                                  (active)
[DATE TIME REPEATER-OR-DELAY]                                  (inactive)
<DATE TIME REPEATER-OR-DELAY>--<DATE TIME REPEATER-OR-DELAY>   (active range)
<DATE TIME-TIME REPEATER-OR-DELAY>                             (active range)
[DATE TIME REPEATER-OR-DELAY]--[DATE TIME REPEATER-OR-DELAY]   (inactive range)
[DATE TIME-TIME REPEATER-OR-DELAY]                             (inactive range)

SEXP

A string consisting of any characters but > and \n.

DATE

An instance of the pattern:

YYYY-MM-DD DAYNAME

Y, M, D: A digit.
DAYNAME (optional): A string consisting of non-whitespace characters except +, -, ], >, a digit, or \n.

TIME (optional)

An instance of the pattern H:MM where H represents a one to two digit number (and can start with 0), and M represents a single digit.

REPEATER-OR-DELAY (optional)

An instance of the following pattern:

MARK VALUE UNIT

Where MARK, VALUE and UNIT are not separated by whitespace characters.

MARK: Either the string + (cumulative type), ++ (catch-up type), or .+ (restart type) when forming a repeater, and either - (all type) or -- (first type) when forming a warning delay.
VALUE: A number
UNIT: Either the character h (hour), d (day), w (week), m (month), or y (year)

There can be two instances of REPEATER-OR-DELAY in the timestamp: one as a repeater and one as a warning delay.

Tom G has some syntax extensions he’d like to suggest for historical / far-future dates, timezone offsets, and second/sub-second times.

Examples

<1997-11-03 Mon 19:15>
<%%(diary-float t 4 2)>
[2004-08-24 Tue]--[2004-08-26 Thu]
<2012-02-08 Wed 20:00 ++1d>
<2030-10-05 Sat +1m -3d>

4.17. Text Markup

There are six text markup objects, which are all structured according to the following pattern:

PRE MARKER CONTENTS MARKER POST

Where PRE, MARKER, CONTENTS, MARKER and POST are not separated by whitespace characters.

PRE

Either a whitespace character, -, (, {, ', ", or the beginning of a line.

MARKER

A character that determines the object type, as follows:

*, a bold object,
/, an italic object,
_ an underline object,
=, a verbatim object,
~, a code object
+, a strike-through object.

CONTENTS

An instance of the pattern:

BORDER BODY BORDER

Where BORDER and BODY are not separated by whitespace.

BORDER: Any non-whitespace character.
BODY: Either a string (when MARKER represents code or verbatim) or a series of objects from the standard set, not spanning more than three lines.

POST

Either a whitespace character, -, ., ,, ;, :, !, ?, ', ), }, [, ", or the end of a line.

Examples

Org is a /plaintext markup syntax/ developed with *Emacs* in 2003.
The canonical parser is =org-element.el=, which provides a number of
functions starting with ~org-element-~.

4.17.1. Plain Text

Any string that doesn’t match any other object can be considered a plain text object.¹² Within a plain text object, all whitespace is collapsed to a single space. For instance, hello\n there is equivalent to hello there.

5. Appendix

5.1. Summary of changes compared to the current `org-syntax` document

Rename “Headlines” -> “Headings”, since while both forms are currently used in the docs a change to consistently use the latter seems imminent if delayed by (what looks like) an ongoing wait for Bastien’s final say
Describe patterns with consistent phrasing, “Xs are structured according to the following pattern:”
Describe string patterns with consistent phrasing,“a string constituted of” (and other forms) -> “a string consisting of”
Describe components of a pattern using description lists
Use verbatim objects for verbatim text over quotes
Change the way inlinetasks are described
Add CONTENTS component to the Item structure
Some whitespace/capitalisation changes
(Lots of) miscellaneous wording changes for clarity
Fix some minor errors (like referencing a variable which was removed 7y ago, or saying that switches in source block headers should be separated by blank lines)
Change the babel call element syntax description to the more detailed form found in the manual
Change the inline babel call object syntax description to be consistent with the babel call element syntax. This does not precisely match the parser behaviour, but matches a very slight subset. The previous description in some parts matched a superset of the parser behaviour, and in other places a subset.
Change “Greater Elements” / “Elements” to “Greater Elements”/ “Lesser Elements”
Put all Elements under the new level-1 heading “Elements”
Separate list definition into four sub-definitions
Add a “Terminology and conventions” section
Mention plain-text objects (see plain-text) for the sake of consistency (When something can “contain an object” it can contain unformatted text. Without naming plain-text as an object this is a bit funky).
Specify that whitespace in plain text is semantically collapsed/equivalent to a single space. It is worth noting that this is not indicated by org-element’s parsing, which grabs all the whitespace as-is. However, this feels like something which is done for performance reasons, instead of a deliberate choice to make whitespace significant, and there are a few things which reinforce this view
- ox-ascii, the only export backend to a format which doesn’t itself collapse whitespace when interpreted, re-fills paragraphs and collapses whitespace.
- We have a line break object. If \n was significant in plain text this would be unnecessary.
- org-fill-paragraph collapses whitespace
- Lastly, this is well-established sensible behaviour in every other plaintext format that I can think of (HTML, LaTeX, Markdown, reST, etc.).
Added bunch of examples
Probably a few bits and pieces that have slipped my mind.

5.2. Org Entities

Name	Character
Letters
LATIN
`Agrave`	À
`agrave`	à
`Aacute`	Á
`aacute`	á
`Acirc`	Â
`acirc`	â
`Amacr`	Ā
`amacr`	ā
`Atilde`	Ã
`atilde`	ã
`Auml`	Ä
`auml`	ä
`Aring`	Å
`AA`	Å
`aring`	å
`AElig`	Æ
`aelig`	æ
`Ccedil`	Ç
`ccedil`	ç
`Egrave`	È
`egrave`	è
`Eacute`	É
`eacute`	é
`Ecirc`	Ê
`ecirc`	ê
`Euml`	Ë
`euml`	ë
`Igrave`	Ì
`igrave`	ì
`Iacute`	Í
`iacute`	í
`Idot`	&idot;
`inodot`	ı
`Icirc`	Î
`icirc`	î
`Iuml`	Ï
`iuml`	ï
`Ntilde`	Ñ
`ntilde`	ñ
`Ograve`	Ò
`ograve`	ò
`Oacute`	Ó
`oacute`	ó
`Ocirc`	Ô
`ocirc`	ô
`Otilde`	Õ
`otilde`	õ
`Ouml`	Ö
`ouml`	ö
`Oslash`	Ø
`oslash`	ø
`OElig`	Œ
`oelig`	œ
`Scaron`	Š
`scaron`	š
`szlig`	ß
`Ugrave`	Ù
`ugrave`	ù
`Uacute`	Ú
`uacute`	ú
`Ucirc`	Û
`ucirc`	û
`Uuml`	Ü
`uuml`	ü
`Yacute`	Ý
`yacute`	ý
`Yuml`	Ÿ
`yuml`	ÿ
LATIN (SPECIAL FACE)
`fnof`	ƒ
`real`	ℜ
`image`	ℑ
`weierp`	℘
`ell`	ℓ
`imath`	ı
`jmath`	ȷ
GREEK
`Alpha`	Α
`alpha`	α
`Beta`	Β
`beta`	β
`Gamma`	Γ
`gamma`	γ
`Delta`	Δ
`delta`	δ
`Epsilon`	Ε
`epsilon`	ε
`varepsilon`	ε
`Zeta`	Ζ
`zeta`	ζ
`Eta`	Η
`eta`	η
`Theta`	Θ
`theta`	θ
`thetasym`	ϑ
`vartheta`	ϑ
`Iota`	Ι
`iota`	ι
`Kappa`	Κ
`kappa`	κ
`Lambda`	Λ
`lambda`	λ
`Mu`	Μ
`mu`	μ
`nu`	ν
`Nu`	Ν
`Xi`	Ξ
`xi`	ξ
`Omicron`	Ο
`omicron`	ο
`Pi`	Π
`pi`	π
`Rho`	Ρ
`rho`	ρ
`Sigma`	Σ
`sigma`	σ
`sigmaf`	ς
`varsigma`	ς
`Tau`	Τ
`Upsilon`	Υ
`upsih`	ϒ
`upsilon`	υ
`Phi`	Φ
`phi`	φ
`varphi`	ϕ
`Chi`	Χ
`chi`	χ
`acutex`	´x
`Psi`	Ψ
`psi`	ψ
`tau`	τ
`Omega`	Ω
`omega`	ω
`piv`	ϖ
`varpi`	ϖ
`partial`	∂
HEBREW
`alefsym`	ℵ
`aleph`	ℵ
`gimel`	ℷ
`beth`	ℶ
`dalet`	ℸ
ICELANDIC
`ETH`	Ð
`eth`	ð
`THORN`	Þ
`thorn`	þ
Punctuation
DOTS AND MARKS
`dots`	…
`cdots`	⋯
`hellip`	…
`middot`	·
`iexcl`	¡
`iquest`	¿
DASH-LIKE
`shy`
`ndash`	–
`mdash`	—
QUOTATIONS
`quot`	"
`acute`	´
`ldquo`	“
`rdquo`	”
`bdquo`	„
`lsquo`	‘
`rsquo`	’
`sbquo`	‚
`laquo`	«
`raquo`	»
`lsaquo`	‹
`rsaquo`	›
Other
MISC. (OFTEN USED)
`circ`	ˆ
`vert`	\|
`vbar`	\|
`brvbar`	¦
`S`	§
`sect`	§
`amp`	&
`lt`	<
`gt`	>
`tilde`	~
`slash`	/
`plus`	+
`under`	_
`equal`	=
`asciicirc`	^
`dagger`	†
`dag`	†
`Dagger`	‡
`ddag`	‡
WHITESPACE
`nbsp`
`ensp`
`emsp`
`thinsp`
CURRENCY
`curren`	¤
`cent`	¢
`pound`	£
`yen`	¥
`euro`	€
`EUR`	€
`dollar`	$
`USD`	$
PROPERTY MARKS
`copy`	©
`reg`	®
`trade`	™
SCIENCE ET AL.
`minus`	−
`pm`	±
`plusmn`	±
`times`	×
`frasl`	⁄
`colon`	:
`div`	÷
`frac12`	½
`frac14`	¼
`frac34`	¾
`permil`	‰
`sup1`	¹
`sup2`	²
`sup3`	³
`radic`	√
`sum`	∑
`prod`	∏
`micro`	µ
`macr`	¯
`deg`	°
`prime`	′
`Prime`	″
`infin`	∞
`infty`	∞
`prop`	∝
`propto`	∝
`not`	¬
`neg`	¬
`land`	∧
`wedge`	∧
`lor`	∨
`vee`	∨
`cap`	∩
`cup`	∪
`smile`	⌣
`frown`	⌢
`int`	∫
`therefore`	∴
`there4`	∴
`because`	∵
`sim`	∼
`cong`	≅
`simeq`	≅
`asymp`	≈
`approx`	≈
`ne`	≠
`neq`	≠
`equiv`	≡
`triangleq`	≜
`le`	≤
`leq`	≤
`ge`	≥
`geq`	≥
`lessgtr`	≶
`lesseqgtr`	⋚
`ll`	≪
`Ll`	⋘
`lll`	⋘
`gg`	≫
`Gg`	⋙
`ggg`	⋙
`prec`	≺
`preceq`	≼
`preccurlyeq`	≼
`succ`	≻
`succeq`	≽
`succcurlyeq`	≽
`sub`	⊂
`subset`	⊂
`sup`	⊃
`supset`	⊃
`nsub`	⊄
`sube`	⊆
`nsup`	⊅
`supe`	⊇
`setminus`	∖
`forall`	∀
`exist`	∃
`exists`	∃
`nexist`	∃
`nexists`	∃
`empty`	∅
`emptyset`	∅
`isin`	∈
`in`	∈
`notin`	∉
`ni`	∋
`nabla`	∇
`ang`	∠
`angle`	∠
`perp`	⊥
`parallel`	∥
`sdot`	⋅
`cdot`	⋅
`lceil`	⌈
`rceil`	⌉
`lfloor`	⌊
`rfloor`	⌋
`lang`	⟨
`rang`	⟩
`langle`	⟨
`rangle`	⟩
`hbar`	ℏ
`mho`	℧
ARROWS
`larr`	←
`leftarrow`	←
`gets`	←
`lArr`	⇐
`Leftarrow`	⇐
`uarr`	↑
`uparrow`	↑
`uArr`	⇑
`Uparrow`	⇑
`rarr`	→
`to`	→
`rightarrow`	→
`rArr`	⇒
`Rightarrow`	⇒
`darr`	↓
`downarrow`	↓
`dArr`	⇓
`Downarrow`	⇓
`harr`	↔
`leftrightarrow`	↔
`hArr`	⇔
`Leftrightarrow`	⇔
`crarr`	↵
`hookleftarrow`	↵
FUNCTION NAMES
`arccos`	arccos
`arcsin`	arcsin
`arctan`	arctan
`arg`	arg
`cos`	cos
`cosh`	cosh
`cot`	cot
`coth`	coth
`csc`	csc
`deg`	°
`det`	det
`dim`	dim
`exp`	exp
`gcd`	gcd
`hom`	hom
`inf`	inf
`ker`	ker
`lg`	lg
`lim`	lim
`liminf`	liminf
`limsup`	limsup
`ln`	ln
`log`	log
`max`	max
`min`	min
`Pr`	Pr
`sec`	sec
`sin`	sin
`sinh`	sinh
`sup`	⊃
`tan`	tan
`tanh`	tanh
SIGNS & SYMBOLS
`bull`	•
`bullet`	•
`star`	*
`lowast`	∗
`ast`	∗
`odot`	o
`oplus`	⊕
`otimes`	⊗
`check`	✓
`checkmark`	✓
MISCELLANEOUS (SELDOM USED)
`para`	¶
`ordf`	ª
`ordm`	º
`cedil`	¸
`oline`	‾
`uml`	¨
`zwnj`	‌
`zwj`	‍
`lrm`	‎
`rlm`	‏
SMILIES
`smiley`	☺
`blacksmile`	☻
`sad`	☹
`frowny`	☹
SUITS
`clubs`	♣
`clubsuit`	♣
`spades`	♠
`spadesuit`	♠
`hearts`	♥
`heartsuit`	♥
`diams`	♦
`diamondsuit`	♦
`diamond`	⋄
`Diamond`	⋄
`loz`	◊
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}
=_ =	{}

Footnotes:

In particular, the parser requires stars at column 0 to be quoted by a comma when they do not define a heading.

It also means that only headings and sections can be recognized just by looking at the beginning of the line. Planning lines and property drawers can be recognized by looking at one or two lines above.

As a consequence, using org-element-at-point or org-element-context will move up to the parent heading, and parse top-down from there until context around the original location is found.

By default, org-todo-keywords-1 only contains TODO and DONE, however org-todo-keywords-1 is set on a per-document basis.

⁴

Implementation note: todo keywords cannot be hardcoded in a tokenizer, the tokenizer must be configurable at runtime so that in-file todo keywords are properly interpreted.

⁵

The default value of org-inlinetask-min-level is 15.

⁶

By default, org-element-parsed-keywords contains CAPTION.

⁷

A common abbreviation for S-expression

⁸

By default, org-element-affiliated-keywords contains CAPTION, DATA, HEADER, NAME, PLOT, and RESULTS.

⁹

By default, org-element-dual-keywords contains CAPTION and RESULTS.

¹⁰

See the appendix for a list of entities.

¹¹

By default, org-link-parameters defines links of type shell, news, mailto, https, http, ftp, help, file, and elisp.

¹²

In org-element.el plain text objects are abstracted away to strings for performance reasons.

1. Introduction

2. Terminology and conventions

2.1. Objects and Elements

2.2. The minimal and standard sets of objects

2.3. Blank lines

2.4. Indentation

2.5. Syntax patterns

2.5.1. General form

2.5.2. Special tokens

2.5.3. Case significance

3. Elements

3.1. Headings and Sections

3.1.1. Headings

3.1.2. Sections

3.1.3. The zeroth section

3.2. Greater Elements

3.2.1. Greater Blocks

3.2.2. Drawers and Property Drawers

3.2.3. Dynamic Blocks

3.2.4. Footnote Definitions

3.2.5. Inlinetasks

3.2.6. Items

3.2.7. Plain Lists

3.2.8. Property Drawers

3.2.9. Tables

3.3. Lesser Elements

3.3.1. Blocks

3.3.2. Clock

3.3.3. Diary Sexp

3.3.4. Planning

3.3.5. Comments

3.3.6. Fixed Width Areas

3.3.7. Horizontal Rules

3.3.8. Keywords

3.3.9. LaTeX Environments

3.3.10. Node Properties

3.3.11. Paragraphs

3.3.12. Table Rows

4. Objects

4.1. Entities

4.2. LaTeX Fragments

4.3. Export Snippets

4.4. Footnote References

4.5. Citations

4.6. Citation references

4.7. Inline Babel Calls

4.8. Inline Source Blocks

4.9. Line Breaks

4.10. Links

4.10.1. Radio Links

4.10.2. Plain links

4.10.3. Angle links

4.10.4. Regular links

4.11. Macros

4.12. Targets and Radio Targets

4.13. Statistics Cookies

4.14. Subscript and Superscript

4.15. Table Cells

4.16. Timestamps

4.17. Text Markup

4.17.1. Plain Text

5. Appendix

5.1. Summary of changes compared to the current org-syntax document

5.2. Org Entities

Footnotes:

5.1. Summary of changes compared to the current `org-syntax` document