Open tommyengstrom opened 4 years ago
To be fair I would implement this directly into Parser.hs. My only problem is should tasks be nodes or just inlines (i.e should tasks just be unordered lists and then have another constructor Task for Inline, or should we have a completely separate node, TaskList).
If going for inlines I would say to have a pTask parser like this
-- | Parse a Task.
pTask :: IParser Inline
pTask = do
void (char '[')
checked <- (True <$ char 'x') <|> (False <$ char ' ')
void (char ']')
sc'
txt <- disallowEmpty pInlines
Task checked txt <$ lastChar OtherChar
and adding the Task into the Inline data type like this
data Inlines =
...
| -- | Task with status and description
Task Bool (NonEmpty Inline)
then in the pInlines :: IParser (NonEmpty Inline)
function on the [
case should have a call to it
I would like to support tasks, just as we have available here in github:
I was hoping to be able to do this using the extension module but as far as I understand it that can't be done.
- [ ]
ends up being parsed as a broken link. Is is possible to do this as an extension?If not, and if you're interested in having this feature, can you give me some hint on how to add it?
in GFMD it seems there is (somewhat shaky) support for task in numbered lists, e.g.
renders as
I never tried that before right now, I wouldn't implement it unless I had to.
However, the
Block
constructor for Unordered lists isUnorderedList (NonEmpty [Block a])
, but tasks are only really supported in lists. The natural way seem to be wrapping theBlock a
ref in something that can tell if it a normal block, unfinished task, or finished task. Is there a better solution? Would that solution be accepted?