Latex error "too deeply nested" only for #+INCLUDE statements

Latex error "too deeply nested" only for #+INCLUDE statements

[Percival du Chat Gris]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

Good day,

I've tried googling, reading faqs and the like, and have come up empty.

If I have a number of stub files, with the information in them that I want
to pull into multiple documents, and I #+INCLUDE them in a file, I get the
latex "too deeply nested" error.  If, however, I simply insert the files
into the buffer, then they will create the PDF via latex export without a
problem.  Is there something in the #+INCLUDE code that adds a nested layer
such that it becomes problematic for PDF production?  If so, is there a
better route to create PDF files?  I have been using Latex and HTML export
for a while, so I'm not entirely familiar with any other options that might
produce PDF files as cleanly.  While I can (and have) written a script to
pull all the pieces together into one large file, there should be an easier
way.

Thank you,
Percival

[-- Attachment #2: Type: text/html, Size: 902 bytes --]

Re: Latex error "too deeply nested" only for #+INCLUDE statements

[Sebastien Vauban]

Hello Percival,

Percival du Chat Gris wrote:
> I've tried googling, reading faqs and the like, and have come up empty.
>
> If I have a number of stub files, with the information in them that I want
> to pull into multiple documents, and I #+INCLUDE them in a file, I get the
> latex "too deeply nested" error.  If, however, I simply insert the files
> into the buffer, then they will create the PDF via latex export without a
> problem.  Is there something in the #+INCLUDE code that adds a nested layer
> such that it becomes problematic for PDF production?  If so, is there a
> better route to create PDF files?  I have been using Latex and HTML export
> for a while, so I'm not entirely familiar with any other options that might
> produce PDF files as cleanly.  While I can (and have) written a script to
> pull all the pieces together into one large file, there should be an easier
> way.

It makes me think at lists of levels 5 or more. Are you including your source
files at deep levels?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Latex error "too deeply nested" only for #+INCLUDE statements

[Nick Dokos]

[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]

Percival du Chat Gris <percyhaven@gmail.com> wrote:

> Good day,
> 
> I've tried googling, reading faqs and the like, and have come up empty.
> 
> If I have a number of stub files, with the information in them that I want to pull into multiple
> documents, and I #+INCLUDE them in a file, I get the latex "too deeply nested" error. 

Please provide details and, if possible, a minimal example.

Who produces this error? What is the exact output? What version of org/emacs?
Are you using the new exporter or the old exporter?

If the error is produced by latex, export to latex and look at the .tex
file.  If the error is produced by org, it
would help to have a backtrace.

I attach a tarball with a simple example where the new exporter with

Org-mode version 7.9.2 (release_7.9.2-432-g545166 @ /home/nick/elisp/org-mode/lisp/)
GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-09-21

does the right thing.

Nick

> If, however,
> I simply insert the files into the buffer, then they will create the PDF via latex export without a
> problem.  Is there something in the #+INCLUDE code that adds a nested layer such that it becomes
> problematic for PDF production?  If so, is there a better route to create PDF files?  I have been
> using Latex and HTML export for a while, so I'm not entirely familiar with any other options that
> might produce PDF files as cleanly.  While I can (and have) written a script to pull all the pieces
> together into one large file, there should be an easier way.
> 


[-- Attachment #2: doc.org and three included files --]
[-- Type: application/x-gzip, Size: 537 bytes --]

Re: Latex error "too deeply nested" only for #+INCLUDE statements

[Percival du Chat Gris]

[-- Attachment #1: Type: text/plain, Size: 4811 bytes --]

Good afternoon,

On Mon, Oct 15, 2012 at 2:24 PM, Nick Dokos <nicholas.dokos@hp.com> wrote:

> Percival du Chat Gris <percyhaven@gmail.com> wrote:
>
> > Good day,
> >
> > I've tried googling, reading faqs and the like, and have come up empty.
> >
> > If I have a number of stub files, with the information in them that I
> want to pull into multiple
> > documents, and I #+INCLUDE them in a file, I get the latex "too deeply
> nested" error.
>
> Please provide details and, if possible, a minimal example.
>

Sorry about that, I was hoping, perhaps, it was a known problem, and I was
just failing to find the FAQ.


> Who produces this error?


The LaTeX -> PDF conversion that happens after I do C-c C-e p

from the Export.log file
[...]

LaTeX Font Info:    Font shape `T1/fvs/bx/n' in size <14.4> not available
(Font)              Font shape `T1/fvs/b/n' tried instead on input line 68.
LaTeX Font Info:    Font shape `T1/fvs/b/n' will be
(Font)              scaled to size 12.9599pt on input line 68.
\tf@toc=\write4
\openout4 = `Export.toc'.

 [2]
LaTeX Font Info:    Font shape `T1/fvs/bx/n' in size <12> not available
(Font)              Font shape `T1/fvs/b/n' tried instead on input line 87.
LaTeX Font Info:    Font shape `T1/fvs/b/n' will be
(Font)              scaled to size 10.79993pt on input line 87.
LaTeX Font Info:    Font shape `TS1/fve/m/n' will be
(Font)              scaled to size 9.85492pt on input line 96.
LaTeX Font Info:    Font shape `T1/fve/bx/n' in size <10.95> not available
(Font)              Font shape `T1/fve/b/n' tried instead on input line 103.
LaTeX Font Info:    Font shape `T1/fve/b/n' will be
(Font)              scaled to size 9.85492pt on input line 103.
 [1]

! LaTeX Error: Too deeply nested.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

l.236 \begin{itemize}

? H
You're in trouble here.  Try typing  <return>  to proceed.
If that doesn't work, type  X <return>  to quit.
?
[2]

! LaTeX Error: Too deeply nested.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...

l.268 \begin{itemize}

?

! LaTeX Error: Too deeply nested.

And that repeats over and over again.



> What is the exact output?


Unfortunately there isn't any output.


> What version of org/emacs?
>

Org-mode:  Version        : 7.9.2-1
Emacs: Version        : 23.3.a-3

Are you using the new exporter or the old exporter?
>

How would I be able to tell?


>
> If the error is produced by latex, export to latex and look at the .tex
> file.  If the error is produced by org, it
> would help to have a backtrace.
>

Well ... I presume the error is produced by Latex, because I can get the
same thing if I run LaTex Export.tex, but if I replace all the #+INCLUDE
references with the contents of the files themselves, in the .org file, it
works, so I think it's an .org problem, in producing the .tex files, not
(necessarily) a LaTex problem.

I think (not being an expert) it seems that, with the stub-based file
(Export.tex), the single * in each of the #+INCLUDEed files becomes a
subsection, as opposed to an actual section (as it did in Export-1.tex),
since a section of the diff file between the .tex files produced looks
something like:

diff Export.tex Export-1.tex
[...]
1144a1132,1133
> \subsection{Dynamic Interactions}
> \label{sec-7-5}
1146,1147d1134
< \item Dynamic Interactions\\
< \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5}%
1154c1141
< \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-1}%
---
> \label{sec-7-5-1}%
1157c1144
< \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-2}%
---
> \label{sec-7-5-2}%
1160c1147
< \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-3}%
---
> \label{sec-7-5-3}%
1163c1150
< \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-4}%
---
> \label{sec-7-5-4}%
1166c1153
[...]

> I attach a tarball with a simple example where the new exporter with
>
> Org-mode version 7.9.2 (release_7.9.2-432-g545166 @
> /home/nick/elisp/org-mode/lisp/)
> GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of
> 2012-09-21
>

Thank you, I will try it, and see if that will clear up the issue.


>
> does the right thing.
>
> Nick
>
> > If, however,
> > I simply insert the files into the buffer, then they will create the PDF
> via latex export without a
> > problem.  Is there something in the #+INCLUDE code that adds a nested
> layer such that it becomes
> > problematic for PDF production?  If so, is there a better route to
> create PDF files?  I have been
> > using Latex and HTML export for a while, so I'm not entirely familiar
> with any other options that
> > might produce PDF files as cleanly.  While I can (and have) written a
> script to pull all the pieces
> > together into one large file, there should be an easier way.
> >
>
>

[-- Attachment #2: Type: text/html, Size: 7111 bytes --]

Re: Latex error "too deeply nested" only for #+INCLUDE statements

[Nick Dokos]

Percival du Chat Gris <percyhaven@gmail.com> wrote:

> 
> ! LaTeX Error: Too deeply nested.
> 
> And that repeats over and over again.
> 

OK - Seb probably got it right then: if you have too many (too many = 5)
nested itemize environments, latex complains as above.

>  
> 
>     What is the exact output?
> 
> Unfortunately there isn't any output.

I meant the error output as you showed above. 

> 
>     What version of org/emacs?
> 
> Org-mode:  Version        : 7.9.2-1
> Emacs: Version        : 23.3.a-3
> 

OK.

>     Are you using the new exporter or the old exporter?
> 
> How would I be able to tell?

C-c C-e p invokes the old exporter. To use the new exporter,
see for example this thread:

http://thread.gmane.org/gmane.emacs.orgmode/60236/focus=61566


>     If the error is produced by latex, export to latex and look at the .tex
>     file.  If the error is produced by org, it
>     would help to have a backtrace.
> 
> Well ... I presume the error is produced by Latex, because I can get the same thing if I run LaTex Export.tex, but if I replace all the
> #+INCLUDE references with the contents of the files themselves, in the .org file, it works, so I think it's an .org problem, in
> producing the .tex files, not (necessarily) a LaTex problem.
> 

I would strip down the contents of the files to just the headers: it's the
structure that matters here, not the details. Then I would ask the exporter
to export to latex and compare the tex files by opening them in two side-by-side
windows in emacs: the differences should be telling.


> I think (not being an expert) it seems that, with the stub-based file (Export.tex), the single * in each of the #+INCLUDEed files
> becomes a subsection, as opposed to an actual section (as it did in Export-1.tex), since a section of the diff file between the .tex
> files produced looks something like:
> 
> diff Export.tex Export-1.tex
> [...]
> 1144a1132,1133
> > \subsection{Dynamic Interactions}
> > \label{sec-7-5}
> 1146,1147d1134
> < \item Dynamic Interactions\\
> < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5}%

The differences *are* telling: In one case, you have a subsection at
level 2, in the other an item at level (almost) infinity :-)


> 1154c1141
> < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-1}%
> ---
> > \label{sec-7-5-1}%
> 1157c1144
> < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-2}%
> ---
> > \label{sec-7-5-2}%
> 1160c1147
> < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-3}%
> ---
> > \label{sec-7-5-3}%
> 1163c1150
> < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-4}%
> ---
> > \label{sec-7-5-4}%
> 1166c1153
> [...]
> 
>     I attach a tarball with a simple example where the new exporter with
>    
>     Org-mode version 7.9.2 (release_7.9.2-432-g545166 @ /home/nick/elisp/org-mode/lisp/)
>     GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-09-21
> 
> Thank you, I will try it, and see if that will clear up the issue.
>  
> 
>     does the right thing.

BTW, I think the old exporter mishandles my simple example (and slightly
modified variants) in various ways.  I would recommend that you try the
new exporter at this point.

Nick