reading DOCX, pick table width from the longest row -- closes #4360

[danse]

this is related to jgm/pandoc-types#36. the test here will have to be updated when that version of pandoc-types will made it to pandoc

[jkr]

This looks good, except that ghc 7.10 build fails on the NonEmpty import, since semigroups wasn't in base yet. We have to either load semigroups for earlier ghc or, what's probably less trouble at the moment, keep the ugly case statement at 654. I'd recommend the latter.

[danse]

cool, i propose a simple ad hoc implementation of nonEmpty, let me know what you think. cheers

[jkr]

Sure. When we drop support for ghc 7.x, we can use real NonEmpty. Couple more things:

1. The test case doesn't demonstrate the issue, or the fix. Since the first row is the longest one, it gets the same result with or without the commit.

2. The commit message could be more helpful. Could you commit with a message like:

   Docx reader: Pick table width from the longest row
   
   [Longer message explaining change]
   
   closes: #4360
   

   That way, when people see the commit in the future, they'll understand it.

[danse]

actually the test case is suited and will fail if the fix is not there. what looks like the first row in the native are actually the headers, but pandoc would use the length of the first row before this change. i updated the commit message as you asked

[jkr]

Oh, I see -- I misunderstood the purpose of the commit. I apologize. (But it does underscore the importance of informative commit messages.) This change only affects the alignments and column widths only, correct?

Thanks for the fix, and your patience!

[jkr]

committed in e6ff7f7

[danse]

thanks to you 👍