Mark tables as "table" instead of "paragraph" at lexer? about marked

[chjj]

What do you mean by table? I figure you're referring to the html element, but those are considered html blocks by the lexer.

[bebraw]

Hi,

Thanks for the swift reply and sorry for being unclear. Here's an an example of what I'm talking about. I guess the GitHub guys must be using some custom table plugin.

I'm not sure if this is something you should support natively. If you think so, great. Otherwise I probably could use some nice extension mechanism to hook into the lexer to avoid certain nastiness.

[chjj]

This is something people have been asking for. It might be good to keep everything contained in one issue: #27 .

[bebraw]

Gotcha.

I noticed you that had done some experiments with an extension API. Any timeline on this? I don't mind helping out a bit if you can point out how. I really wouldn't mind getting those tables to work properly. :)

[chjj]

The extension API might not happen. The more I think about it, the more unrealistic it is. Take for instance the text regex for the inline rules: text: /^[^\0]+?(?=[\\<!\[_*]| {2,}\n|$)/`. If any inline rule is ever added, this regex needs to be updated accordingly to work properly. There's a lot of other little annoyances that would make it difficult. But, eventually, f I can dream up a nice clean interface to make marked extensible, without hurting performance, I will do it.

[bebraw]

Do you think some kind of hierarchical scheme would work? As I mentioned earlier tables get parsed as "paragraphs" now. If there was a way to attach another lexer to the context of paragraph it would do the trick I think.

This is sort of what I do in my current solution at ghw. I just check if the lexer gives my a text or a paragraph and then apply my rules in a certain order. Actually now that I think of it I can probably hack tables there using the same scheme. Need to give that a go to see how ugly it gets. :)

Thanks for the feedback. :)