aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--app/Main.hs49
1 files changed, 49 insertions, 0 deletions
diff --git a/app/Main.hs b/app/Main.hs
index 66188d1..41b65b6 100644
--- a/app/Main.hs
+++ b/app/Main.hs
@@ -1,3 +1,52 @@
+-- TODO Separate database issues and history issues
+--
+-- History code re-uses the issue concept which leads to undesirable effects.
+--
+-- (1) History issues don't hold up to the guarantee that provenance is
+-- computed over the history, because we compute issues with trivial provenance
+-- per commit, and then later merge those trivial provenance in an
+-- history-encompassing provenance.
+--
+-- (2) Internal tags depend on provenance, and thus, have to re-computed after
+-- the final provenance has been generated.
+--
+-- (3) We need to compare issues in history code, and several fields of issue
+-- prevent us from doing that cleanly.
+--
+-- To remedy, history should introduce its own notion (data type) of issue,
+-- and operate on that.
+--
+-- @supersedes fix-issue-comparison
+-- @supersedes refactor-non-issues
+--
+-- @difficulty medium
+-- @priority high
+
+-- TODO Parse issues as markdown
+--
+-- There are several issues related to the fact that we are not parsing
+-- issues as markdown.
+--
+-- (1) We cannot easily page `show` output, as we are mixing direct output
+-- with shell commands highlighting markdown.
+--
+-- (2) We cannot easily ignore markup (tags) in code blocks.
+--
+-- (3) We cannot easily determine the first and last markdown content when
+-- augmenting the issue body with meta information.
+--
+-- I am neither for nor against replacing `mdcat` with our own markdown
+-- rendering.
+--
+-- @supersedes exclude-tags-in-code-blocks
+-- @supersedes make-show-page-able
+-- @supersedes only-separate-generated-tags-with-a-blank-line-when-description-does-not-end-with-tags
+--
+-- @difficulty medium
+-- @priority medium
+-- @topic markdown
+-- @topic tags
+
-- TODO Tag improvements (OR-filtering)
--
-- Currently it is not possible to filter for an issue satisfying one filter or another. We could add the following syntax allowing it: