add comments to all comments

1 files changed, 49 insertions, 0 deletions

diff --git a/app/Main.hs b/app/Main.hs
index a199643..4b4213e 100644
--- a/app/Main.hs
+++ b/app/Main.hs
@@ -75,6 +75,12 @@
 -- @topic options
 --
 -- COMMENT Do we expect the code BEFORE an issue to be ever relevant?
+--
+-- COMMENT Hm, this would make it possible for users to use anissue in
+-- that way at least.  I guess most people would assume a comment to go
+-- before (or for a short comment at the end) the relecant line(s), so
+-- maybe an `--after/-A` option would suffice.  Not sure what's best
+-- here to be honest. =)
 
 -- TODO Expose all command line options as environment variables
 --
@@ -90,6 +96,13 @@
 -- COMMENT Can/ should this be made a feature of optparse-applicative, which we
 -- could fork? Like, can this work transparently if we fork
 -- optparse-applicative?
+--
+-- COMMENT Hm, this would only apply to options and flags, but not sub
+-- commands, I guess.  I would say, we could first start by just
+-- manually adding these env variables and see if we run into
+-- options/flags, where a env variable does not make sense.  But then,
+-- this would be an optional feature in the library, as well, i guess?
+-- :D
 
 -- TODO Add a subcommand which appends the generated ids to the issue in the sourcecode
 --
@@ -116,6 +129,12 @@
 -- COMMENT Can you elaborate on why this would be useful? I am expecting us to
 -- do some renaming detection regarding provenance. After that, will it be
 -- useful still?
+--
+-- COMMENT I think, I mostly find this useful for ammendments, as I then
+-- neither would have to think about what the generated id was, nor
+-- would I have to come up with an id.  And if we would decide for
+-- randomized (but easily typeable) generated ids, this would be useful,
+-- I believe.
 
 -- FIXME Exclude tags in code blocks
 --
@@ -169,6 +188,10 @@
 -- That being said, I am up for experimenting with random IDs *alongside* the
 -- current design. Maybe we could add a `@uuid` tag automatically that is
 -- generated from the issues first `@id`, and append that?
+--
+-- COMMENT I think I like the idea of adding an id, once we see a change in the
+-- title.  I'm not sure though, when in the workflow this would happen.
+-- I think the id generation topic needs some syncronous discussion. :D
 
 -- TODO Dependencies between issues
 --
@@ -222,6 +245,19 @@
 -- I am fine with having emojis by default. However, seeing that markers are
 -- extendable, maybe we should make it an opt-in configuration in the first
 -- place?
+--
+-- COMMENT Yes, thinking about this again, putting the written marker
+-- instead, might be better.  So sth like.
+--
+-- ```
+-- FIXME    Issue A
+-- FIXME    Issue B
+-- TODO     Story A
+-- QUESTION Question A
+-- FIXME    Issue C
+-- ```
+--
+-- We could still additionally color code them.
 
 -- TODO Add option to group issue list
 --
@@ -262,6 +298,8 @@
 -- COMMENT For consistency, I would like the option to use `--group-by @topic`.
 -- Arbitrary tag grouping seems sufficient for this, assuming we add the
 -- respective *internal tags*.
+--
+-- COMMENT Sounds good!
 
 -- FIXME Crash when displaying some unicode emojis
 --
@@ -313,6 +351,8 @@
 --
 -- PS. Nothing prevents us later to extend functionality by special cases,
 -- should we dislike an internal `@title` tag.
+--
+-- COMMENT I like this approach! :)
 
 -- TODO Add command for (re)generating the cache
 --
@@ -334,6 +374,15 @@
 --
 -- COMMENT What is the point of this command? Can't caches be handled
 -- transparently to the user?
+--
+-- COMMENT Hm, I think I don't exactly know, what you mean by
+-- transparently. ':)  So cache invalidation would be like how e.g. elm
+-- does it with the elm-stuff folder?
+--
+-- The idea for the cache generation command could be e.g. used in
+-- environment setup scripts.  And then the first-commit option would
+-- make it possible to use very old repostories without a too long
+-- initial delay.
 
 -- TODO Add global option for specifying first considered commit
 --