Dependency checking can break when file name in latex log is split over several rows

[chr]

Dependency checking can break when file name in latex log is split over several rows.

Christian> LyX scans the LaTeX log file to determine what files it
Christian> depends on, and the problem here is that since the line is
Christian> split, it doens't get a proper file name?

(I will add more comments once I see that this got committed)

[chr]

Here's a cryptic test case where Lyx's dependancy checking fails.
I've spent two hours reducing it from my thesis, and here's the minimal
recipy for producing the problem.

First of all, the files can be found here:

​http://www.md.kth.se/~chr/lyx/bugs/depend/

and you should copy them to a local directory. Furthermore, the files:

outline.inc
stdlayouts.inc

should be copied to .lyx/layouts/ or you can manually incorporate the
style ContentNotes in whatever way you feel like. I haven't been able to
produce the error without that style.

Now do this command from wherever you copied the files to:

lyx -dbg depend depend.lyx

and do:

File->Export->Postscript

which ought to export the file: depend.ps

Open depend.ps in some postscript viewer to look at the first page.

Then edit 'preamble.tex' and modify the command \someText{} in a way you
like. Now do:

File->Export->Postcript

again and study depend.ps. Notice that it has not changed, even though you
have changed preamble.tex.

[levon]

I'm sure we had some dep bugs listed but I can't find them yet.

[leeming]

Christian, the mentioned files no longer exist at the advertised location. Can
you attach a log file demonstrating the problem instead.

[chr]

*sigh*.... the files are seriously gone. If it's important to create a test case
I might be able to redo it from scratch (according to the notes I reduced my
thesis to produce the test case). Tomorrow (well, today), I'll compile my thesis
(that'll be an interesting experiment) and see if the log file contains anything
interesting.

[chr]

Log file illustrating how the file name for preamble.tex is split over two lines

[chr]

Ok, I've attached the log-file. The interesting lines look like this:

---

Excluding comment 'comment') Special comment 'contentCmt' (/afs/md.kth.se/md/ho
me/damek/chr/thesis/docpreamble.tex
<---------

where the long path to .../docpreamble.tex is split over two lines. Let me
know if I need to recreate the test files.

[Georg Baum]

The problem is that latex tries to be clever and splits strings to fit in some
"terminal". This can of course break not only long file names, but also the
error message extraction. You can change the "width" of the terminal on tetex
with texmf.cnf:

% It's probably inadvisable to change these. At any rate, we must have:
% 45 < error_line < 255;
% 30 < half_error_line < error_line - 15;
% 60 <= max_print_line;
% These apply to Metafont and MetaPost as well.
error_line = 79
half_error_line = 50
max_print_line = 79

Unfortunately I don't know of any way to disable this completely or at least
change this width protably.

[lasgouttes]

I think it was left like that because otherwise the TRIP test would fail
and the result would not be TeX anymore.

However, when we know we are parsing file name, we can decide to continue if
the name we got up to there does not seem complete.

[lasgouttes]

Enrico, I do not understand this patch. Could you describe how endChar is used?

[forenr@…]

The logic of the patch is to catenate two consecutive lines before applying
the regexps. So, a path could be spotted twice. To avoid this, when we know
that either (1) for sure a path isn't split across lines or (2) for sure it is,
we slide our logical 2-line window further down.

(1) A path isn't for sure split across line1 and line2 if

a) the previous line1 was empty;
b) the current line2 begins with "File:", "(Font)", ...;
c) the last char on current line2 is ')'.

(2) A path is for sure split across lines if the last char is either '\' or

'/', where these chars are path separators in some OS.

In case (1.b) we have already spotted the path on the previous iteration.
In cases (1.a) and (2) we will spot the path on next iteration.
Case (1.c) mostly occurs in cases like this one:

(C:\texmf\tex\latex\base\size10.clo
File: size10.clo 2004/02/16 v1.4f Standard LaTeX file (size option)
)

so we would unnecessarily check for "size option". There could be a flaw
in this last case (1.c), e.g.

(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
yyyyyyyyyyyy)

would not be spotted, but I've never seen this as, after loading, a package
emits some messages, so we would have:

(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
yyyyyyyyyyyy
messages here
)

All in all, I think that (1.c) could be nuked.

Sometimes we will spot twice the same path. On some trial I did, this never
occurred in more than 3% of cases. So, I said that it was occurring in
less than 5% of cases.

Please, tell me if you need further explanations or if you think that my
logic is flawed ;-)

I admit that it may well be so for (1.c), so take it away, or even get rid
of endchar altogether. This means only taking into account (1.a) and (1.b),
and nuking (1.c) and (2). In case (2) a directory may be spotted, but I
have already accounted for it elsewhere (this is important as it leads
to a crash in cygwin).

[lasgouttes]

I applied a patch that avoids directory in deptable, thus preventing
cygwin crash.

[Juergen Spitzmueller]

fixed in trunk (r17240).
Could be backported to 1.4.5, since it fixes some rather annoying bugs.

[forenr@…]

proposed patch

[Juergen Spitzmueller]

backport to 1.4

[lasgouttes]

This is a rather big patch... How confident are you that it is not
worse than what we had?

[Juergen Spitzmueller]

I'm pretty confident that it is much better than what we had.
However, I have it in my real-work-version now, and I can give it some more
testing, before we shove it in (it also will get testing with trunk and
1.5beta1).

[lasgouttes]

Juergen, what is the current status? I seem to remember there have been other
patches. Are they worth considering?

[Juergen Spitzmueller]

I'd say it's too tricky for 1.4. The changes entailed some severe problems on
Windows. They are now fixed in trunk, afaics, but backporting would have to be
done very carefully (and I don't have the time for that ATM).

[lasgouttes]

OK.

[forenr@…]

I think that the patch in comment 9 would be good enough for 1.4.

[Richard Heck]

New stable series is 1.5.x.