When table data contained a newline, the result of minirst.maketable
did not look nice plus it was not recognised by minirst.format:
== === ====
l1 1 one
l2 2 2
22
l3
== === ====
This problem occurred when the description of options had a very long
translation which was split by newlines. Do not bother a translator with
this detail.
The multiline translations for option descriptions have been fixed in
7a88a81d5d9e in it.po, de.po and ro.po. I manually did the same as this patch
does, I removed the newlines.
When a newline was in the description, this created unusable help output:
$ hg help somecommand
hg somecommand [option]...
with somecommand, you can...
options:
== =================== =======================================================
=================================== --longdesc VALUE xxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -n --norm
normal desc --newline VALUE line1 line2 == =================== ===============
===========================================================================
now this looks much nicer:
...
options:
--longdesc VALUE xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-n --norm normal desc
--newline VALUE line1 line2
Modifying the test input data shows the effects of the last patches.
In text output nothing has changed.
In html output the title has moved on its own line.
The default width of field lists is changed from 12 to 14 to align minirst with
the rst2html tool. Shrinking the width of the left column to fit the content is
removed, to keep formatting simple and uniform.
Formerly RST blocks were formatted without a trailing newline, which
wasn't particularly helpful. Now everything that comes back from the
formatter has a trailing newline so remove all the extra ones added by
users.
This adds a subset of the 'simple table' support from RST to allow
formatting of options lists through RST. Table columns are
automatically sized based on contents, with line wrapping in the last
column.
This enables minirst to parse and print option lists which have both
long and short options. Before, we could only parse option lists with
long options.
Text can be grouped into generic containers in reStructuredText:
.. container:: foo
This is text inside a "foo" container.
.. container:: bar
This is nested inside two containers.
The minirst parser now recognizes these containers. The containers are
either pruned completely from the output (included all nested blocks)
or they are simply un-indented. So if 'foo' and 'bar' containers are
kept, the above example will result in:
This is text inside a "foo" container.
This is nested inside two containers.
If only 'foo' containers are kept, we get:
This is text inside a "foo" container.
No output is made if only 'bar' containers are kept.
This feature will come in handy for implementing different levels of
help output (e.g., verbose and debug level help texts).
Before, we used the padding following the key to compute where to wrap
the text. Long keys would thus give a big indentation. It also
required careful alignment of the source text, making it cumbersome to
items to the list.
We now compute the maximum key length and use that for all items in
the list. We also put a cap on the indentation: keys longer than 10
characters are put on their own line. This is similar to how rst2html
handles large keys: it uses 14 as the cutoff point, but I felt that 10
was better for monospaced text in the console.
Input such as
Only the
left-most line
(this line!)
is significant
for the indentation
is not valid reStructuredText: the first line starts a block quote,
but then the second line is not allowed to be unindented.
The vast majority* of them are formatted like this in the source, so
this basically reverts the output to how it looked before we got the
minirst parser.
*: the help on templating use four spaces for some examples and will
now shown with an indentation of just two spaces.
