Open aarongable opened 3 years ago
Ideas:
I don't particularly like the first idea; often table cells are multi-line, and cramming multiple cells of info into a single line makes that line very hard to edit.
The second idea is a reasonable compromise. In tables where the rows are short, it can be left inline and edited in much the same way that a traditional markdown table would be (just with commas instead of pipes to separate cells). In tables with very long rows, the table could be broken out to a separate file and edited with dedicated csv-editing tools.
The third idea is the one I like the most, but might be hardest to integrate into this build action. It requires either adding a bunch of CSS and wrapping all the markdown tables with some inline HTML, or adding an additional step in the build process to convert certain lists to tables before generating the various outputs.
Yeah, I was mainly looking at the second and third options, using Pandoc filters. For example, for using CSV, pantable is likely the best option, as it supports Pandoc's full AST for tables. I've seen some filters for list-syntax, but they haven't been updated to support Pandoc's extended AST (which allows for colspan and rowspan in the docx, LaTeX, and HTML outputs, which we'd likely want)
There's a whole bunch of discussion in the Pandoc and CommonMark repositories regarding tables and syntax, so this definitely hasn't converged.
For Pandoc, only grid tables support inline block markdown (e.g. lists and line breaks being the two most important). grid tables are effectively the RST table format, but editing is definitely a pain.
Tables are notoriously hard. The whole point of markdown is that the plaintext input should be readable; the whole point of tables is taking generally unreadable input and laying it out in a more digestible way. It would be great to have a way to reconcile these.