Systemcall::startscript returns the exit code of the LaTeX command
that is run, but the return value was not being checked by
LaTeX::run. Instead, we relied on parsing log files. However, this
parsing is not perfect.
The return value is now checked and if the exit code of the command
is non-zero, an enum value is added to the return and the user is
notified of the error.
At a higher level, if the LaTeX command returns a non-zero exit code,
in the GUI a message such as
"Error while exporting format: PDF (LuaTeX)" will be given instead of
"Successful preview of format: PDF (LuaTeX)".
When run on the commandline, lyx -e lualatex example.lyx
will give "Error: LaTeX failed" and a non-zero exit code
where before it gave a zero exit code.
A real example of the bug this commit fixes is LyX's (as of this commit)
ACM-sigplan.lyx template.
Before this commit:
$ lyx -e pdf2 ACM-sigplan.lyx
[...snip...]
support/Systemcall.cpp (288): Systemcall: 'pdflatex "ACM-sigplan.tex"'
finished with exit code 1
$ echo $?
0
Starting with this commit:
$ mylyx master -e pdf2 ACM-sigplan.lyx
support/Systemcall.cpp (288): Systemcall: 'pdflatex "ACM-sigplan.tex"'
finished with exit code 1
Error: LaTeX failed
----------------------------------------
LaTeX did not run successfully. The command that was run exited with
error.
$ echo $?
1
This was disabled in 2009 in bea0925f but it is now safe.
From Richard:
"I am pretty sure that all the work that Peter Kümmel did with the
InGuiThread classes dealt with this issue."
This commit solves two issues:
(1) A PDF from a previous run could have been the result of a command
that exited with error (e.g. sometimes pdflatex still produces a PDF if
it exits with error). If the "View" button were clicked a second time
without changing the .lyx file, then the checksum of the .tex file would
not have changed so LyX would show the PDF (which was created from the
first run that exited with error), and this time LyX would not report
the error (because the parsing of the logs only happens when the .tex
file is compiled).
(2) A myfile.tex that results in no output does not yield a myfile.pdf.
Thus, Any myfile.pdf in the temporary directory will not be overwritten.
Before this commit, the following scenario was possible: LyX runs
pdflatex which processes myfile.tex and no error is given so LyX opens
myfile.pdf. However, it could have been the scenario that pdflatex did
not exit with error and did not create myfile.pdf, in which case
whichever myfile.pdf is being shown is not correct. To see this bug in
action, start a new document, type "abc", view the PDF, delete "abc",
view the PDF (this correctly gives an error that empty output was
created), view the PDF again (this does not give an error because the
checksum has not changed). The PDF shown will contain "abc".
Note that the above also applies to DVI files and that the fix is
general.
- Use paths, not fonts. Have a look at the sqrt icon in the image attached
here http://thread.gmane.org/gmane.editors.lyx.devel/154179/focus=154183
to see what may happen when a font is not present on a given system.
- Make uniform the height of the parentheses.
- Move a couple of icons to the oxygen subdir (I was not sure it was Ok
replacing them. If yes, they can be simply deleted).
Using fraction of points is a reasonable way to avoid warnings with fussy compilers.
Moreover, this fixes the output of PHRASE_LATEX2E to use the proper form \LaTeXe.
The file format still uses the questionnable form \\LaTeX2e.
The problem came from the fact that Qt associates Interlingua to locale C.
Now, we do not rely anymore on the Qt locale to set the language. I suspect that the problem will still exist if the system locale is ia_IA.
Fixes bug #9267.
The old scheme was:
* multiple insertions are undone by groups of 20
* multiple deletions are undone in one big block
The new scheme is to stop merging undo elements after 2 seconds of elapsed time.
Moreover, the merging of undo elements stops when the cursor has moved. Potentially, this could allow to remove many of the finishUndo() calls.
Fixes bug #9204.
It is better to introduce a dummy blank dir in TEXINPUTS rather than
appending a blank at the end. Even if I have checked that this is not
a problem with MikTeX, some other engine (maybe texlive, but I cannot
check) could not ignore this space and take it as the name of a dir.
In this case, TEXINPUTS would not end with an empty element and the
standard search path would not be inserted there.
