This is a (continuation and) re-work of #8769 (e6bf9145dc)
I have reintegrated option handling and most package loading into the
original file sphinx.sty and reorganized completely the filenames of
secondary style files.
sphinx.sty had become too big and first #8769 now this more definitive
refactoring is necessary to clarify structure, dependencies, and ease up
future maintenance.
Unfortunately this means a lot of moving around hunks of latex code with
some alterations. I tried to carefully check everything is defined in
right order (as LaTeX being a macro expansion language, often one can
manipulate things before them being defined, nevertheless I checked
things are done in order).
Only simple thing is to review is that I added missing EOLs at last
lines of the extracted files...
The {\py@NormalColor} was wrong it should have been [\py@NormalColor].
It got executed by latex during document preamble and never got
integrated as part of the heading...
Closes: #8788
This is cosmetic as the blank line starting varwidth environment used
for merged table cells in latex output changed nothing to PDF.
Nevertheless I extended a unit test to have a multi-paragraph merged
cell using varwidth. What is important is that \sphinxAtStartPar line
itself is never followed by blank line.
Else, a non-hyphenatable long word as first word in a narrow column in a
longtable/tabular (with column type e.g. p{1cm} from tabularcolumns
directive) gets shifted downwards vertically in PDF output.
Memo:
1. I did not find other cases where such a vertical shift may occur (I
tried with deeply nested lists and artificial words such as 'A'*32) with
LaTeX mark-up produced by Sphinx,
2. but with the support of hlist directive via PR #8779 using multicols
environment, there is again this situation of downwards shift of
non-hyphenatable long first words. But it occurs whether or not
\sphinxAtStartPar is used (\nobreak does not modify this).
Instead of using application members to access the builder and trigger a
build, use the main app interface.
It ensures the builder setup is realistic, builder cleanups are executed
and the build-finished events are emitted.
Compare doc/conf.py after merge at c9480f994 to what it was at 2ee033838.
It loses the modification from #8716 (merged at 38c614347) and thus
reverts doc/conf.py to former font config using mathpazo.
The latex macros from sphinx.sty were already partitioned into
successive sections. The file sphinx.sty is split into multiple
files in concordance with this pre-existing sectioning.
The files are loaded via \input. File extension is .sty not .tex
to not confuse the Makefile.
This makes .idx files contain \spxentry{..} with no space, whether or
not the \index latex command is encountered in main text or e.g. in a
label of a description list (like happens for terms from a glossary).
Xindy does not care about spaces, but Makeindex doesn't merge entries
whose typesetting is to be done via \spxentry{..} or \spxentry {..}.
An alternative work-around would be for Sphinx LaTeX writer to use some
wrapper, say, \sphinxindexwrap, only to fetch the argument and force TeX
tokenization and then hand over it to \index command.
But we choose to let \spxentry expand to its own name, with no trailing
space (it gets its final definition only from the python.ist file in
case of Makeindex).
In case both the :index: role and the glossary are on same page, Xindy
and Makeindex behave differently: the former gives only once the page
number, the latter issues them twice (but the indexed term only once),
and there is warning in the .ilg file. But this is unrelated and we
can't do here anything about it.
