All LaTeX commands such as \textbf, \emph, \underline.. are "short",
thus there was no need of ``\long`` prefix. Regarding
``\sphinxoptional`` which was defined via ``\newcommand``, the ``\long``
is there for full backwards compatibility, but a priori the argument
will always be a "short" one (i.e. not containing empty line or ``\par``
token.)
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
table directives on docutils-0.13.1+ set source information to
caption node. So these patch will be not necessary in feature
version of docutils.
https://sourceforge.net/p/docutils/patches/137/
For PDF via LaTeX PR #2304 (ac7d7b5) implemented wrapping of long code
lines in literal blocks and PR #3340 (8c21abe) extended this to parsed
literals. On this occasion the space was defined as a LaTeX macro,
depending on the used font, and as it allowed some potential uses it was
allowed for the space to obey the stretch and shrink as configured in
the used font. The default is to render using the mono font
(``\ttfamily``), hence a priori the stretchability and shrinkability are
anyhow zero. Non-zero stretch/shrink was left as a theoretical
possibility for special purposes; but although it may make sense to use
a "variable mono" for non-Python code, it is certainly not adequate for
things like verbatim grid tables...
The problem is that XeTeX does not set the TeX font parameters to zero
for OpenType fonts of Mono type, as is discussed there:
http://tug.org/pipermail/xetex/2017-January/026956.html
and in particular applies to the Latin Modern OpenType font, which is
the default when loading fontspec package. Due to this problem there was
a LaTeX kernel patch update late January 2017 to forcefully set the
corresponding TeX font parameters to zero (indeed since 2017/01/01
release LaTeX uses OpenType fonts by default under XeTeX/LuaTeX
engines.) But this is only a specific kludge for handling the Latin
Modern Mono font. Other OpenType fonts of MonoSpace type may still show
the XeTeX issue.
To make things simple, this commit simply avoids ascribing to the space
the font stretch or shrink as set in the TeX font parameters. This will
alleviate problems with Monospace fonts with XeTeX and avoir user
reports that their literal-blocks are all wrong.
Existing documents are not affected. The possibility to use a variable
space mono font had not been documented.
