[tex-live] Disappearing text

[jfbu]

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