Moved #3465 here, to address this in `stable` instead.
This fixes a problem with the Python domain object nesting. Because only one
object name was stored in `ref_context`, and reset to `None` in `after_content`,
nesting broke if you put anything after a nested class:
```rst
.. py:class:: Parent
.. py:method:: foo()
This wouldn't resolve: :py:meth:`bar`
.. py:class:: Child
In the `after_content` method, the object is reset to `None`, so
anything after this in the same nesting is considered to be top level
instead.
.. py:method:: bar()
This is top level, as the domain thinks the surrounding object is `None`
```
This depends on #3519 and can be rebased after that is merged into stable
Fixes#3065
Refs #3067
These are just the passing test cases for the domains currently. I am going to
patch up issues with nesting on both domains to start, so these are the test
cases I'll be testing against. I'll see about addressing the other core
domains, or at very least the cpp domain, with similar tests if this looks
okay.
So far, these tests only test against methods/functions for the basic nesting
structure. More complete tests will test additional domain roles.
Refs #662
in particular:
``\sphinxbelowtablecaptionskip`` renamed to ``\sphinxbelowcaptionskip``
as it may be extended in future to usage for captions of literal blocks.
- allow multi-paragraph contents in grid table merged cells
- allow code-blocks in merged cells
- allow generally speaking reST contents allowed in regular
cells to be also allowed in merged cells, whether multirow,
multicolumn, or both.
This is made possible by custom LaTeX macros replacing original
``\multicolumn`` and ``\multirow`` (none of the originals allows
verbatim contents as is needed for code-blocks). They are defined in
bundled LaTeX style file sphinxmulticell.sty. The multicolumn merged
cells give much better results with tabulary as it is coerced into
taking them into account in its automatic width algorithm.
This deprecates use of LaTeX packages eqparbox and multirow, which are
not needed anymore.
New config setting ``latex_use_latex_multicolumn`` (default value False,
currently) as custom Sphinx multicolumn is not fully compatible will all
types of custom table col specs which may be inserted via tabularcolumns
directive. It works best with standard ``|`` column separator.
The default tabulary column specifier has been changed from L
(flushleft) to J (justifying). Internally the column type is called T,
so ``r'\newcolumntype{T}{L}'`` in preamble key recovers the former
behaviour. A ``\Y`` column type is defined which admits one decimal
argument in place of the two integers for ``\X``.
At present, the 'builder' option for the setuptools integration only
supports a single output format, typically HTML, like so:
[build_sphinx]
builder = man
There is value in being able to specify multiple format, like so:
[build_sphinx]
builder = html man
Make this possible.
Signed-off-by: Stephen Finucane <stephen@that.guru>
