Latex output "too deeply nested"

[shimizukawa]

If Sphinx's LaTeX output gets too deeply-nested, I get the following error:

[13] [14]
Chapter 4.
[15]

! LaTeX Error: Too deeply nested.

I've found an item on the Docutils to-do list:
http://docutils.sourceforge.net/docs/dev/todo.html
indicating that this is something they're aware of, but have not yet fixed, but I'm wondering if this is something Sphinx can work around in the mean time.

In particular, the LaTeX "enumitem" package:
http://www.tex.ac.uk/CTAN/macros/latex/contrib/enumitem/
has recently added support for list environments of any depth. I was wondering if Sphinx could make use of this package to allow nesting of chapters and code blocks to a higher number of levels, because when you start using code blocks with several levels of indentation, the nesting gets deep quickly, and standard LaTeX maxes out somewhere around 5-6 levels.

Could something like this work?

---

• Bitbucket: https://bitbucket.org/birkenfeld/sphinx/issue/777
• Originally reported by: tonycpsu
• Originally created at: 2011-10-01T22:35:55.188

[shimizukawa]

From Anonymous on 2011-12-29 08:26:07+00:00

You will find really 100s of exercises available that will help you gain muscles and this can be done by doing bench presses, dead lifts or by utilizing hand weights. These workouts are the very best if this involves firming and strengthening the muscles.
nfl shop http://www.nfl-shops.com/
Cheap NFL Jerseys http://www.nfl-shops.com/
NFL Jerseys http://www.nfl-shops.com/
nfl shop jerseys http://www.nfl-shops.com/
http://www.nfl-shops.com/san-francisco-49ers-jerseys-c-76.html

[shimizukawa]

From kaiwa on 2012-07-18 12:31:15+00:00

+1 for using enumitem package

[shimizukawa]

From Martin Ortbauer on 2012-09-05 12:36:10+00:00

I encountered the same problem. did you or somebody already implement that? or did you find some workaround?
thanks

[shimizukawa]

From tonycpsu on 2012-09-05 14:49:20+00:00

I don't know of any workarounds other than lowering the number of nesting levels in my documents. I would love it if Sphinx could switch to using enumitem to get rid of this limit.

[shimizukawa]

From Nicolas M. Thiéry on 2013-08-29 15:12:46+00:00

+1 to using enumitem as well. We stumbled on this problem in Sage [1]:

Probably a bit more work will actually be needed, for there seems to be a bug in the @listdepth incrementation/decrementation with Sphinx+enumitem: for a file which is not soo deeply nested (10 maybe?) but quite long, we actually need to use \setlistdepth{264} !

Cheers,
Nicolas

[1] http://trac.sagemath.org/ticket/9107#comment:42

[shimizukawa]

From Nicolas M. Thiéry on 2014-06-13 08:36:59+00:00

I got annoyed because we now need to use \setlistdepth{2000}, so the problem was just going to become worst and worst with time. So I investigated a bit further, and found out that if we replace list by trivlist in the customized Verbatim defined by sphinx.sty, then our documenation compiles smoothly, without even using enumitem.

To everyone here: does this fix your own compilation errors?

To the sphinx devs: does this seem like a sensible change to do to sphinx.sty?

[shimizukawa]

From Nicolas M. Thiéry on 2014-06-13 09:16:52+00:00

I proposed a pull request for this on: https://bitbucket.org/birkenfeld/sphinx/pull-request/250/

[nthiery]

Ping? Does using trivlist sound reasonable?

[kiwifb]

Resurrecting the discussion. Using trivlist sounds ok to me. Looking at the doc that would also means that some of the lengths are set to 0 automatically so a few (but not all) \setlength statements could be removed.

[jfbu]

yes using trivlist is definitely feasible, avoids the check for nesting depth done by list and if needed (I have not looked closerly) we can always add some of the things done by list and not by trivlist either at begin or end. I can work on this tomorrow.

[jfbu]

Initially I thought from comment by @kiwifb the issue was with Verbatim, and I self-assigned to me. I fixed that but this only spares one level of nesting. Reading the whole thread I realized the issue was more general, related to lists. The package enumitem was mentioned, but the simplest would be to remove from LaTeX's \list code the check for depth. Then the above commit would be unneeded. Anyway, @kiwifb can you tell me if PR #2624 solves your issue ?

[kiwifb]

No luck. I am doing a serial build to disentangle things and give you a clean output, that will take a little while.

[kiwifb]

Underfull \hbox (badness 10000) in paragraph at lines 6122--6124
[]\T1/ptm/m/n/10 A first ap-proach is to pass the \T1/pcr/m/n/10 roots \T1/ptm/
m/n/10 and \T1/pcr/m/n/10 children \T1/ptm/m/n/10 func-tions as ar-gu-ments to
[77]

LaTeX Warning: Hyper reference `sage/combinat/backtrack:sage.combinat.backtrack
.SearchForest' on page 78 undefined on input line 6182.

! Missing \endcsname inserted.
<to be read again> 
                   \let 
l.6186 \begin{Verbatim}[commandchars=\\\{\}]

? 
! Emergency stop.
<to be read again> 
                   \let 
l.6186 \begin{Verbatim}[commandchars=\\\{\}]

!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on combinat.log.

I can provide the log if necessary or any other files you may need.

[jfbu]

Thank you for trying PR #2624. Your project has no issue with make latexpdf on 1.4.3?

[jfbu]

well, my question was silly because you surely have earlier reported "too deeply nested". But perhaps there were other issues than the "too deeply nested" one. I don't see how Missing \endcsname inserted can arise from PR #2624, but I will think if I get time.

[kiwifb]

Actually I probably should run a check with pure 1.4.3. That issue as been going on for a long time and I don't know how many people did try runs apart from me at this stage.

[kiwifb]

Well that's interesting same error.

! Missing \endcsname inserted.
<to be read again> 
                   \let 
l.448 \begin{Verbatim}[commandchars=\\\{\}]

? 
! Emergency stop.
<to be read again> 
                   \let 
l.448 \begin{Verbatim}[commandchars=\\\{\}]

So we have moved from the nesting issue. Going with trivlist in sphinx 1.4.1 got things build. Checking with 1.4.3.

[kiwifb]

Same error when replacing list by trivlist in 1.4.3 so it must be something new.

[jfbu]

Thank you for reporting.

• I suppose it fails also with 1.4.2 ? (many latex changes occurred from 1.4.1 to 1.4.2)
• can you do make latex go to build repertory, add a \errorcontextlines10 line near top of latex file, then launch pdflatex manually and report here the first error message with all its context (say about 20 lines)
• ideally if you had a small project exhibiting the issue and which can be made public, I can examine via git bisect the problem

[jnothman]

Getting the same \endcsname and Verbatim issue as @kiwifb trying to build scikit-learn user guide with latexpdf in sphinx 1.4.2 and 1.4.3. I suspect this isn't the small project you're looking for :/

However, the error occurs with Verbatim in a notice environment or a SphinxShadowBox, and goes away when that environment is removed, so it may be simple for you to produce a minimal failing example.

Error context:

! Missing \endcsname inserted.
<to be read again>
                   \let
\@ifnextchar #1#2#3->\let
                          \reserved@d =#1\def \reserved@a {#2}\def \reserved...

\@ifundefined #1->\expandafter \ifx \csname #1
                                              \endcsname \relax \expandafter...

\begin #1->\@ifundefined {#1}
                             {\def \reserved@a {\@latex@error {Environment #...

\\Verbatim ...framed \noindent \begin {\minipage }
                                                  {\linewidth }\fi \MakeFram...
l.226 \begin{Verbatim}[commandchars=\\\{\}]

[jfbu]

ah! sorry to everyone. This should be \begin{minipage} not \begin{\minipage}. This is only a typo, but obviously with big consequences :-(( very sorry about this. I will correct very soon on stable branch.

[jfbu]

I have fixed the sub-issue reported by @jnothman and @kiwifb at d4a9997 (on stable branch). With apologies, bad commit was 68becb1. I will merge the fix also into PR #2624 which is mentioned in the current thread.

[jfbu]

@jnothman @kiwifb sadly there is another issue besides the typo with code-blocks inside warning admonitions. Reported at #2640. Will work on it (it's all my fault as I committed the new code for warning admonitions).

[jfbu]

@kiwifb @jnothman big relief ...

[jfbu]

Reopening because b2be594 only addresses partially the issue. Together with PR #2651 when it will be merged, the situation with code-blocks will be that they are allowed at maximal nesting depth within lists/quotes. With latex defaults if no list package is loaded, this is 6 levels of nesting.

Memo: by default latex allows 4 levels of enumerated lists, 4 levels of labeled lists, and 6 levels total of lists, inclusive of quotes, which also are a list in disguise in latex. Prior to b2be594 code-blocks however could happen only at max depth 4. Now 5, and PR #2651 will make this six. edit now merged into stable at 7fd7d29. Thus now code-blocks will be allowed at maximal depth from document class+list packages.

But this does not lift the "4" max levels of either enumerated or labeled lists.

[jfbu]

I am reopening for the same reason. 4a0b283 only fixes to the extent that code-blocks are now allowed at deepest level, but nothing is changed to LaTeX defaults regarding max nesting of lists and quotes.

[mindw]

got hit by this issue while building sqlalchemy PDF doc. The following worked for me:

\usepackage{enumitem}
\setlistdepth{20}
\renewlist{itemize}{itemize}{20}

% initially, use dots for all levels
\setlist[itemize]{label=$\cdot$}
\setlist[itemize]{labelsep=.5em}

% customize the first 3 levels
\setlist[itemize,1]{label=\textbullet}
\setlist[itemize,2]{label=--}
\setlist[itemize,3]{label=*}

[jfbu]

@mindw

Thanks for the tip. Loading enumitem and using \setlistdepth allows to ease up the cap on maximal depths, but one must also, as you do in your code, \renewlist explicitely the itemize, enumerate and description to reset the cap on listdepth for them.

I wanted to test this and I have an issue, I can't get it to work:

\documentclass{article}

\usepackage{enumitem}
\setlistdepth{10}
\renewlist{itemize}{itemize}{10}
\setlist[itemize]{label=$\cdot$}
\setlist[itemize]{labelsep=.5em}

\setlist[itemize,1]{label=\textbullet}
\setlist[itemize,2]{label=--}
\setlist[itemize,3]{label=*}
\setlist[itemize,4]{label=*}

\begin{document}

%does NOT work! Package enumitem Error: Undefined label. (at level of \item e)

\begin{itemize}
\item a
  \begin{itemize}
  \item b
    \begin{itemize}
    \item c
      \begin{itemize}
      \item d
        \begin{itemize}
        \item e
          \begin{itemize}
          \item f
          \end{itemize}
        \end{itemize}
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{itemize}
\end{document}

Does your document really have 5 or more nested itemize ? or is it simply the maximal nesting depth which goes beyond 6 and is fixed by your set-up ?

This is with enumitem 2011/09/28 v3.5.2. Could you also check in your latex log the version you use (in case my code snippet above does work with your version of enumitem).

[jfbu]

@mindw

I see your code snippet also here. However notice that the accepted answer explicitely sets the label at each level (in the case of enumerate). I checked the enumitem manual and the fact that my code snippet is not working does seem to contradict the manual. This is possibly a bug in package enumitem, or in its documentation. This problem complicates incorporating use of enumitem into Sphinx (additionally to the fact that we should not break people's setup which already use it). Besides enumitem has had some updates after TL2009 which Sphinx currently supports. It appears some of these updates precisely refers to issues with \setlist.

Memo:

• http://tex.stackexchange.com/a/126881/4686
• http://www.texnia.com/enumitem.html

[jfbu]

@mindw

I got it just before posting a bug report to enumitem's author !

Your code should be with

\setlist[itemize]{label=$\cdot$, labelsep=.5em}

and not with

\setlist[itemize]{label=$\cdot$}
\setlist[itemize]{labelsep=.5em}

It appears that the second use of \setlist upsets the first one. I have no idea if this is clear from the enumitem doc. But this does complicate matters for incorporating use of enumuitem in Sphinx.

[jfbu]

PR #3096 addresses this without resorting to package enumitem. Of course enumitem has much to recommend it, but its version in TeXLive 2009 which Sphinx supports was at 2.x, and later it reached 3.5.2, with some important changes. Once Sphinx will support only TeXLive 2013 or later, we can more easily consider using enumitem which had no changes since.