Fixed the code for GHC 7...

Nicer LaTeX output would be

\begin{itemize}
\item[$\square$] Foo bar
    
    baz
\item[$\boxtimes$] ok
\end{itemize}

which renders like this:

Yes, I've changed it to \item[$\square$], followed by a newline for consistency with how we render normal lists...

This looks good so far. questions:

1. What about gfm/commonmark support? It's a bit awkward that this doesn't work with the gfm reader; that is what people are most likely to use anyway with this feature.

   gfm/commonmark support should be quite easy to add. In the clause for LIST at line 113 of the Commonmark reader, you'd just need to add another function in the pipeline, e.g. (handleTaskList . setTightness . addBlocks opts). This would be operating on a pandoc AST.

   But now, it makes sense to factor out this handleTaskList code and use it in the markdown reader as well, instead of the custom parsing code. That is, parse as normal into Str "[x]", Space, ... and then just revise the block.

2. What about the markdown and gfm/commonmark writers? Shouldn't they be recognizing the unicode checklist symbols at the beginning of lists (if the extension is set) and replacing with [x] etc.?

3. I think I'm okay with leaving out the span. This would mean that if one has a list item that starts with the modal logic box operator, it might be accidentally construed as a task list, but this would normally be in math mode.

I left the CommonMark parts as a todo because I wasn't sure what was the best way. Thanks for the pointers, I'll take a look in the next couple of days... I guess factoring out the handleTaskList is worth the second pass to eliminate code duplication?

About the "modal logic box operator": we're actually not using the U+25FB ◻WHITE MEDIUM SQUARE, but instead:

U+2610 ☐ BALLOT BOX
U+2612 ☒ BALLOT BOX WITH X

I think this is actually starting to look much better!

I wasn't sure whether handleTaskListItem should be [Block] -> [Block] or Blocks -> Blocks. But since we still support GHC 7, we cannot use pattern synonyms on Seq, so I went for the lists where we can just pattern match...

Note that I also changed the CommonMark Writer to output Raw Inline/Block "markdown". Not sure whether this should also be "commonmark", "gfm", or similar.

I agree, this is looking good!

I think the names taskListItemFromMd and taskListItemToMd are a bit odd, since these are AST transformations and not conversions to and from markdown. I wonder if taskListItemToAscii and taskListItemFromAscii or something like that would make more sense? (Alternatively, taskListItemFromUnicode, taskListItemToUnicode.)

Well, taskListItemFromMd converts an AST containing unparsed markdown tasklist text.

But indeed, other markup languages might use the same syntax for task lists (e.g. org mode checkboxes), and there we could reuse the functions. Therefore renamed to taskListItemFromAscii and taskListItemToAscii.

One more thought. Looking at our other extensions, I think task_lists would be a more consistent name for the extension than tasklist. (Compare example_lists, definition_lists, etc.)

I adopted the name from the GFM spec linked above, but if you think task_lists is better I can change it...

Yes, I think we should try to be internally consistent with naming conventions of extensions.

That is: task_lists is better.

Yes, makes sense. It's changed.

I forgot to document this change properly in the git log message, so I made a trivial follow-up change with documentation. For future reference, API changes should always be carefully document in the commit messages, so they can be indicated in the changelog.

Right... but good to see this merged into master!

Thanks for implementing this!
The default docx behavior doesn't look great though.

There is an issue with the spacing, and another with long lines. Both could be solved by using specific numbering styles with the proper bullets:

Should I open a separate issue for it? (I was reluctant since this isn't yet in a released pandoc version)

@agusmba We currently don't do anything in the docx writer to handle task lists. This is just the unicode fallback. I added the feature mainly for HTML output. But feel free to open a new issue for the docx output, best with an example docx xml snippet of how the output should look like.

I'll do that. Thanks!!

See #5198

Does this recognize - [] as a task list? (no space between the square brackets)

@jgm Would that functionality be accepted? I'd be happy to put in the PR since it looks like a one line change. I don't think it really interferes with anything else since I don't see what else - [] is used for.

As mentioned above, this was modeled after GitHub tasklists. There, it needs a space as well, so I would keep it that way.