This reverts the ``\scantokens`` added (commit 86083875) to ``\code``
(aka ``\sphinxcode``), in case it is encountered inside a parsed-literal
directive. Indeed strange interference arise then. The problem would
occur in Verbatim too, but I think ``\sphinxcode`` is not encountered
there.
Depending on the version of the italian module for LaTeX Babel, the
double-quote character may have been or not declared as a babel
shorthand. The babel ``\shorthandoff`` macro emits an error which aborts
compilation if the character isn't a shorthand. This commits wraps the
macro in a conditional to test if the character is active or not.
modified: sphinx/writers/latex.py
Via re-definable ``\sphinxbreaksbeforelist`` and ``\sphinxbreaksafterlist``,
latex user can specify (using ``'preamble'`` key for example) if broken
code lines are split before or after the said character when code blocks
are wrapped. Punctuation characters use active catcodes and are
configurable via further macros ``\sphinxbreaksbeforeactivelist`` and
``\sphinxbreaksafteractivelist``. The defaults in ``sphinx.sty`` can be
modified by imitation in user document preamble.
n.b.: ``\sphinxbreaksatpunct`` has been renamed to ``\sphinxbreaksviaactive``.
The potential linebreaks at commas in code lines were not inserted due
to latex kernel macro ``\@noligs`` which is issued by fancyvrb.sty
during its line processing. From the default `` `<>,'- ``, only the
backtick is left to be handled by ``\@noligs`` because the others are
either already replaced by a macro by Pygments, or (only the comma) made
active by sphinx.sty to insert potential linebreaks.
This came from the spurious space tokens following a fullwidth rule at
top of ``\maketitle`` in ``sphinxhowto.cls`` and ``sphinxmanual.cls``.
The ``\newline\null\par`` incantation recreates the extra empty line
which originated in these spurious space tokens, but it avoids the
Underfull latex warning. Nothing is changed to layout from this fix.
Adds some ``\relax``/``\unskip`` and removes spaces from ``visit_entry``
generated latex code. Earlier, multirow cell inherited one extra space
token at begin and one at end, making left or right alignment with other
cells fail because the native LaTeX space removal mechanism for table
cells could not apply there.
Memo: the ``\eqparbox`` part of ``visit_entry`` from e41f831f is left
untouched; separate analysis required.
Memo: this command produces a list of the code listings in the document
(with chosen title foo), analogous to ``\listoffigures``, and it comes
from LaTeX package float.sty.
This should not change anything for Sphinx produced documents without
extra custom use of float package by user, and is recommended by wrapfig
doc for good functioning.
- 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).
MEMO: the used formula is correct as long as package array is loaded.
Package array (which modifies how the width of vertical rules is counted
in the total width of the tabular) is a dependency of packages tabulary,
and eqparbox, and possibly others which are currently loaded by
sphinx.sty. Even if usage of package tabulary is dropped in future
version of sphinx.sty, there would still remain the dependency on array
via eqparbox, and the formula configured in latex.py will remain
correct.
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``.
Functionality is now at bottom of sphinx.sty. For case of
``\sphinxstylesidebarsubtitle`` from b3d8961, there should probably be a
``\par`` before the ``\smallskip`` but current code is exact transfer of
original from latex.py to sphinx.sty.
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).
latex: let sphinx.sty use own \spx@ifundefined for some tests.
the first commit is more aggressive, I leave it in commit history in case it could be useful in future.
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.
The update incorporates
\changes{v0.10}{2014/06/21}
{support \cs{cellcolor} see
http://tex.stackexchange.com/a/185851/1090}
from tabulary commented source.
Memo: Sphinx ships a custom tabulary to fix a footnote issue, in
relation with package footnote:
sphinx.sty does \makesavenoteenv{tabulary} but this needs also
a patch inside tabulary package
It would be better, as package footnote has some bugs, for Sphinx to
ship with package footnotehyper which fixes theses bugs and can easily
be extended to ensure the compatibility with tabulary. This would be
better than shipping a custom tabulary.
Allow code-blocks at maximal nesting depth of lists/quotes in LaTeX
(which by default is 6), by patching fancyvrb's original Verbatim way of
checking list depth which resulted in a loss of 1 possible level.
Memo 1: latex can have by default a maximum of 4 nested enumerated
lists, 4 nested labeled lists, and in total 6 nested lists. This
includes quoted blocks as they use the `\list` macro.
Memo 2: fancyvrb's rationale for using the \@list... macros (in its
\FV@ListNesting) is to set vertical positioning. To set a Verbatim at
level N it uses vertical parameters for list level N+1, hence can't work
at max level. But in Sphinx, this happens inside a \vbox for framing,
hence the vertical positioning set by fancyvrb turns out to be inoperant
anyhow. The execution of \@list<level> also sets the \leftmargin, but
fancyvrb resets it to zero later (#1=\z@ in \FV@ListNesting). To sum up,
fancyvrb's \FV@ListNesting does nothing but has the after effect to
raise an error if the code-block is at level equal to max - 1.
The effect of this commit is to make inoperant fancyvrb's check of
nesting depth, hence now the code-block can appear at maximal depth.
This is second commit improving in Sphinx the maximal depth for
code-blocks in nested lists or quote blocks. It used to be 4 (with
LaTeX's defaults for lists), it is now at 6 (or at the max depth
allowed by the document class).
This is \list --> \trivlist replacement in Sphinx wrapper of original
Verbatim from package fancyvrb. This gains one level for allowed
location of a code-block in nested lists/quotes.
Move \@newlistfalse from 18eb553b to earlier location, else LaTeX's \par
will created obsecure "missing item error" if Verbatim code-block is
enclosed in warning notice, and warning notice is in quote block ...
Jean-François B