diff options
Diffstat (limited to 'app/Main.hs')
| -rw-r--r-- | app/Main.hs | 49 |
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 -- |