This fixes only the case the label including both spaces and colons as
ad-hoc. There is still a bug if a label having spaces, colons and
numbers like "foo bar:baz 1234".
Note: To support the case, we have to improve the inventory format.
- new dimensions ``\sphinxverbatimsep`` and ``\sphinxverbatimborder``
configure the frame width and its separation from contents,
- new ``\ifsphinxverbatimwithframe`` and ``\ifsphinxverbatimwrapslines``
to customize behaviour of sphinxVerbatim or define wrapper
environments, such as sphinxVerbatimNoFrame and sphinxVerbatimintable,
- the latter is used in table cells, in place of OriginalVerbatim, thus
allowing to handle captions for code-blocks in tables (issue #2706).
On this occasion, a bit of refactoring in sphinx Verbatim code,
particularly the caption is typeset in advance to its insertion in
non-breakable from code location (this avoids using the amstext
``\iffirstchoice@`` conditional), and the sphinxVerbatim is usable
without any optional argument (but currently option is always present
and contains at least ``commandchars=\\\{\}`` to activate syntax
highlighting).
The refactoring maintains backwards compatibility for the non-customized
usage: but macros such as ``\py@noticesstart@note`` have been removed
and any customization by extension or user will be without effect.
However the ``notice`` environment is still used, hence customization or
modified usage of it will work as before.
The LaTeX writer now uses ``sphinxadmonition``. Currently it is a
wrapper of ``notice`` environment. At some future release ``>1.5`` of
Sphinx it is planned to remove definition of ``notice`` environment, and
rename it directly to ``sphinxadmonition``. In the transition period
both will work, but at end of transition period extensions using only
``notice`` will stop working and those using ``sphinxadmonition`` will
require at least Sphinx ``1.5``.
Seems longer lines are more frequent since 1.4. I hard-wrapped at 80
chars the ones I committed which sometimes exceeded 100 chars. Other
long lines remain (one has 108 chars).
The cause of the issue was a clash about ``\titleref`` macro being already
defined in memoir class context. To avoid similar problems, this makes
the text styling macros
``\strong``, ``\code``, ``\bfcode``, ``\email``, ``\tablecontinued``,
``\titleref``, ``\menuselection``, ``\accelerator``, ``\crossref``,
``\termref``, ``\optional``,
also available with ``\sphinx`` prefix, with a conf.py boolean option to
let sphinx.sty only define ``\sphinx``-prefixed macros. As default value
is False, backwards compatibility is maintained.
On this occasion, some internal non-public macros have been renamed with
prefix ``\spx@``. The command
find . -name '*.sty' -exec grep -l \\\\spx@ {} \;
has been executed in TeXLive 2015 and 2016 installations to check no
package defines macros starting with ``\spx@``.
Some internal macros having public names (because they are written by
latex.py into the body of the latex document) have been renamed to have
``\sphinx`` prefix. The macros in sphinx.sty starting with \py@, or \DU,
or \PYG have not been modified. Similarly ``\release``, ``\version``,
``\releasename``, etc... have not been renamed.
jfbu
mixmastamyk
Takeshi KOMIYA
Tadej Janež
Jakob Lykke Andersen