drop FIXMEs and TODOs

5 files changed, 6 insertions, 47 deletions

diff --git a/_conclusion.qmd b/_conclusion.qmd
index a6c4145..cbe8d3e 100644
--- a/_conclusion.qmd
+++ b/_conclusion.qmd
@@ -1,6 +1,3 @@
-*FIXME: introduce subsections
-on observation/reflection/envision discussions an conclusion*
-
 ## Observations from implementation work
 
 Work on implementing `sem-md` uncovered a few observations,
@@ -169,11 +166,6 @@ respectively.
 These extensions to the Pandoc-based workflow have uses in themselves,
 and also enables further explorations into more complex workflows.
 
-### Integration with Hypothesis
-
-*TODO: Introduce previous semester project
-and elaborate on potential benefits of semanticized annotations*
-
 ### Generalizing Quarto metadata {#sec-quarto}
 
 Quarto,
diff --git a/_filter.qmd b/_filter.qmd
index 95d3bbe..37698d9 100644
--- a/_filter.qmd
+++ b/_filter.qmd
@@ -1,5 +1,3 @@
-*TODO: chapter overview*
-
 ## Misparsing and then cleaning up {#sec-misparsing}
 
 Pandoc offers two ways to implement a syntax extension to Markdown:
@@ -25,8 +23,6 @@ to deliberately misparse Semantic Markdown as CommonMark at first,
 and then parse the misparsed content again using the filter API,
 adjusting to the extended syntax.
 
-*TODO: More details...*
-
 ## The choice of Lua
 
 This project is implemented in the scripting language Lua.
@@ -78,8 +74,3 @@ called by Pandoc for each block of the AST.
 The function iterates through each content element of the block,
 keeping track of whether it is free from annotation-related enclosures,
 or are in an enclosure for the content part or the annotation part.
-
-
-
-*TODO: Details of cleaning up KeyWords
-through correlating Pandoc AST with 5 enclosure states*
diff --git a/_intro.qmd b/_intro.qmd
index 2acea79..49dd580 100644
--- a/_intro.qmd
+++ b/_intro.qmd
@@ -55,7 +55,6 @@ Thus,
 * What are the core qualities of Markdown,
   and how can a Markdown dialect express semantic text annotations
   while maintaining those qualities?
-* *TODO: Analysis of spec, phrased as a question*
 * How does Pandoc parse Markdown into a generalised content structure,
   and how can that process be extended
   to handle semantic text annotations?
@@ -63,11 +62,6 @@ Thus,
   is more likely to be sustainable in the long term?
 * How can the reliability of a Pandoc extension be evaluated?
 
-*TODO: Maybe reframe as an investigation of the spec,
-implementing it to identify its strengths and weaknesses*
-
-*FIXME: align above questions with actual findings*
-
 ## Project constraints
 
 Driven by an interest in sustained development of this research project
@@ -190,14 +184,14 @@ under the Creative Commons crediting share-alike 4.0.
 
 ## Implementation plan
 
-*FIXME: sharpen this chapter summary
-to explicitly conclude the previous parts*
+The plan for this project is to...
 
-* extension to existing widespread authoring language,
+* implement an extension to existing widespread authoring language,
   not an alternative one
-* subtle extension, both to ease adoption of existing Markdown users,
+* keep changes to Markdown syntax to a minimum,
+  both to ease adoption of existing Markdown users,
   and to keep the original principle that it "should be publishable as-is".
-* emphasizing ease of user adoption rather than ease of implementation
+* emphasize ease of user adoption rather than ease of implementation
 
 Achieving these goals requires an understanding of Markdown and annotations,
 and it requires working code.
diff --git a/_markdown.qmd b/_markdown.qmd
index 83a9e20..550e14f 100644
--- a/_markdown.qmd
+++ b/_markdown.qmd
@@ -141,10 +141,7 @@ including at points with choices.
 
 ## Syntax of dialect CommonMark {#sec-commonmark}
 
-*TODO: is something missing here? Section start oddly?*
-
-More specifically,
-the example @fig-hello contains two different types of blocks
+The example @fig-hello contains two different types of blocks
 (as well as a set of metadata blocks which will not be covered here),
 first a headline and then a regular paragraph.
 These are defined in the visual syntax as block types `Header` and `Paragraph`
diff --git a/_pandoc.qmd b/_pandoc.qmd
index 8a349fa..af159d2 100644
--- a/_pandoc.qmd
+++ b/_pandoc.qmd
@@ -21,10 +21,6 @@ import from layout-rich document formats reduces such information,
 and export to layout-rich document formats
 use templates to effectively impose a normalized style.
 
-*TODO: dot diagram  
-"import -> AST, { AST, template } -> export"  
-workflow components*
-
 ## APIs to supplant or extend workflow components {#sec-pandoc-apis}
 
 Pandoc is designed with extension in mind,
@@ -45,19 +41,11 @@ either by passing command-line options
 or by declaring options in document-wide metadata in the source file
 (for the source text formats supporting that).
 
-*TODO: dot diagram  
-"**custom** import -> AST, { AST, **custom** template } -> **custom** export"  
-customizable workflow components*
-
 The AST itself is also exposed through a filter API,
 allowing for intervening in the data processing workflow
 after source import and before target export,
 by directly mangling the AST.
 
-*TODO: dot diagram  
-"import -> AST -> **filter**; { **filter**, template } -> export"  
-workflow components with a filter applied*
-
 ## The AST segments content into smallest type {#sec-pandoc-ast}
 
 The Pandoc AST contains objects,
@@ -113,9 +101,6 @@ flowing within the constraints of a block
 (inline elements)
 or itself a block (block elements).
 
-*TODO: below should cover
-how import and filter APIs ideally and possibly interact with the AST*
-
 The Pandoc filter API,
 which exposes the full AST,
 is efficient and intuitive for example to traverse all blocks