test for "hg help -c config" in help config
``section``
-----------
section text
``def1``
definition of def1
$ hg help scope.def1
should list this paragraph, but not section text below...
section text
``def2``
definition of def2
$ hg help scope.def2
should list this paragraph, but not section text below...
section text
$ hg help scope.section should show everything from the first
section text to this last line.
``section2``
------------
Used to be that `hg help hgrc.paths` would show
"paths"
-------
Assigns symbolic names to repositories. The left side is the symbolic
name, and the right gives the directory or URL that is the location of the
repository. Default paths can be declared by setting the following
entries.
and stop there. Obviously the result seems better as shown in the
attached test.
There was a bug in df3ceb2fbb4d. The block that added definitions to
getsections should have been an elif, not an if. Otherwise section
titles get added twice, since the else clause would always get
executed for section titles.
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
Lines with only a directive are not deleted anymore because they are detected
before comments are deleted by prunecomments().
addmargins() will be adapted later.
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.
# this change redones part of e0051068893a, backed out by 38c00c035629
Some character encodings use ASCII characters other than
control/alphabet/digit as a part of multi-bytes characters, so direct
replacing with such characters on strings in local encoding causes
invalid byte sequences.
[mpm: test changed to simple doctest]
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 standalone mode no longer works due to the mechanics of import
and util. When run not as part of a package, the import of util causes
an import of the built-in posix module, which doesn't contain the
expected symbols. This is difficult to fix in Py2.4.
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.
These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
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.
