pandoc
pandoc copied to clipboard
jgm
rST writer: add option for list tables, closes #4564
this changes the API adding a global --list-table option which only
affects the rST writer, and causes all tables to be rendered using the
list table syntax documented here
http://docutils.sourceforge.net/docs/ref/rst/directives.html#list-table
I get the following failure on Linux 8.8.4, to be honest it doesn't seem related to these changes
defaults-inheritance-2.md
#1: Error: Circular defaults file reference in 'command/defaults7.yaml'
Thanks for the update. As noted in the issue, my main reservation about merging this is that it adds a new command-line option and alters WriterOptions (an API change that could break existing code). Also, people might want certain tables to be list and others not. The ideal solution, it seems to me, is to make this triggered by an attribute on the table (and thus on a per-table basis). And we now do have table attributes. The problem is that you still can't set attributes on tables in most formats (though this could always be done with a filter).
people might want certain tables to be list and others not
Theoretically, yes. But in many cases the team styleguide defines one preferred style for tables in rST. In my previous and current job it's the list-table.
Having two types of tables in a large documentation set is a likely situation, indeed. One has legacy code and so on. But within a single document most often there's one style.
Also, in my experience, a common case for writing rST is migrating a large set of documents from some other format to rST. In such case I would use list-table as the default setting and pick usual, ascii-art tables for special cases like cell spans.
The problem is that you still can't set attributes on tables in most formats (though this could always be done with a filter).
Writing filters is way more difficult than just using pandoc as a CLI application. A lot of users won't be able to write a filter.
I think we wouldn't lose anything if we went with the attribute-controlled solution first, as the command line switch could still be added later. @danse, do you want to update the PR, or would you prefer for somebody else to make those modifications?
Any update on this one? Nobody really uses grid tables for anything serious, AFAIK. :)
apologies for answering late on this one. I am not working at this project anymore so the change of scope has been a blocker for too long. As i wrote in #4564, i am willing to devote some time in the next future to merge these changes. Since @jgm's position seems to be quite firm, and we have no data about users' preferences, i will work towards the direction of using attributes. I hope to also include a sample script to set these attributes for all tables, so hopefully it will be easy enough for most users to switch to list tables
My position isn't firm. I'm open to a global option that uses list tables for all tables in a document. I just don't know enough about how these are used to make the decision.
Side note: The ConTeXt writer uses the ntb extension to switch between "natural" and "extreme" tables. It might not be a good idea to add more extensions, but it could still make sense in this case.
My position isn't firm. I'm open to a global option that uses list tables for all tables in a document. I just don't know enough about how these are used to make the decision.
Well, if we went for the attributes, there would be no way to produce list tables for some users, although i think that a Pandoc script would significantly help.
When i was working on automated conversion of documents we had guidelines about how to format .rst, so we considered list tables more convenient and just used them in all cases, using a fork.
Anyway i might be biased towards merging this as it is, and i agree that reducing global options is desirable.
Side note: The ConTeXt writer uses the
ntbextension to switch between "natural" and "extreme" tables. It might not be a good idea to add more extensions, but it could still make sense in this case.
I did not work much with extensions. If i understand correctly they pollute a global namespace as well. By looking at the manual i do not find advantages in using extensions rather than options.