# [tex-live] Disappearing text

jfbu jfbu at free.fr
Sat Dec 21 18:58:50 CET 2013

Le 21 déc. 2013 à 18:30, jfbu <jfbu at free.fr> a écrit :

>
> Le 21 déc. 2013 à 18:26, jfbu <jfbu at free.fr> a écrit :
>
>>
>> Le 21 déc. 2013 à 15:59, Artur Zaroda <zaroda at mimuw.edu.pl> a écrit :
>>
>>>
>>> This happens on Ubuntu 12.04 with TexLive 2009 and on Windows with
>>> fresh installation of TexLive 2013.
>>>
>>> For a do-it-yourself minimal working example, in the following:
>>>
>>> \documentclass{article}
>>> \usepackage{comment}
>>> \includecomment{a}
>>> \includecomment{b}
>>> \begin{document}
>>> \begin{a}
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>> \begin{b}
>>> \end{b}
>>> 0123456789 0123456789 0123456789 0123456789 0123456789
>>> \end{a}
>>> \end{document}
>>>
>>> repeat the line with 62 '%' characters exactly 64 times.
>>>
>>> The resulting document is shortened to:
>>>
>>> 0123456789 0123456789 0123456789 0123456789 01
>>>
>>> Artur Zaroda
>>
>> I confirm this with TL2013  on Mac OS X.
>>
>> This is perhaps more a comment.sty issue than a TeX Live, although
>> the detailed explanation (which I am curious to learn) might depend on
>> TeX Live (or rather on the details of TeX’s dealings with input/output of files).
>>
>> When the comment package finds a comment environment
>> it writes its contents to a file called comment.cut, and at the end of the environment
>> decides to include back the file or not (*)
>>
>> (*) I don’t know why this decision is done only after the environment
>> contents have been output verbatim to the comment.cut file as it could
>> have been identified from comment.sty that ‘a’ was not to be commented out
>> after all
>>
>> So here we have ‘a’ and then an \input
>> is done which reads 64 lines of 62 percent signs, then \begin{b} and this starts
>> again the process as environment ‘b’ was also declared in the preamble to require
>> comment.sty interference
>>
>> When a file is opened up for write operations its contents
>> are instantly erased, so comment.cut which already served for ‘a’ is erased
>> for ‘b’ to write its contents (here nothing) and then again input. Somehow
>> we are left with a partial version of the first input: precisely
>> 4096 characters (including the EOL’s).
>>
>> Possibly, when TeX encounters \input file.tex it
>> proceeds by blocks of 4096 (as no smaller power of 2 seems to give the same effect
>> in my brief testing just now
>> and this might be file system dependent)
>> and loads from disk the next 4096 characters only when needed. Thus it loaded
>> everything up to and including 01, then the file was erased by the process described
>> above
>>
>> this is a guess
>>
>> best regards
>>
>> Jean-Francois
>
> my explanations will need elaboration as it seems that the fact that \begin{b}
> is followed by \end{b} immediately plays a rôle. (if we add something inside
> like an X things appear to work normally)
>
> curious to know the complete explanation
> best
> Jean-François
>

Actually also a non empty ‘b’ environment can show the phenomenon as long as
it comes first

\documentclass{article}
\usepackage{comment}
\includecomment{a}
\includecomment{b}
\begin{document}
\begin{a}
\begin{b}
X
\end{b}
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\\
— <exactly 62 lines identical to the one above: hence 10+2+8+63*64=4052 chars> —
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaStopsHereXXXXXXXX
\end{a}
\end{document}

best
Jean-François