Allow tables without headers

[ghost]

Seems like there is support for allowing tables without headers (https://github.com/miyuchina/mistletoe/blob/master/mistletoe/block_token.py#L622) but it doesn't seem to be allowed by parsing (https://github.com/miyuchina/mistletoe/blob/master/mistletoe/block_token.py#L661).

Would you consider allowing headerless tables? Perhaps something like the following would be a headerless-table?

--- | --- | ---
cell1 | cell2 | cell3
cell4 | cell5 | cell6

[ghost]

I guess another option is I can write my own custom token that doesn't do the check for '---' in read. Although, an example of a custom block-level token in the README would be nice. :)

[miyuchina]

I'm going to treat this as a bug and fix it in the implementation. For additional documentation of custom block-level tokens, I'm opening a new issue.

Thanks for this!

[pbodnar]

Looking at this in relation to the new issue #131...

It looks like the mistletoe's code is really kind of "schizophrenic", having one part prepared for allowing skipping of the header separator line, while another part banning it.

Anyway, this could be treated as an enhancement, as even GFM doesn't support header-less tables. But others like kramdown do (a more complete list at SO). The syntax would probably look rather like this (an example borrowed from kramdown docs):

| A simple | table |
| with multiple | lines |

[anderskaplan]

The current state of the table parsing code is indeed ambiguous, and the docstring describing the Table token is misleading. It looks like there are remnants from an older version of the code, and it would be nice to get this fixed. I'd be happy to take a stab at it, but then I'll need a bit of direction: do we want support for headerless tables or not? And if yes, to what extent?

The simple example above where the header and separator lines are just omitted is simple enough, however, the table spec from Kramdown is quite extensive and adds not only headerless tables, but also makes start and end pipe characters optional, introduces additional separator lines, etc. So adhering to the Kramdown table spec would be quite a bit of work and I don't really see the point of it.

My suggestion would be to let tables adhere to the GFM spec and NOT support headerless tables -- but to remove the ambiguity in code and comments. (In the same spirit, I'd also suggest to implement #131, but that's a separate topic.)

Or, as a second option, to implement support for headerless tables like the one in the simple example above.

Thoughts?

[pbodnar]

@anderskaplan, thanks for the analysis!

As there doesn't seem to be enough drive / votes from the mistletoe community to support the requested feature, I would also vote for just cleaning up the code and be GFM-compliant, i.e. NOT to support headerless tables, at least for now.