[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27088: 11.90; preview-latex fails for file names of certain length

From: Ikumi Keita
Subject: bug#27088: 11.90; preview-latex fails for file names of certain length
Date: Fri, 22 Sep 2017 15:07:15 +0900

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
address@hidden, too.

>>>>> Ikumi Keita <address@hidden> 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).

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
./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]+\\) 
\\.? *(\\([---0-9]+\\)\\+\\([---0-9]+\\)x\\([---0-9]+\\))\\)?\\)\\.")
... (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)))
                                               (match-string 4)
                                               (match-string 5)
                                               (match-string 6)))
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".

Thanks to
, 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.

Ikumi Keita

Attachment: preview-latex-fix
Description: set max_print_line to 1000

reply via email to

[Prev in Thread] Current Thread [Next in Thread]