Hi all,

At last I managed to figure out the roots of this wierd symptom.  And it
also turned out that bug#20773 has the same origin, so I'm cc'ing to
20773@debbugs.gnu.org, too.

>>>>> Ikumi Keita <ikumi@ikumi.que.jp> writes:

> Preview-latex fails if the length of the file name or the amount of the
> document is sufficiently large.

> [How to reproduce]
> (0) Enable preview-latex.
> (1) Save the attached file "preview-section-test.tex" in /tmp/ and open it.
> (2) Type C-c C-p C-d and answer with "n" to "Cache preamble?" question.
> (3) The ghostscript process hangs with error message "No bounding box"
> and the process buffer is displayed.  Only the partial "\section{xxx}"
> are covered by the expected images and rests remains icons of road
> construction sign.  See the attached screenshot.

> It is really strage to me that the length of the file name seems to be
> related to this symptom.  If the *same* file is saved under the file
> name "xxxxxxxxxxxxxxxxxx.tex" (18 x's), no errors occur and all
> "\section{xxx}" are covered by suitable images after C-c C-p C-d.  But
> the symptom occurs again if the file name is "xxxxxxxxxxxxxxxxxxx.tex"
> (19 x's).

[Analysis]
When LaTeX runs it always outputs a lot of messages to console and log
file, and it inserts line breaks in the 80th column when it outputs long
messages.  Here are some samples:
----------------------------------------------------------------------
./preview-section-test.tex:10: Preview: Snippet 4 ended.(655359+183500x22609920
).
----------------------------------------------------------------------
./xxxxxxxxxxxxxxxxxxxABC.tex:8: Preview: Snippet 3 ended.(655359+183500x2260992
0).
----------------------------------------------------------------------
./formalism_atranslation.tex:1: Preview: Snippet 1 ended.(541848+14544x15728640
).
----------------------------------------------------------------------

It is this line break that makes preview-latex to fail.  The part which
parses the LaTeX messages in `preview-parse-messages' of preview.el is:
----------------------------------------------------------------------
		(if (looking-at "\
\\(?:Preview\\|Package Preview Error\\): Snippet \\([---0-9]+\\) \\(started\\|ended\\(\
\\.? *(\\([---0-9]+\\)\\+\\([---0-9]+\\)x\\([---0-9]+\\))\\)?\\)\\.")
		    (progn
... (snip) ...
		      (setq snippet (string-to-number (match-string 1))
			    box (unless
				    (string= (match-string 2) "started")
				  (if (match-string 4)
				      (mapcar #'(lambda (x)
						  (* (preview-get-magnification)
						     (string-to-number x)))
					      (list
					       (match-string 4)
					       (match-string 5)
					       (match-string 6)))
				    t))
----------------------------------------------------------------------
Comparing the regexp and the examples quoted above, you can tell that
the regexp fails to pick up the numbers embedded in the LaTeX messages
such as "655359+183500x22609920" due to the extra line break.  This the
reason that preview-latex cannot provide the necessary information to
ghostscript and complains that "No bounding box".

[Solution]
Thanks to
https://tex.stackexchange.com/questions/52988/avoid-linebreaks-in-latex-console-log-output
, I learned that we can (effectively) inhibit to insert extra line
breaks by setting environment variable max_print_line to sufficiently
large value.

I confirmed that the attached patch solves the both bug#20773 and
bug#27088.  I will install this fix in a week or so.  According to the
article above, MikTeX also understands max_print_line, so I think this
fix is effective regardless of TeX distribution.  As always, any
comments and suggestions are welcome.

And I also expect that the same prescription can be applied to solve
reliably similar problem handled in `TeX-format-filter' at the part
"Remove line breaks at columns 79 and 80" comment.  We can get rid of
heuristic logic used there.

Regards,
Ikumi Keita