@@ -143,7 +143,7 @@ Looking first at the ``TodolistDirective`` directive:
143
143
.. literalinclude :: examples/todo.py
144
144
:language: python
145
145
:linenos:
146
- :lines: 24-27
146
+ :pyobject: TodolistDirective
147
147
148
148
It's very simple, creating and returning an instance of our ``todolist `` node
149
149
class. The ``TodolistDirective `` directive itself has neither content nor
@@ -153,7 +153,7 @@ directive:
153
153
.. literalinclude :: examples/todo.py
154
154
:language: python
155
155
:linenos:
156
- :lines: 30-53
156
+ :pyobject: TodoDirective
157
157
158
158
Several important things are covered here. First, as you can see, we're now
159
159
subclassing the :class: `~sphinx.util.docutils.SphinxDirective ` helper class
@@ -168,16 +168,16 @@ new unique integer on each call and therefore leads to unique target names. The
168
168
target node is instantiated without any text (the first two arguments).
169
169
170
170
On creating admonition node, the content body of the directive are parsed using
171
- ``self.state.nested_parse ``. The first argument gives the content body, and
172
- the second one gives content offset. The third argument gives the parent node
173
- of parsed result, in our case the `` todo `` node. Following this, the `` todo ``
174
- node is added to the environment. This is needed to be able to create a list of
175
- all todo entries throughout the documentation, in the place where the author
176
- puts a `` todolist `` directive. For this case, the environment attribute
177
- `` todo_all_todos `` is used (again, the name should be unique , so it is prefixed
178
- by the extension name). It does not exist when a new environment is created, so
179
- the directive must check and create it if necessary. Various information about
180
- the todo entry's location are stored along with a copy of the node.
171
+ ``self.parse_content_to_nodes() ``.
172
+ Following this, the `` todo `` node is added to the environment.
173
+ This is needed to be able to create a list of all todo entries throughout
174
+ the documentation, in the place where the author puts a `` todolist `` directive.
175
+ For this case, the environment attribute `` todo_all_todos `` is used
176
+ (again, the name should be unique, so it is prefixed by the extension name).
177
+ It does not exist when a new environment is created , so the directive must
178
+ check and create it if necessary.
179
+ Various information about the todo entry's location are stored along with
180
+ a copy of the node.
181
181
182
182
In the last line, the nodes that should be put into the doctree are returned:
183
183
the target node and the admonition node.
@@ -211,7 +211,7 @@ the :event:`env-purge-doc` event:
211
211
.. literalinclude :: examples/todo.py
212
212
:language: python
213
213
:linenos:
214
- :lines: 56-61
214
+ :pyobject: purge_todos
215
215
216
216
Since we store information from source files in the environment, which is
217
217
persistent, it may become out of date when the source file changes. Therefore,
@@ -229,20 +229,21 @@ to be merged:
229
229
.. literalinclude :: examples/todo.py
230
230
:language: python
231
231
:linenos:
232
- :lines: 64-68
232
+ :pyobject: merge_todos
233
233
234
234
235
235
The other handler belongs to the :event: `doctree-resolved ` event:
236
236
237
237
.. literalinclude :: examples/todo.py
238
238
:language: python
239
239
:linenos:
240
- :lines: 71-113
240
+ :pyobject: process_todo_nodes
241
241
242
- The :event: `doctree-resolved ` event is emitted at the end of :ref: `phase 3
243
- (resolving) <build-phases>` and allows custom resolving to be done. The handler
244
- we have written for this event is a bit more involved. If the
245
- ``todo_include_todos `` config value (which we'll describe shortly) is false,
242
+ The :event: `doctree-resolved ` event is emitted for each document that is
243
+ about to be written at the end of :ref: `phase 3 (resolving) <build-phases >`
244
+ and allows custom resolving to be done on that document.
245
+ The handler we have written for this event is a bit more involved.
246
+ If the ``todo_include_todos `` config value (which we'll describe shortly) is false,
246
247
all ``todo `` and ``todolist `` nodes are removed from the documents. If not,
247
248
``todo `` nodes just stay where and how they are. ``todolist `` nodes are
248
249
replaced by a list of todo entries, complete with backlinks to the location
@@ -266,17 +267,17 @@ the other parts of our extension. Let's look at our ``setup`` function:
266
267
.. literalinclude :: examples/todo.py
267
268
:language: python
268
269
:linenos:
269
- :lines: 116-
270
+ :pyobject: setup
270
271
271
272
The calls in this function refer to the classes and functions we added earlier.
272
273
What the individual calls do is the following:
273
274
274
275
* :meth: `~Sphinx.add_config_value ` lets Sphinx know that it should recognize the
275
- new *config value * ``todo_include_todos ``, whose default value should be
276
- `` False `` (this also tells Sphinx that it is a boolean value).
276
+ new *config value * ``todo_include_todos ``, whose default value is `` False ``
277
+ (which also tells Sphinx that it is a boolean value).
277
278
278
- If the third argument was ``'html' ``, HTML documents would be full rebuild if the
279
- config value changed its value. This is needed for config values that
279
+ If the third argument was ``'html' ``, HTML documents would be fully rebuilt
280
+ if the config value changed its value. This is needed for config values that
280
281
influence reading (build :ref: `phase 1 (reading) <build-phases >`).
281
282
282
283
* :meth: `~Sphinx.add_node ` adds a new *node class * to the build system. It also
0 commit comments