Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RST Writer: auto-wrapping accidentally creates "Definition list" in tables #3276

Closed
ickc opened this issue Dec 4, 2016 · 12 comments
Closed

Comments

@ickc
Copy link
Contributor

ickc commented Dec 4, 2016

Sorry I don't have a MWE since the input and output has to be in a specific way such that:

say, in a table cell in markdown: has_header: True | False, the rst output wrapped into

has\_header
: True \| F
alse

The : on the beginning of the new line becomes a definition list, and rst2html complains:

Definition list ends without a blank line; unexpected unindent.

Example

The only example I can give is in native pandoc AST since the table is generated by my filter:

command used:

# pandoc 1.19
pandoc -f native -o test.rst test.native
# (Docutils 0.12 [release], Python 3.5.2, on darwin)
rst2html.py test.rst > test.html

The AST, generated RST and HTML are here.

@jgm
Copy link
Owner

jgm commented Dec 4, 2016

This is similar to #3270. We can escape every colon to ensure this never happens, but then the output is ugly. Ideal thing would be a much more sophisticated wrapping method.

@ickc
Copy link
Contributor Author

ickc commented Dec 4, 2016

Ok, I think this one should be closed. Should the title of #3270 be changed to reflect the more general problem?

@ickc ickc closed this as completed Dec 4, 2016
@ickc ickc reopened this Dec 5, 2016
@ickc
Copy link
Contributor Author

ickc commented Dec 5, 2016

Since #3270 is fixed, probably I should keave this open instead.

@jgm
Copy link
Owner

jgm commented Dec 5, 2016 via email

@ickc
Copy link
Contributor Author

ickc commented Dec 7, 2016

I'll try to hunt down a smaller example. Since the nature of the problem involves wrap and table make it difficult to reproduce.

@jgm
Copy link
Owner

jgm commented Dec 7, 2016 via email

@nsoranzo
Copy link

nsoranzo commented Dec 8, 2016

I have a similar issue with Pandoc 1.19 when converting from markdown_github to rST:

pandoc schema.md -f markdown_github-hard_line_breaks -s -o schema.rst

where schema.md contains this table:

Attribute | Details | Required
--- | --- | ---
``id`` | Must be unique across all tools; should be lowercase and contain only letters, numbers, and underscores. It allows for tool versioning and metrics of the number of times a tool is used, among other things. Find the Intergalactic Utilities Commision suggested best practices for this element [here](https://planemo.readthedocs.io/en/latest/standards/docs/best_practices/tool_xml.html#tool-ids). | True
``name`` | This string is what is displayed as a hyperlink in the tool menu. Find the Intergalactic Utilities Commision suggested best practices for this element [here](https://planemo.readthedocs.io/en/latest/standards/docs/best_practices/tool_xml.html#tool-names). | True

generates this broken rST:

+------+------+------+
| Attr | Deta | Requ |
| ibut | ils  | ired |
| e    |      |      |
+======+======+======+
| ``id | Must | True |
| ``   | be   |      |
|      | uniq |      |
|      | ue   |      |
|      | acro |      |
|      | ss   |      |
|      | all  |      |
|      | tool |      |
|      | s;   |      |
|      | shou |      |
|      | ld   |      |
|      | be   |      |
|      | lowe |      |
|      | rcas |      |
|      | e    |      |
|      | and  |      |
|      | cont |      |
|      | ain  |      |
|      | only |      |
|      | lett |      |
|      | ers, |      |
|      | numb |      |
|      | ers, |      |
|      | and  |      |
|      | unde |      |
|      | rsco |      |
|      | res. |      |
|      | It   |      |
|      | allo |      |
|      | ws   |      |
|      | for  |      |
|      | tool |      |
|      | vers |      |
|      | ioni |      |
|      | ng   |      |
|      | and  |      |
|      | metr |      |
|      | ics  |      |
|      | of   |      |
|      | the  |      |
|      | numb |      |
|      | er   |      |
|      | of   |      |
...

The workaround for me is using --columns=500.

I think that --wrap=none should stop pandoc from enforcing a column width, but unfortunately it has no effect on tables.

@jgm
Copy link
Owner

jgm commented Dec 8, 2016 via email

@ickc
Copy link
Contributor Author

ickc commented Dec 8, 2016

I think that --wrap=none should stop pandoc from enforcing a column width, but unfortunately it has no effect on tables.

Also see #3171. I also confused with the wrap and column option too. While the manual said

It also affects calculation of column widths for plain text tables (see Tables below).

...

If a pipe table contains a row whose printable content is wider than the column width (see --columns), then the cell contents will wrap, with the relative cell widths determined by the widths of the separator lines.

May be it should mention something related to the fact that --wrap=none does not have an effect on it.

@nsoranzo
Copy link

nsoranzo commented Dec 9, 2016

I think that --wrap=none should stop pandoc from enforcing a column width, but unfortunately it has no effect on tables.

It's still nice to be able to adjust relative column widths in tables, even if you use --wrap=none.

Remember that --wrap=none also affects formats like HTML and LaTeX.

Agreed, but maybe a different option to specify this would be better, e.g. --table-width .

@nsoranzo
Copy link

nsoranzo commented Dec 9, 2016

A nicer solution is to use longer bars under the headers (see the documentation for pipe tables).

This works only to a certain extent because if multiple columns need to be of a certain width to not break rST syntax, adjusting the relative width is not enough and increasing --columns is the only option.

@jgm
Copy link
Owner

jgm commented Mar 2, 2017

I think this is a dup of #3340

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

No branches or pull requests

3 participants