Skip to content
This repository has been archived by the owner on Mar 26, 2022. It is now read-only.

Support Tables #28

Closed
lu-zero opened this issue Dec 12, 2015 · 5 comments
Closed

Support Tables #28

lu-zero opened this issue Dec 12, 2015 · 5 comments

Comments

@lu-zero
Copy link
Collaborator

lu-zero commented Dec 12, 2015

See readthedocs/recommonmark#3

We should probably match the support markdown-it implemented at least.

@belak
Copy link

belak commented Jan 23, 2017

I assume nobody's working on this (as there doesn't appear to be an official extension yet) but are there any plans to support any of the existing table syntaxes?

@agjohnson
Copy link

I believe I am going to take a swing at this tomorrow. I raised the following question on readthedocs/recommonmark#3 already:

Do we keep CommonMark vanilla CommonMark, and instead subclass or patch the CommonMark.Parser in recommonmark, or would experimental CommonMark spec features make more sense in the CommonMark package?

I'd like to keep experimental features configured under an option flag, and if there is ever movement in the table syntax and extension syntax, the experimental features would issue deprecation warnings after they are moved to the main parser. Does any of this sound antithetical to this package? At this point, I feel like the lack of these features is hurting recommonmark adoption.

@agjohnson agjohnson self-assigned this Feb 19, 2017
@nikolas
Copy link
Collaborator

nikolas commented Feb 19, 2017

Cool, sounds good. Up to this point I have been trying to focus on the upstream commonmark spec, and afraid of adding new syntax like this because it could get more complicated to maintain. I definitely see how this is a needed feature though for recommonmark / rtfd, and I like the idea of experimental features under an options flag.

Keep in mind that the Python-Markdown library supports tables:
https://pythonhosted.org/Markdown/extensions/tables.html
So one approach could be adding compatibility with that library to recommonmark. But after glancing over recommonmark it looks like it does dig pretty deeply into this library's API, so I don't know if that's so straightforward.

@JoshData
Copy link

JoshData commented Nov 1, 2017

Hi all. I have a mostly working implementation of an extension to this library for parsing and rendering tables here:

https://github.com/GovReady/CommonMark-py-tables/blob/master/CommonMarkTables/__init__.py

It attempts to follow Github Flavored Markdown.

We'd be happy to have this be incorporated into this library, or not (because I totally understand the hesitance over incorporating non-standard extensions). If not, this might at least be informative for how to make this library a little friendlier for extending it.

@leniy
Copy link

leniy commented May 24, 2018

I know recommonmark will never support table , cause this is a major feature than markdown , to let people to use rst.

So,is there any other Parser for sphinx to use ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants