[WIP] Add colspan/rowspan support

[roblabla]

Fixes #1024

Dependant on jgm/pandoc-types#29

I needed this for one of my projects, so I went ahead and built it. This adds colspan/rowspan to the AST, and adds support for it in MediaWiki reader/writer.

My next goal is to add support to the markdown grid layout now, similar to reStructuredText's grid layouts.

I'm very new to haskell, so there's probably a better way to do things :).

This is a breaking change.

[jgm]

You also need changes to pandoc-types, and one can't see from these PR what changes you made there. That would be interesting to see. It looks like you took a different approach than the proposal in #1024, so it would be good to know more about it as we decide how best to implement row/colspans.

The final decision on the AST may be different from what you're assuming here. Nonetheless, once it is made (and I'd like to do this for pandoc 2.0), I'd really welcome help fixing up parsers to work with it. (And any work you do now on grid tables will be relevant whatever happens with the AST.)

[roblabla]

Woops, i forgot to submit the PR to pandoc-types. I'll do it when I get home.

…

On March 14, 2017 9:14:38 PM GMT+01:00, John MacFarlane ***@***.***> wrote: You also need changes to pandoc-types, and one can't see from these PR what changes you made there. That would be interesting to see. It looks like you took a different approach than the proposal in #1024, so it would be good to know more about it as we decide how best to implement row/colspans. The final decision on the AST may be different from what you're assuming here. Nonetheless, once it is made (and I'd like to do this for pandoc 2.0), I'd really welcome help fixing up parsers to work with it. (And any work you do now on grid tables will be relevant whatever happens with the AST.) -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #3508 (comment)

[jgm]

OK, that's an interesting approach, just adding two parameters that define col/rowspans for headers and rows. The advantage is that it makes the changes to the readers and writers more minimal. (To keep current behavior, one merely has to ignore the two extra parameters or pass them default values.) But, without taking that practical consideration into account, it seems less clean than an approach that builds this information into the cells themselves, as in the proposal floated in #1024:

type Rowspan = Int
type Colspan = Int
data Cell = Cell Rowspan Colspan [Block]
data Row = Row [Cell] | Header [[Cell]]
type Caption = [Block]
-- constructor for Table in Block:
   | Table Attr Caption [Alignment] [Maybe Double] [Row]

[roblabla]

So I tried to do something like that at first and more or less failed due to my lack of knowledge in haskell (for instance, I had no idea how to adapt Walkable : https://github.com/jgm/pandoc-types/pull/29/files). Hence why the current approach was taken. This PR is more or less my only contact with haskell ^^'.

I'm also thinking of making an utility function for writers that don't support col/row-span that creates empty table cells instead. This should avoid situations like : http://wiki.vg/Protocol#Window_Property turning into http://prismarinejs.github.io/minecraft-data/?v=1.11.2&d=protocol#toClient_craft_progress_bar

[jgm]

+++ Robin Lambertz [Mar 14 17 15:33 ]:

So I tried to do something like that at first and more or less failed due to my lack of knowledge in haskell (for instance, I had no idea how to adapt Walkable : [1]https://github.com/jgm/pandoc-types/pull/29/files). Hence why the current approach was taken.

If you're interested in working on this, perhaps we could collaborate? I could handle the pandoc-types changes. To ease the transition, we could perhaps define a pattern synonym that mimics the old type https://mpickering.github.io/posts/2014-11-27-pain-free.html Or, more low tech, we could define a data type that mimics the old table constructor and a function that converts between this and new-style tables (in a lossy way, of course). I'm not thinking of this as a long-term fix, but more of a bridge that makes it easier to get the whole code base compiling again after the type change.

I'm also thinking of making an utility function for writers that don't support col/row-span that creates empty table cells instead.

Makes sense. This could be useful in some formats, though most have SOME way to support row/col-span (if only via raw HTML).

[luke-sift]

I haven't got any experience with Haskell, but would like to add that this feature is very much needed. Thanks for your work on this so far.

[mb21]

@luke-sift see #1024 (comment) for the latest proposal for the AST change this requires...

[tarleb]

We've since went with a different table structure. I believe MediaWiki support was added in 0b003de, so I'm closing this now.

Nevertheless, thank you for the contribution!