Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Wed, Mar 11, 2015 at 3:17 AM, Kornel Benko kor...@lyx.org wrote:

 Enrico, Georg, Liviu, Kornel: warning/error + PDF

OK, looks like this is the most popular. I implemented the
warning/error + PDF in cd8be655. I applied the patches sent in this
thread with a few minor changes (e.g. I took out the warning because
there is no regression from a user point of view, the PDF is still
shown; I made the fix for removing PDF files on error more general to
allow for DVI files also) at 6343d994 through 0a6120cb.

Please test. There could be an issue with keeping files around (for
previewing even if error). For example, this could cause a problem if
part of our code depends on these files being deleted for detecting
whether there was an error (hopefully we do not do this).

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Wed, Mar 11, 2015 at 3:17 AM, Kornel Benko  wrote:

> Enrico, Georg, Liviu, Kornel: warning/error + PDF

OK, looks like this is the most popular. I implemented the
warning/error + PDF in cd8be655. I applied the patches sent in this
thread with a few minor changes (e.g. I took out the warning because
there is no regression from a user point of view, the PDF is still
shown; I made the fix for removing PDF files on error more general to
allow for DVI files also) at 6343d994 through 0a6120cb.

Please test. There could be an issue with keeping files around (for
previewing even if error). For example, this could cause a problem if
part of our code depends on these files being deleted for detecting
whether there was an error (hopefully we do not do this).

Scott

Re: [patches] Improve error reporting and log parsing

[Kornel Benko]

Am Dienstag, 10. März 2015 um 23:54:10, schrieb Scott Kostyshak 
skost...@lyx.org
 So far I interpret the following opinions:
 
 Enrico, Georg, Liviu: warning/error + PDF
 Helge: Keep the current behavior (error and no PDF)
 
 I do not know if Andrew was supporting a certain behavior or just
 giving his idea of what is currently happening.
 
 Does anyone else have an opinion on this? I view this as a significant
 change so I would like to get a few more opinions before proceeding to
 work on the code. If you have not followed this email thread, the
 question is If LaTeX has errors when compiling but produces a PDF,
 should LyX show that PDF? (currently LyX does not show the PDF).
 
 On a separate note, patches in this thread also address the LaTeX
 parsing problem and the lack of a GUI error reported here a few days
 ago:
 http://tex.stackexchange.com/questions/231655/lyx-cannot-output-to-pdflatex-for-a-specific-file
 
 Scott

Enrico, Georg, Liviu, Kornel: warning/error + PDF

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [patches] Improve error reporting and log parsing

[Kornel Benko]

Am Dienstag, 10. März 2015 um 23:54:10, schrieb Scott Kostyshak 

> So far I interpret the following opinions:
> 
> Enrico, Georg, Liviu: warning/error + PDF
> Helge: Keep the current behavior (error and no PDF)
> 
> I do not know if Andrew was supporting a certain behavior or just
> giving his idea of what is currently happening.
> 
> Does anyone else have an opinion on this? I view this as a significant
> change so I would like to get a few more opinions before proceeding to
> work on the code. If you have not followed this email thread, the
> question is "If LaTeX has errors when compiling but produces a PDF,
> should LyX show that PDF?" (currently LyX does not show the PDF).
> 
> On a separate note, patches in this thread also address the LaTeX
> parsing problem and the lack of a GUI error reported here a few days
> ago:
> http://tex.stackexchange.com/questions/231655/lyx-cannot-output-to-pdflatex-for-a-specific-file
> 
> Scott

Enrico, Georg, Liviu, Kornel: warning/error + PDF

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

So far I interpret the following opinions:

Enrico, Georg, Liviu: warning/error + PDF
Helge: Keep the current behavior (error and no PDF)

I do not know if Andrew was supporting a certain behavior or just
giving his idea of what is currently happening.

Does anyone else have an opinion on this? I view this as a significant
change so I would like to get a few more opinions before proceeding to
work on the code. If you have not followed this email thread, the
question is If LaTeX has errors when compiling but produces a PDF,
should LyX show that PDF? (currently LyX does not show the PDF).

On a separate note, patches in this thread also address the LaTeX
parsing problem and the lack of a GUI error reported here a few days
ago:
http://tex.stackexchange.com/questions/231655/lyx-cannot-output-to-pdflatex-for-a-specific-file

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

So far I interpret the following opinions:

Enrico, Georg, Liviu: warning/error + PDF
Helge: Keep the current behavior (error and no PDF)

I do not know if Andrew was supporting a certain behavior or just
giving his idea of what is currently happening.

Does anyone else have an opinion on this? I view this as a significant
change so I would like to get a few more opinions before proceeding to
work on the code. If you have not followed this email thread, the
question is "If LaTeX has errors when compiling but produces a PDF,
should LyX show that PDF?" (currently LyX does not show the PDF).

On a separate note, patches in this thread also address the LaTeX
parsing problem and the lack of a GUI error reported here a few days
ago:
http://tex.stackexchange.com/questions/231655/lyx-cannot-output-to-pdflatex-for-a-specific-file

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Mon, Mar 2, 2015 at 8:01 AM, Helge Hafting helge.haft...@hist.no wrote:
 In my opinion, the current (released) behaviour is fine. LyX do not bring up
 a PDF when something went wrong. But if you have a viewer open, that viewer
 might decide on its own to reload the changed pdf from disk.

 We should bear in mind that LyX has 2 kinds of user. The simpler ones don't
 know about latex, and LyX hides most of the complexity from them. Of course,
 they rarely use ERT and are not really supposed to get compile errors on
 their documents.
 They might get confused from a failed PDF showing up - especially if it is
 blank or if it seems ok (just a figure missing on page 103, something you
 don't notice casually.)

 The other kind knows latex - perhaps a lot - and do a lot of work in ERT.
 They get compile errors, expect them, and can fix them. So they need to see
 the error message text.  Seeing the half-baked PDF is useful in some cases,
 it can give a good idea of what went wrong in a TIKZ figure for example. So
 these users leave the PDF viewer open, and wouldn't like having to hunt
 through /tmp to look at the problems.

Helge, I just wanted to clarify that the other option is for the PDF
*and* the error to be shown. Your reply made me think that you thought
the other option was to show the PDF and no error.

My apologies if I misinterpreted your reply.

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Mon, Mar 2, 2015 at 8:01 AM, Helge Hafting  wrote:
> In my opinion, the current (released) behaviour is fine. LyX do not bring up
> a PDF when something went wrong. But if you have a viewer open, that viewer
> might decide on its own to reload the changed pdf from disk.
>
> We should bear in mind that LyX has 2 kinds of user. The simpler ones don't
> know about latex, and LyX hides most of the complexity from them. Of course,
> they rarely use ERT and are not really supposed to get compile errors on
> their documents.
> They might get confused from a failed PDF showing up - especially if it is
> blank or if it seems ok (just a figure missing on page 103, something you
> don't notice casually.)
>
> The other kind knows latex - perhaps a lot - and do a lot of work in ERT.
> They get compile errors, expect them, and can fix them. So they need to see
> the error message text.  Seeing the half-baked PDF is useful in some cases,
> it can give a good idea of what went wrong in a TIKZ figure for example. So
> these users leave the PDF viewer open, and wouldn't like having to hunt
> through /tmp to look at the problems.

Helge, I just wanted to clarify that the other option is for the PDF
*and* the error to be shown. Your reply made me think that you thought
the other option was to show the PDF and no error.

My apologies if I misinterpreted your reply.

Scott

Re: [patches] Improve error reporting and log parsing

[Helge Hafting]

Den 27. feb. 2015 22:31, skrev Scott Kostyshak:

On Fri, Feb 27, 2015 at 4:14 PM, aparsloe apars...@clear.net.nz wrote:


I've noticed that although LyX may report LaTeX errors and not display a
pdf, nonetheless one is still produced in the temporary directory and can be
displayed by double clicking. For example, create a math inset, insert an
undefined control sequence, e.g. \blah, and a symbol or two, say xyz, and
compile to pdf. LyX reports an undefined control sequence error and stops
without displaying the pdf, but it *is* created in the temporary directory
and will display a nicely typeset xyz.

Indeed. The question is: *should* LyX show the PDF?

In my opinion, the current (released) behaviour is fine. LyX do not 
bring up a PDF when something went wrong. But if you have a viewer open, 
that viewer might decide on its own to reload the changed pdf from disk.


We should bear in mind that LyX has 2 kinds of user. The simpler ones 
don't know about latex, and LyX hides most of the complexity from them. 
Of course, they rarely use ERT and are not really supposed to get 
compile errors on their documents.
They might get confused from a failed PDF showing up - especially if it 
is blank or if it seems ok (just a figure missing on page 103, something 
you don't notice casually.)


The other kind knows latex - perhaps a lot - and do a lot of work in 
ERT. They get compile errors, expect them, and can fix them. So they 
need to see the error message text.  Seeing the half-baked PDF is useful 
in some cases, it can give a good idea of what went wrong in a TIKZ 
figure for example. So these users leave the PDF viewer open, and 
wouldn't like having to hunt through /tmp to look at the problems.


Helge Hafting

Re: [patches] Improve error reporting and log parsing

[Helge Hafting]

Den 27. feb. 2015 22:31, skrev Scott Kostyshak:

On Fri, Feb 27, 2015 at 4:14 PM, aparsloe  wrote:


I've noticed that although LyX may report LaTeX errors and not display a
pdf, nonetheless one is still produced in the temporary directory and can be
displayed by double clicking. For example, create a math inset, insert an
undefined control sequence, e.g. \blah, and a symbol or two, say xyz, and
compile to pdf. LyX reports an undefined control sequence error and stops
without displaying the pdf, but it *is* created in the temporary directory
and will display a nicely typeset xyz.

Indeed. The question is: *should* LyX show the PDF?

In my opinion, the current (released) behaviour is fine. LyX do not 
bring up a PDF when something went wrong. But if you have a viewer open, 
that viewer might decide on its own to reload the changed pdf from disk.


We should bear in mind that LyX has 2 kinds of user. The simpler ones 
don't know about latex, and LyX hides most of the complexity from them. 
Of course, they rarely use ERT and are not really supposed to get 
compile errors on their documents.
They might get confused from a failed PDF showing up - especially if it 
is blank or if it seems ok (just a figure missing on page 103, something 
you don't notice casually.)


The other kind knows latex - perhaps a lot - and do a lot of work in 
ERT. They get compile errors, expect them, and can fix them. So they 
need to see the error message text.  Seeing the half-baked PDF is useful 
in some cases, it can give a good idea of what went wrong in a TIKZ 
figure for example. So these users leave the PDF viewer open, and 
wouldn't like having to hunt through /tmp to look at the problems.


Helge Hafting

Re: [patches] Improve error reporting and log parsing

[Georg Baum]

Scott Kostyshak wrote:

 On Fri, Feb 27, 2015 at 4:27 PM, Georg Baum
 georg.b...@post.rwth-aachen.de wrote:
 Enrico Forestieri wrote:

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

 This is a good argument actually. Then we should produce a strong
 warning,
 
 Why do you prefer a strong warning versus an error? Do you agree that
 with command line export we should exit with error?

With strong warning I wanted to say that the  message should make it very 
clear that the resulting PDF should not be trusted, even if it looks OK at 
first glance. Whether it is called warning or error is more a matter of 
taste. To me it looks awkward to give an error message and then show the 
result nevertheless, but I have no strong opinion on this.
The command line export should exit with error in this case, otherwise it 
would not be possible to detect that something went wrong. This would also 
be consistent with the TeX compiler itself.

 OK. Does anyone object to showing the PDF if there is an error during
 compilation?

I think this should be consistent for all conversions: If the PDF is shown 
despite of LaTeX errorsv then it should also be shown if another converter 
fails, but produces output, e.g. ps2pdf.


Georg

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Sun, Mar 1, 2015 at 5:08 AM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:
 Scott Kostyshak wrote:

 On Fri, Feb 27, 2015 at 4:27 PM, Georg Baum
 georg.b...@post.rwth-aachen.de wrote:
 Enrico Forestieri wrote:

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

 This is a good argument actually. Then we should produce a strong
 warning,

 Why do you prefer a strong warning versus an error? Do you agree that
 with command line export we should exit with error?

 With strong warning I wanted to say that the  message should make it very
 clear that the resulting PDF should not be trusted, even if it looks OK at
 first glance. Whether it is called warning or error is more a matter of
 taste. To me it looks awkward to give an error message and then show the
 result nevertheless, but I have no strong opinion on this.

I see what you mean. I agree it looks awkward but I think that's the
point. I guess I was preferring an error because on the terminal we
will exit with an error so it seems more consistent. Also, we are
reporting a LaTeX error, not a LaTeX warning, so it seems consistent
from that point of view also.

 The command line export should exit with error in this case, otherwise it
 would not be possible to detect that something went wrong. This would also
 be consistent with the TeX compiler itself.

I agree.

 OK. Does anyone object to showing the PDF if there is an error during
 compilation?

 I think this should be consistent for all conversions: If the PDF is shown
 despite of LaTeX errorsv then it should also be shown if another converter
 fails, but produces output, e.g. ps2pdf.

I agree.

Scott

Re: [patches] Improve error reporting and log parsing

[Georg Baum]

Scott Kostyshak wrote:

> On Fri, Feb 27, 2015 at 4:27 PM, Georg Baum
>  wrote:
>> Enrico Forestieri wrote:
>>
>>> My vote is for a warning and an output produced in any case.
>>> If latex produces an output, that output has to be shown, IMO.
>>> Having the possibility of looking at the output may be of great
>>> help to pinpoint problems.
>>
>> This is a good argument actually. Then we should produce a strong
>> warning,
> 
> Why do you prefer a strong warning versus an error? Do you agree that
> with command line export we should exit with error?

With "strong warning" I wanted to say that the  message should make it very 
clear that the resulting PDF should not be trusted, even if it looks OK at 
first glance. Whether it is called warning or error is more a matter of 
taste. To me it looks awkward to give an error message and then show the 
result nevertheless, but I have no strong opinion on this.
The command line export should exit with error in this case, otherwise it 
would not be possible to detect that something went wrong. This would also 
be consistent with the TeX compiler itself.

> OK. Does anyone object to showing the PDF if there is an error during
> compilation?

I think this should be consistent for all conversions: If the PDF is shown 
despite of LaTeX errorsv then it should also be shown if another converter 
fails, but produces output, e.g. ps2pdf.


Georg

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Sun, Mar 1, 2015 at 5:08 AM, Georg Baum
 wrote:
> Scott Kostyshak wrote:
>
>> On Fri, Feb 27, 2015 at 4:27 PM, Georg Baum
>>  wrote:
>>> Enrico Forestieri wrote:
>>>
 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.
>>>
>>> This is a good argument actually. Then we should produce a strong
>>> warning,
>>
>> Why do you prefer a strong warning versus an error? Do you agree that
>> with command line export we should exit with error?
>
> With "strong warning" I wanted to say that the  message should make it very
> clear that the resulting PDF should not be trusted, even if it looks OK at
> first glance. Whether it is called warning or error is more a matter of
> taste. To me it looks awkward to give an error message and then show the
> result nevertheless, but I have no strong opinion on this.

I see what you mean. I agree it looks awkward but I think that's the
point. I guess I was preferring an error because on the terminal we
will exit with an error so it seems more consistent. Also, we are
reporting a LaTeX error, not a LaTeX warning, so it seems consistent
from that point of view also.

> The command line export should exit with error in this case, otherwise it
> would not be possible to detect that something went wrong. This would also
> be consistent with the TeX compiler itself.

I agree.

>> OK. Does anyone object to showing the PDF if there is an error during
>> compilation?
>
> I think this should be consistent for all conversions: If the PDF is shown
> despite of LaTeX errorsv then it should also be shown if another converter
> fails, but produces output, e.g. ps2pdf.

I agree.

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Fri, Feb 27, 2015 at 4:27 PM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:
 Enrico Forestieri wrote:

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

 This is a good argument actually. Then we should produce a strong warning,

Why do you prefer a strong warning versus an error? Do you agree that
with command line export we should exit with error?

 and keep it that way (no referal to future versions).

OK. Does anyone object to showing the PDF if there is an error during
compilation?

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Fri, Feb 27, 2015 at 4:27 PM, Georg Baum
 wrote:
> Enrico Forestieri wrote:
>
>> My vote is for a warning and an output produced in any case.
>> If latex produces an output, that output has to be shown, IMO.
>> Having the possibility of looking at the output may be of great
>> help to pinpoint problems.
>
> This is a good argument actually. Then we should produce a strong warning,

Why do you prefer a strong warning versus an error? Do you agree that
with command line export we should exit with error?

> and keep it that way (no referal to future versions).

OK. Does anyone object to showing the PDF if there is an error during
compilation?

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic landronim...@gmail.com wrote:
 On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak skost...@lyx.org wrote:
 On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri for...@lyx.org wrote:

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

 Interesting idea. If we do this, we should do it for all errors. With

 I would second this. Actually, it seems to me that this is what LyX
 has been doing for quite some time,

 as somewhat often I get errors but
 a PDF does output (sometimes with useful clues on what really went
 wrong, and pointers on how to fix it).

LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
catches them by parsing the log, I do not get a PDF. I get the LaTeX
Errors dialog. You get the PDF and the LaTeX Errors dialog? Can you
send an example .lyx file that does this for you?

Scott

Re: [patches] Improve error reporting and log parsing

[Liviu Andronic]

On Fri, Feb 27, 2015 at 7:09 PM, Scott Kostyshak skost...@lyx.org wrote:
 On Fri, Feb 27, 2015 at 12:54 PM, Liviu Andronic landronim...@gmail.com 
 wrote:
 On Fri, Feb 27, 2015 at 6:22 PM, Scott Kostyshak skost...@lyx.org wrote:
 On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic landronim...@gmail.com 
 wrote:
 On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak skost...@lyx.org wrote:
 On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri for...@lyx.org wrote:

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

 Interesting idea. If we do this, we should do it for all errors. With

 I would second this. Actually, it seems to me that this is what LyX
 has been doing for quite some time,

 as somewhat often I get errors but
 a PDF does output (sometimes with useful clues on what really went
 wrong, and pointers on how to fix it).

 LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
 catches them by parsing the log, I do not get a PDF. I get the LaTeX
 Errors dialog. You get the PDF and the LaTeX Errors dialog? Can you
 send an example .lyx file that does this for you?

 No, nothing handy. From memory, the exact use case is that I have a
 document that  compiles and I have a PDF displayed. Then I modify the
 document, introduce something that will generate an error (perhaps on
 2nd pass), and compile from LyX: at one point the document compilation
 will result in error, but the PDF file shall be reloaded from disk in
 the PDF viewer (i.e. the PDF will appear even if compilation errors
 out). This will NOT work however if the PDF viewer was closed in
 between: an error will mean that the PDF viewer won't be called.

 Liviu

 Ah, that makes sense. Yes, you are exactly right about what's going
 on. This means that we already have an inconsistency in LyX: either we
 should not modify the PDF in the case of an error (e.g. use a
 temporary file and only rename if their is no error) or we should
 always show the PDF in the case of an error. It should be the same
 behavior for reload and view, in my opinion. And it seems to me that
 Enrico's preference is the most sensible: always show the PDF if there
 is one.

Agreed: always PDF...


 However, do we want a warning + PDF or an error + PDF? I think an
 error + PDF makes more sense. Similarly, on the command line, lyx -e
 pdf2 myfile.lyx in my opinion should have a non-zero exit code. I
 suppose it should also produce a PDF if possible.

...and an error message, explaining user that even if PDF showed up,
something is very wrong and they need to hunt that down.

Liviu


 Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: [patches] Improve error reporting and log parsing

[Liviu Andronic]

On Fri, Feb 27, 2015 at 6:22 PM, Scott Kostyshak skost...@lyx.org wrote:
 On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic landronim...@gmail.com 
 wrote:
 On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak skost...@lyx.org wrote:
 On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri for...@lyx.org wrote:

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

 Interesting idea. If we do this, we should do it for all errors. With

 I would second this. Actually, it seems to me that this is what LyX
 has been doing for quite some time,

 as somewhat often I get errors but
 a PDF does output (sometimes with useful clues on what really went
 wrong, and pointers on how to fix it).

 LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
 catches them by parsing the log, I do not get a PDF. I get the LaTeX
 Errors dialog. You get the PDF and the LaTeX Errors dialog? Can you
 send an example .lyx file that does this for you?

No, nothing handy. From memory, the exact use case is that I have a
document that  compiles and I have a PDF displayed. Then I modify the
document, introduce something that will generate an error (perhaps on
2nd pass), and compile from LyX: at one point the document compilation
will result in error, but the PDF file shall be reloaded from disk in
the PDF viewer (i.e. the PDF will appear even if compilation errors
out). This will NOT work however if the PDF viewer was closed in
between: an error will mean that the PDF viewer won't be called.

Liviu


 Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Fri, Feb 27, 2015 at 12:54 PM, Liviu Andronic landronim...@gmail.com wrote:
 On Fri, Feb 27, 2015 at 6:22 PM, Scott Kostyshak skost...@lyx.org wrote:
 On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic landronim...@gmail.com 
 wrote:
 On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak skost...@lyx.org wrote:
 On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri for...@lyx.org wrote:

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

 Interesting idea. If we do this, we should do it for all errors. With

 I would second this. Actually, it seems to me that this is what LyX
 has been doing for quite some time,

 as somewhat often I get errors but
 a PDF does output (sometimes with useful clues on what really went
 wrong, and pointers on how to fix it).

 LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
 catches them by parsing the log, I do not get a PDF. I get the LaTeX
 Errors dialog. You get the PDF and the LaTeX Errors dialog? Can you
 send an example .lyx file that does this for you?

 No, nothing handy. From memory, the exact use case is that I have a
 document that  compiles and I have a PDF displayed. Then I modify the
 document, introduce something that will generate an error (perhaps on
 2nd pass), and compile from LyX: at one point the document compilation
 will result in error, but the PDF file shall be reloaded from disk in
 the PDF viewer (i.e. the PDF will appear even if compilation errors
 out). This will NOT work however if the PDF viewer was closed in
 between: an error will mean that the PDF viewer won't be called.

 Liviu

Ah, that makes sense. Yes, you are exactly right about what's going
on. This means that we already have an inconsistency in LyX: either we
should not modify the PDF in the case of an error (e.g. use a
temporary file and only rename if their is no error) or we should
always show the PDF in the case of an error. It should be the same
behavior for reload and view, in my opinion. And it seems to me that
Enrico's preference is the most sensible: always show the PDF if there
is one.

However, do we want a warning + PDF or an error + PDF? I think an
error + PDF makes more sense. Similarly, on the command line, lyx -e
pdf2 myfile.lyx in my opinion should have a non-zero exit code. I
suppose it should also produce a PDF if possible.

Scott

Re: [patches] Improve error reporting and log parsing

[aparsloe]

On 28/02/2015 6:22 a.m., Scott Kostyshak wrote:

On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic landronim...@gmail.com wrote:

as somewhat often I get errors but
a PDF does output (sometimes with useful clues on what really went
wrong, and pointers on how to fix it).

LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
catches them by parsing the log, I do not get a PDF. I get the LaTeX
Errors dialog. You get the PDF and the LaTeX Errors dialog? Can you
send an example .lyx file that does this for you?

Scott
I've noticed that although LyX may report LaTeX errors and not display a 
pdf, nonetheless one is still produced in the temporary directory and 
can be displayed by double clicking. For example, create a math inset, 
insert an undefined control sequence, e.g. \blah, and a symbol or two, 
say xyz, and compile to pdf. LyX reports an undefined control sequence 
error and stops without displaying the pdf, but it *is* created in the 
temporary directory and will display a nicely typeset xyz.


Andrew

Re: [patches] Improve error reporting and log parsing

[Georg Baum]

Enrico Forestieri wrote:

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

This is a good argument actually. Then we should produce a strong warning, 
and keep it that way (no referal to future versions).


Georg

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Fri, Feb 27, 2015 at 4:14 PM, aparsloe apars...@clear.net.nz wrote:
 On 28/02/2015 6:22 a.m., Scott Kostyshak wrote:

 On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic landronim...@gmail.com
 wrote:

 as somewhat often I get errors but
 a PDF does output (sometimes with useful clues on what really went
 wrong, and pointers on how to fix it).

 LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
 catches them by parsing the log, I do not get a PDF. I get the LaTeX
 Errors dialog. You get the PDF and the LaTeX Errors dialog? Can you
 send an example .lyx file that does this for you?

 Scott

 I've noticed that although LyX may report LaTeX errors and not display a
 pdf, nonetheless one is still produced in the temporary directory and can be
 displayed by double clicking. For example, create a math inset, insert an
 undefined control sequence, e.g. \blah, and a symbol or two, say xyz, and
 compile to pdf. LyX reports an undefined control sequence error and stops
 without displaying the pdf, but it *is* created in the temporary directory
 and will display a nicely typeset xyz.

Indeed. The question is: *should* LyX show the PDF?

Scott

Re: [patches] Improve error reporting and log parsing

[Liviu Andronic]

On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak skost...@lyx.org wrote:
 On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri for...@lyx.org wrote:
 On Thu, Feb 26, 2015 at 12:57:24PM -0500, Scott Kostyshak wrote:
 On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak skost...@lyx.org wrote:
  On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum

  IMHO it can be made an error right away.
 
  I would be OK with making it an error right away. The argument for
  first making it a warning is that from the user perspective, the
  documents stop compiling. We had a similar discussion with BibTeX. We
  currently do not report BibTeX errors. Jurgen implemented support for
  reporting errors (7e188c51) but had to revert (148317b6) because of
  user complaints.

 Does anyone else have an opinion on this? I am fine either way. At
 first I assumed that because of the BibTeX issue we should be
 consistent with our decision on that. But perhaps this is different in
 some way?

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

 Interesting idea. If we do this, we should do it for all errors. With

I would second this. Actually, it seems to me that this is what LyX
has been doing for quite some time, as somewhat often I get errors but
a PDF does output (sometimes with useful clues on what really went
wrong, and pointers on how to fix it).

Regards,
Liviu

PS It is true that some other times it is confusing, so perhaps a
message from LyX: LaTeX compilation ended up with errors, but a PDF
has nevertheless been produced.  Or something along these lines...


 this commit I'm just proposing to (either directly or in a future
 version) add NONZERO_ERROR to be treated as other errors (by adding
 NONZERO_ERROR to ERRORS = TEX_ERROR + LATEX_ERROR in LaTeX.h). As for
 how we handle ERRORS, we could do what you suggest and check whether a
 PDF was created.

 Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: [patches] Improve error reporting and log parsing

[Liviu Andronic]

On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak  wrote:
> On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri  wrote:
>> On Thu, Feb 26, 2015 at 12:57:24PM -0500, Scott Kostyshak wrote:
>>> On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak  wrote:
>>> > On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum
>>>
>>> >> IMHO it can be made an error right away.
>>> >
>>> > I would be OK with making it an error right away. The argument for
>>> > first making it a warning is that from the user perspective, the
>>> > documents stop compiling. We had a similar discussion with BibTeX. We
>>> > currently do not report BibTeX errors. Jurgen implemented support for
>>> > reporting errors (7e188c51) but had to revert (148317b6) because of
>>> > user complaints.
>>>
>>> Does anyone else have an opinion on this? I am fine either way. At
>>> first I assumed that because of the BibTeX issue we should be
>>> consistent with our decision on that. But perhaps this is different in
>>> some way?
>>
>> My vote is for a warning and an output produced in any case.
>> If latex produces an output, that output has to be shown, IMO.
>> Having the possibility of looking at the output may be of great
>> help to pinpoint problems.
>
> Interesting idea. If we do this, we should do it for all errors. With
>
I would second this. Actually, it seems to me that this is what LyX
has been doing for quite some time, as somewhat often I get errors but
a PDF does output (sometimes with useful clues on what really went
wrong, and pointers on how to fix it).

Regards,
Liviu

PS It is true that some other times it is confusing, so perhaps a
message from LyX: "LaTeX compilation ended up with errors, but a PDF
has nevertheless been produced. " Or something along these lines...


> this commit I'm just proposing to (either directly or in a future
> version) add NONZERO_ERROR to be treated as other errors (by adding
> NONZERO_ERROR to ERRORS = TEX_ERROR + LATEX_ERROR in LaTeX.h). As for
> how we handle ERRORS, we could do what you suggest and check whether a
> PDF was created.
>
> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic  wrote:
> On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak  wrote:
>> On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri  wrote:

>>> My vote is for a warning and an output produced in any case.
>>> If latex produces an output, that output has to be shown, IMO.
>>> Having the possibility of looking at the output may be of great
>>> help to pinpoint problems.
>>
>> Interesting idea. If we do this, we should do it for all errors. With
>>
> I would second this. Actually, it seems to me that this is what LyX
> has been doing for quite some time,

> as somewhat often I get errors but
> a PDF does output (sometimes with useful clues on what really went
> wrong, and pointers on how to fix it).

LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
catches them by parsing the log, I do not get a PDF. I get the "LaTeX
Errors" dialog. You get the PDF and the "LaTeX Errors" dialog? Can you
send an example .lyx file that does this for you?

Scott

Re: [patches] Improve error reporting and log parsing

[Liviu Andronic]

On Fri, Feb 27, 2015 at 6:22 PM, Scott Kostyshak  wrote:
> On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic  
> wrote:
>> On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak  wrote:
>>> On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri  wrote:
>
 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.
>>>
>>> Interesting idea. If we do this, we should do it for all errors. With
>>>
>> I would second this. Actually, it seems to me that this is what LyX
>> has been doing for quite some time,
>
>> as somewhat often I get errors but
>> a PDF does output (sometimes with useful clues on what really went
>> wrong, and pointers on how to fix it).
>
> LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
> catches them by parsing the log, I do not get a PDF. I get the "LaTeX
> Errors" dialog. You get the PDF and the "LaTeX Errors" dialog? Can you
> send an example .lyx file that does this for you?
>
No, nothing handy. From memory, the exact use case is that I have a
document that  compiles and I have a PDF displayed. Then I modify the
document, introduce something that will generate an error (perhaps on
2nd pass), and compile from LyX: at one point the document compilation
will result in error, but the PDF file shall be reloaded from disk in
the PDF viewer (i.e. the PDF will appear even if compilation errors
out). This will NOT work however if the PDF viewer was closed in
between: an error will mean that the PDF viewer won't be called.

Liviu


> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Fri, Feb 27, 2015 at 12:54 PM, Liviu Andronic  wrote:
> On Fri, Feb 27, 2015 at 6:22 PM, Scott Kostyshak  wrote:
>> On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic  
>> wrote:
>>> On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak  wrote:
 On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri  wrote:
>>
> My vote is for a warning and an output produced in any case.
> If latex produces an output, that output has to be shown, IMO.
> Having the possibility of looking at the output may be of great
> help to pinpoint problems.

 Interesting idea. If we do this, we should do it for all errors. With

>>> I would second this. Actually, it seems to me that this is what LyX
>>> has been doing for quite some time,
>>
>>> as somewhat often I get errors but
>>> a PDF does output (sometimes with useful clues on what really went
>>> wrong, and pointers on how to fix it).
>>
>> LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
>> catches them by parsing the log, I do not get a PDF. I get the "LaTeX
>> Errors" dialog. You get the PDF and the "LaTeX Errors" dialog? Can you
>> send an example .lyx file that does this for you?
>>
> No, nothing handy. From memory, the exact use case is that I have a
> document that  compiles and I have a PDF displayed. Then I modify the
> document, introduce something that will generate an error (perhaps on
> 2nd pass), and compile from LyX: at one point the document compilation
> will result in error, but the PDF file shall be reloaded from disk in
> the PDF viewer (i.e. the PDF will appear even if compilation errors
> out). This will NOT work however if the PDF viewer was closed in
> between: an error will mean that the PDF viewer won't be called.
>
> Liviu

Ah, that makes sense. Yes, you are exactly right about what's going
on. This means that we already have an inconsistency in LyX: either we
should not modify the PDF in the case of an error (e.g. use a
temporary file and only rename if their is no error) or we should
always show the PDF in the case of an error. It should be the same
behavior for reload and view, in my opinion. And it seems to me that
Enrico's preference is the most sensible: always show the PDF if there
is one.

However, do we want a warning + PDF or an error + PDF? I think an
error + PDF makes more sense. Similarly, on the command line, lyx -e
pdf2 myfile.lyx in my opinion should have a non-zero exit code. I
suppose it should also produce a PDF if possible.

Scott

Re: [patches] Improve error reporting and log parsing

[Liviu Andronic]

On Fri, Feb 27, 2015 at 7:09 PM, Scott Kostyshak  wrote:
> On Fri, Feb 27, 2015 at 12:54 PM, Liviu Andronic  
> wrote:
>> On Fri, Feb 27, 2015 at 6:22 PM, Scott Kostyshak  wrote:
>>> On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic  
>>> wrote:
 On Fri, Feb 27, 2015 at 5:59 AM, Scott Kostyshak  wrote:
> On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri  wrote:
>>>
>> My vote is for a warning and an output produced in any case.
>> If latex produces an output, that output has to be shown, IMO.
>> Having the possibility of looking at the output may be of great
>> help to pinpoint problems.
>
> Interesting idea. If we do this, we should do it for all errors. With
>
 I would second this. Actually, it seems to me that this is what LyX
 has been doing for quite some time,
>>>
 as somewhat often I get errors but
 a PDF does output (sometimes with useful clues on what really went
 wrong, and pointers on how to fix it).
>>>
>>> LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
>>> catches them by parsing the log, I do not get a PDF. I get the "LaTeX
>>> Errors" dialog. You get the PDF and the "LaTeX Errors" dialog? Can you
>>> send an example .lyx file that does this for you?
>>>
>> No, nothing handy. From memory, the exact use case is that I have a
>> document that  compiles and I have a PDF displayed. Then I modify the
>> document, introduce something that will generate an error (perhaps on
>> 2nd pass), and compile from LyX: at one point the document compilation
>> will result in error, but the PDF file shall be reloaded from disk in
>> the PDF viewer (i.e. the PDF will appear even if compilation errors
>> out). This will NOT work however if the PDF viewer was closed in
>> between: an error will mean that the PDF viewer won't be called.
>>
>> Liviu
>
> Ah, that makes sense. Yes, you are exactly right about what's going
> on. This means that we already have an inconsistency in LyX: either we
> should not modify the PDF in the case of an error (e.g. use a
> temporary file and only rename if their is no error) or we should
> always show the PDF in the case of an error. It should be the same
> behavior for reload and view, in my opinion. And it seems to me that
> Enrico's preference is the most sensible: always show the PDF if there
> is one.
>
Agreed: always PDF...


> However, do we want a warning + PDF or an error + PDF? I think an
> error + PDF makes more sense. Similarly, on the command line, lyx -e
> pdf2 myfile.lyx in my opinion should have a non-zero exit code. I
> suppose it should also produce a PDF if possible.
>
...and an error message, explaining user that even if PDF showed up,
something is very wrong and they need to hunt that down.

Liviu


> Scott



-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library

Re: [patches] Improve error reporting and log parsing

[aparsloe]

On 28/02/2015 6:22 a.m., Scott Kostyshak wrote:

On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic  wrote:

as somewhat often I get errors but
a PDF does output (sometimes with useful clues on what really went
wrong, and pointers on how to fix it).

LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
catches them by parsing the log, I do not get a PDF. I get the "LaTeX
Errors" dialog. You get the PDF and the "LaTeX Errors" dialog? Can you
send an example .lyx file that does this for you?

Scott
I've noticed that although LyX may report LaTeX errors and not display a 
pdf, nonetheless one is still produced in the temporary directory and 
can be displayed by double clicking. For example, create a math inset, 
insert an undefined control sequence, e.g. \blah, and a symbol or two, 
say xyz, and compile to pdf. LyX reports an undefined control sequence 
error and stops without displaying the pdf, but it *is* created in the 
temporary directory and will display a nicely typeset xyz.


Andrew

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Fri, Feb 27, 2015 at 4:14 PM, aparsloe  wrote:
> On 28/02/2015 6:22 a.m., Scott Kostyshak wrote:
>>
>> On Fri, Feb 27, 2015 at 3:50 AM, Liviu Andronic 
>> wrote:
>>>
>>> as somewhat often I get errors but
>>> a PDF does output (sometimes with useful clues on what really went
>>> wrong, and pointers on how to fix it).
>>
>> LaTeX errors? Strange, for me if my document has LaTeX errors and LyX
>> catches them by parsing the log, I do not get a PDF. I get the "LaTeX
>> Errors" dialog. You get the PDF and the "LaTeX Errors" dialog? Can you
>> send an example .lyx file that does this for you?
>>
>> Scott
>
> I've noticed that although LyX may report LaTeX errors and not display a
> pdf, nonetheless one is still produced in the temporary directory and can be
> displayed by double clicking. For example, create a math inset, insert an
> undefined control sequence, e.g. \blah, and a symbol or two, say xyz, and
> compile to pdf. LyX reports an undefined control sequence error and stops
> without displaying the pdf, but it *is* created in the temporary directory
> and will display a nicely typeset xyz.

Indeed. The question is: *should* LyX show the PDF?

Scott

Re: [patches] Improve error reporting and log parsing

[Georg Baum]

Enrico Forestieri wrote:

> My vote is for a warning and an output produced in any case.
> If latex produces an output, that output has to be shown, IMO.
> Having the possibility of looking at the output may be of great
> help to pinpoint problems.

This is a good argument actually. Then we should produce a strong warning, 
and keep it that way (no referal to future versions).


Georg

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak skost...@lyx.org wrote:
 On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum

 IMHO it can be made an error right away.

 I would be OK with making it an error right away. The argument for
 first making it a warning is that from the user perspective, the
 documents stop compiling. We had a similar discussion with BibTeX. We
 currently do not report BibTeX errors. Jurgen implemented support for
 reporting errors (7e188c51) but had to revert (148317b6) because of
 user complaints.

Does anyone else have an opinion on this? I am fine either way. At
first I assumed that because of the BibTeX issue we should be
consistent with our decision on that. But perhaps this is different in
some way?

Scott

Re: [patches] Improve error reporting and log parsing

[Enrico Forestieri]

On Thu, Feb 26, 2015 at 12:57:24PM -0500, Scott Kostyshak wrote:
 On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak skost...@lyx.org wrote:
  On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum
 
  IMHO it can be made an error right away.
 
  I would be OK with making it an error right away. The argument for
  first making it a warning is that from the user perspective, the
  documents stop compiling. We had a similar discussion with BibTeX. We
  currently do not report BibTeX errors. Jurgen implemented support for
  reporting errors (7e188c51) but had to revert (148317b6) because of
  user complaints.
 
 Does anyone else have an opinion on this? I am fine either way. At
 first I assumed that because of the BibTeX issue we should be
 consistent with our decision on that. But perhaps this is different in
 some way?

My vote is for a warning and an output produced in any case.
If latex produces an output, that output has to be shown, IMO.
Having the possibility of looking at the output may be of great
help to pinpoint problems.

-- 
Enrico

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri for...@lyx.org wrote:
 On Thu, Feb 26, 2015 at 12:57:24PM -0500, Scott Kostyshak wrote:
 On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak skost...@lyx.org wrote:
  On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum

  IMHO it can be made an error right away.
 
  I would be OK with making it an error right away. The argument for
  first making it a warning is that from the user perspective, the
  documents stop compiling. We had a similar discussion with BibTeX. We
  currently do not report BibTeX errors. Jurgen implemented support for
  reporting errors (7e188c51) but had to revert (148317b6) because of
  user complaints.

 Does anyone else have an opinion on this? I am fine either way. At
 first I assumed that because of the BibTeX issue we should be
 consistent with our decision on that. But perhaps this is different in
 some way?

 My vote is for a warning and an output produced in any case.
 If latex produces an output, that output has to be shown, IMO.
 Having the possibility of looking at the output may be of great
 help to pinpoint problems.

Interesting idea. If we do this, we should do it for all errors. With
this commit I'm just proposing to (either directly or in a future
version) add NONZERO_ERROR to be treated as other errors (by adding
NONZERO_ERROR to ERRORS = TEX_ERROR + LATEX_ERROR in LaTeX.h). As for
how we handle ERRORS, we could do what you suggest and check whether a
PDF was created.

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak  wrote:
> On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum

>> IMHO it can be made an error right away.
>
> I would be OK with making it an error right away. The argument for
> first making it a warning is that from the user perspective, the
> documents stop compiling. We had a similar discussion with BibTeX. We
> currently do not report BibTeX errors. Jurgen implemented support for
> reporting errors (7e188c51) but had to revert (148317b6) because of
> user complaints.

Does anyone else have an opinion on this? I am fine either way. At
first I assumed that because of the BibTeX issue we should be
consistent with our decision on that. But perhaps this is different in
some way?

Scott

Re: [patches] Improve error reporting and log parsing

[Enrico Forestieri]

On Thu, Feb 26, 2015 at 12:57:24PM -0500, Scott Kostyshak wrote:
> On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak  wrote:
> > On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum
> 
> >> IMHO it can be made an error right away.
> >
> > I would be OK with making it an error right away. The argument for
> > first making it a warning is that from the user perspective, the
> > documents stop compiling. We had a similar discussion with BibTeX. We
> > currently do not report BibTeX errors. Jurgen implemented support for
> > reporting errors (7e188c51) but had to revert (148317b6) because of
> > user complaints.
> 
> Does anyone else have an opinion on this? I am fine either way. At
> first I assumed that because of the BibTeX issue we should be
> consistent with our decision on that. But perhaps this is different in
> some way?

My vote is for a warning and an output produced in any case.
If latex produces an output, that output has to be shown, IMO.
Having the possibility of looking at the output may be of great
help to pinpoint problems.

-- 
Enrico

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Thu, Feb 26, 2015 at 4:24 PM, Enrico Forestieri  wrote:
> On Thu, Feb 26, 2015 at 12:57:24PM -0500, Scott Kostyshak wrote:
>> On Wed, Feb 25, 2015 at 4:33 PM, Scott Kostyshak  wrote:
>> > On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum
>>
>> >> IMHO it can be made an error right away.
>> >
>> > I would be OK with making it an error right away. The argument for
>> > first making it a warning is that from the user perspective, the
>> > documents stop compiling. We had a similar discussion with BibTeX. We
>> > currently do not report BibTeX errors. Jurgen implemented support for
>> > reporting errors (7e188c51) but had to revert (148317b6) because of
>> > user complaints.
>>
>> Does anyone else have an opinion on this? I am fine either way. At
>> first I assumed that because of the BibTeX issue we should be
>> consistent with our decision on that. But perhaps this is different in
>> some way?
>
> My vote is for a warning and an output produced in any case.
> If latex produces an output, that output has to be shown, IMO.
> Having the possibility of looking at the output may be of great
> help to pinpoint problems.

Interesting idea. If we do this, we should do it for all errors. With
this commit I'm just proposing to (either directly or in a future
version) add NONZERO_ERROR to be treated as other errors (by adding
NONZERO_ERROR to ERRORS = TEX_ERROR + LATEX_ERROR in LaTeX.h). As for
how we handle ERRORS, we could do what you suggest and check whether a
PDF was created.

Scott

Re: [patches] Improve error reporting and log parsing

[Georg Baum]

Scott Kostyshak wrote:

 0005-Check-exit-code-of-LaTeX-process-in-LaTeX-run.patch
 - To see why this patch is useful, open New  New from Template 
 ACM-sigplan.lyx and compile. It says that compilation was successful
 and shows the PDF. However, there was an error that was missed in
 parsing (the terminal shows support/Systemcall.cpp (288): Systemcall:
 'pdflatex  newfile1.tex' finished with exit code 1).
 - For a related email thread, see
 https://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg185316.html

I am surprised that the exit code is currently ignored. IMHO it can be made 
an error right away. If you want to keep it as a warning then please don't 
mention future version numbers, these tend to be wrong (we do not know if 
the release after 2.2.0 will be named 2.3.0 or something else, and we don't 
know either if this will be the release which converts the warning into an 
error).

I can't comment on the Alert stuff since I don't understand it too well, but 
the other patches look all good.


Georg

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:
 Scott Kostyshak wrote:

 0005-Check-exit-code-of-LaTeX-process-in-LaTeX-run.patch
 - To see why this patch is useful, open New  New from Template 
 ACM-sigplan.lyx and compile. It says that compilation was successful
 and shows the PDF. However, there was an error that was missed in
 parsing (the terminal shows support/Systemcall.cpp (288): Systemcall:
 'pdflatex  newfile1.tex' finished with exit code 1).
 - For a related email thread, see
 https://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg185316.html

 I am surprised that the exit code is currently ignored.

So was I. I guess this means that our log parsing is pretty good if
the issue hasn't come up before.

 IMHO it can be made an error right away.

I would be OK with making it an error right away. The argument for
first making it a warning is that from the user perspective, the
documents stop compiling. We had a similar discussion with BibTeX. We
currently do not report BibTeX errors. Jurgen implemented support for
reporting errors (7e188c51) but had to revert (148317b6) because of
user complaints.

 If you want to keep it as a warning then please don't
 mention future version numbers, these tend to be wrong (we do not know if
 the release after 2.2.0 will be named 2.3.0 or something else, and we don't
 know either if this will be the release which converts the warning into an
 error).

OK I will say future version.

 I can't comment on the Alert stuff since I don't understand it too well, but
 the other patches look all good.

Thanks for taking a look.

Scott

Re: [patches] Improve error reporting and log parsing

[Georg Baum]

Scott Kostyshak wrote:

> 0005-Check-exit-code-of-LaTeX-process-in-LaTeX-run.patch
> - To see why this patch is useful, open New > New from Template >
> ACM-sigplan.lyx and compile. It says that compilation was successful
> and shows the PDF. However, there was an error that was missed in
> parsing (the terminal shows support/Systemcall.cpp (288): Systemcall:
> 'pdflatex  "newfile1.tex"' finished with exit code 1).
> - For a related email thread, see
> https://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg185316.html

I am surprised that the exit code is currently ignored. IMHO it can be made 
an error right away. If you want to keep it as a warning then please don't 
mention future version numbers, these tend to be wrong (we do not know if 
the release after 2.2.0 will be named 2.3.0 or something else, and we don't 
know either if this will be the release which converts the warning into an 
error).

I can't comment on the Alert stuff since I don't understand it too well, but 
the other patches look all good.


Georg

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Wed, Feb 25, 2015 at 4:07 PM, Georg Baum
 wrote:
> Scott Kostyshak wrote:
>
>> 0005-Check-exit-code-of-LaTeX-process-in-LaTeX-run.patch
>> - To see why this patch is useful, open New > New from Template >
>> ACM-sigplan.lyx and compile. It says that compilation was successful
>> and shows the PDF. However, there was an error that was missed in
>> parsing (the terminal shows support/Systemcall.cpp (288): Systemcall:
>> 'pdflatex  "newfile1.tex"' finished with exit code 1).
>> - For a related email thread, see
>> https://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg185316.html
>
> I am surprised that the exit code is currently ignored.

So was I. I guess this means that our log parsing is pretty good if
the issue hasn't come up before.

> IMHO it can be made an error right away.

I would be OK with making it an error right away. The argument for
first making it a warning is that from the user perspective, the
documents stop compiling. We had a similar discussion with BibTeX. We
currently do not report BibTeX errors. Jurgen implemented support for
reporting errors (7e188c51) but had to revert (148317b6) because of
user complaints.

> If you want to keep it as a warning then please don't
> mention future version numbers, these tend to be wrong (we do not know if
> the release after 2.2.0 will be named 2.3.0 or something else, and we don't
> know either if this will be the release which converts the warning into an
> error).

OK I will say "future version".

> I can't comment on the Alert stuff since I don't understand it too well, but
> the other patches look all good.

Thanks for taking a look.

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Tue, Feb 24, 2015 at 1:22 PM, Richard Heck rgh...@lyx.org wrote:
 On 02/24/2015 12:01 PM, Scott Kostyshak wrote:

 On Tue, Feb 24, 2015 at 9:30 AM, Richard Heck rgh...@lyx.org wrote:

 On 02/22/2015 03:45 PM, Scott Kostyshak wrote:

 0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
 - This is the patch I am least confident about. Conditioning on
 !buffer.isClone() caused the condition to always fail so the alerts
 were never shown. Is that conditioning still needed? I don't
 understand this process well. I imagine that whenever I compile from
 the LyX GUI, it clones the buffer (so that I can change the buffer
 while compiling is going on). In which case is !buffer.isClone() true
 (can you give me steps to reproduce)? Can anyone get the warning to
 activate *without* this patch (e.g. try to compile a blank .lyx file)?

 Can anyone explain further the necessity of this commit and whether
 the Alert system has indeed been rethought in the last few years?


 This seems to have been committed right when the whole cloning idea was
 first
 introduced into the code. There was a good deal of work done on the Alert
 framework
 after that, but whether it was enough to make this unnecessary, I do not
 know. There's
 one way to find out

 It works well when I take it out (i.e. apply the patch), but I'm not
 sure if that is only because I have tested it in a certain situation
 and only on Linux.


 Unless you hear any objection, I'd go ahead and put it in. I am pretty sure
 that all the work that Peter Kummel did with the InGuiThread classes dealt
 with this issue.

Sounds good. I will still wait a few days to see if anyone has feedback.

Scott

Re: [patches] Improve error reporting and log parsing

[Richard Heck]

On 02/22/2015 03:45 PM, Scott Kostyshak wrote:

0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
- This is the patch I am least confident about. Conditioning on
!buffer.isClone() caused the condition to always fail so the alerts
were never shown. Is that conditioning still needed? I don't
understand this process well. I imagine that whenever I compile from
the LyX GUI, it clones the buffer (so that I can change the buffer
while compiling is going on). In which case is !buffer.isClone() true
(can you give me steps to reproduce)? Can anyone get the warning to
activate *without* this patch (e.g. try to compile a blank .lyx file)?

Can anyone explain further the necessity of this commit and whether
the Alert system has indeed been rethought in the last few years?


This seems to have been committed right when the whole cloning idea was 
first
introduced into the code. There was a good deal of work done on the 
Alert framework
after that, but whether it was enough to make this unnecessary, I do not 
know. There's

one way to find out

Richard

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Tue, Feb 24, 2015 at 9:30 AM, Richard Heck rgh...@lyx.org wrote:
 On 02/22/2015 03:45 PM, Scott Kostyshak wrote:

 0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
 - This is the patch I am least confident about. Conditioning on
 !buffer.isClone() caused the condition to always fail so the alerts
 were never shown. Is that conditioning still needed? I don't
 understand this process well. I imagine that whenever I compile from
 the LyX GUI, it clones the buffer (so that I can change the buffer
 while compiling is going on). In which case is !buffer.isClone() true
 (can you give me steps to reproduce)? Can anyone get the warning to
 activate *without* this patch (e.g. try to compile a blank .lyx file)?

 Can anyone explain further the necessity of this commit and whether
 the Alert system has indeed been rethought in the last few years?


 This seems to have been committed right when the whole cloning idea was
 first
 introduced into the code. There was a good deal of work done on the Alert
 framework
 after that, but whether it was enough to make this unnecessary, I do not
 know. There's
 one way to find out

It works well when I take it out (i.e. apply the patch), but I'm not
sure if that is only because I have tested it in a certain situation
and only on Linux.

Scott

Re: [patches] Improve error reporting and log parsing

[Richard Heck]

On 02/24/2015 12:01 PM, Scott Kostyshak wrote:

On Tue, Feb 24, 2015 at 9:30 AM, Richard Heck rgh...@lyx.org wrote:

On 02/22/2015 03:45 PM, Scott Kostyshak wrote:

0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
- This is the patch I am least confident about. Conditioning on
!buffer.isClone() caused the condition to always fail so the alerts
were never shown. Is that conditioning still needed? I don't
understand this process well. I imagine that whenever I compile from
the LyX GUI, it clones the buffer (so that I can change the buffer
while compiling is going on). In which case is !buffer.isClone() true
(can you give me steps to reproduce)? Can anyone get the warning to
activate *without* this patch (e.g. try to compile a blank .lyx file)?

Can anyone explain further the necessity of this commit and whether
the Alert system has indeed been rethought in the last few years?


This seems to have been committed right when the whole cloning idea was
first
introduced into the code. There was a good deal of work done on the Alert
framework
after that, but whether it was enough to make this unnecessary, I do not
know. There's
one way to find out

It works well when I take it out (i.e. apply the patch), but I'm not
sure if that is only because I have tested it in a certain situation
and only on Linux.


Unless you hear any objection, I'd go ahead and put it in. I am pretty 
sure that all the work that Peter Kummel did with the InGuiThread 
classes dealt with this issue.


If not, we'll find out.

rh

Re: [patches] Improve error reporting and log parsing

[Richard Heck]

On 02/22/2015 03:45 PM, Scott Kostyshak wrote:

0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
- This is the patch I am least confident about. Conditioning on
!buffer.isClone() caused the condition to always fail so the alerts
were never shown. Is that conditioning still needed? I don't
understand this process well. I imagine that whenever I compile from
the LyX GUI, it clones the buffer (so that I can change the buffer
while compiling is going on). In which case is !buffer.isClone() true
(can you give me steps to reproduce)? Can anyone get the warning to
activate *without* this patch (e.g. try to compile a blank .lyx file)?

Can anyone explain further the necessity of this commit and whether
the Alert system has indeed been rethought in the last few years?


This seems to have been committed right when the whole cloning idea was 
first
introduced into the code. There was a good deal of work done on the 
Alert framework
after that, but whether it was enough to make this unnecessary, I do not 
know. There's

one way to find out

Richard

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Tue, Feb 24, 2015 at 9:30 AM, Richard Heck  wrote:
> On 02/22/2015 03:45 PM, Scott Kostyshak wrote:
>>
>> 0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
>> - This is the patch I am least confident about. Conditioning on
>> !buffer.isClone() caused the condition to always fail so the alerts
>> were never shown. Is that conditioning still needed? I don't
>> understand this process well. I imagine that whenever I compile from
>> the LyX GUI, it clones the buffer (so that I can change the buffer
>> while compiling is going on). In which case is !buffer.isClone() true
>> (can you give me steps to reproduce)? Can anyone get the warning to
>> activate *without* this patch (e.g. try to compile a blank .lyx file)?
>>
>> Can anyone explain further the necessity of this commit and whether
>> the Alert system has indeed been rethought in the last few years?
>
>
> This seems to have been committed right when the whole cloning idea was
> first
> introduced into the code. There was a good deal of work done on the Alert
> framework
> after that, but whether it was enough to make this unnecessary, I do not
> know. There's
> one way to find out

It works well when I take it out (i.e. apply the patch), but I'm not
sure if that is only because I have tested it in a certain situation
and only on Linux.

Scott

Re: [patches] Improve error reporting and log parsing

[Richard Heck]

On 02/24/2015 12:01 PM, Scott Kostyshak wrote:

On Tue, Feb 24, 2015 at 9:30 AM, Richard Heck  wrote:

On 02/22/2015 03:45 PM, Scott Kostyshak wrote:

0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
- This is the patch I am least confident about. Conditioning on
!buffer.isClone() caused the condition to always fail so the alerts
were never shown. Is that conditioning still needed? I don't
understand this process well. I imagine that whenever I compile from
the LyX GUI, it clones the buffer (so that I can change the buffer
while compiling is going on). In which case is !buffer.isClone() true
(can you give me steps to reproduce)? Can anyone get the warning to
activate *without* this patch (e.g. try to compile a blank .lyx file)?

Can anyone explain further the necessity of this commit and whether
the Alert system has indeed been rethought in the last few years?


This seems to have been committed right when the whole cloning idea was
first
introduced into the code. There was a good deal of work done on the Alert
framework
after that, but whether it was enough to make this unnecessary, I do not
know. There's
one way to find out

It works well when I take it out (i.e. apply the patch), but I'm not
sure if that is only because I have tested it in a certain situation
and only on Linux.


Unless you hear any objection, I'd go ahead and put it in. I am pretty 
sure that all the work that Peter K"ummel did with the InGuiThread 
classes dealt with this issue.


If not, we'll find out.

rh

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Tue, Feb 24, 2015 at 1:22 PM, Richard Heck  wrote:
> On 02/24/2015 12:01 PM, Scott Kostyshak wrote:
>>
>> On Tue, Feb 24, 2015 at 9:30 AM, Richard Heck  wrote:
>>>
>>> On 02/22/2015 03:45 PM, Scott Kostyshak wrote:

 0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
 - This is the patch I am least confident about. Conditioning on
 !buffer.isClone() caused the condition to always fail so the alerts
 were never shown. Is that conditioning still needed? I don't
 understand this process well. I imagine that whenever I compile from
 the LyX GUI, it clones the buffer (so that I can change the buffer
 while compiling is going on). In which case is !buffer.isClone() true
 (can you give me steps to reproduce)? Can anyone get the warning to
 activate *without* this patch (e.g. try to compile a blank .lyx file)?

 Can anyone explain further the necessity of this commit and whether
 the Alert system has indeed been rethought in the last few years?
>>>
>>>
>>> This seems to have been committed right when the whole cloning idea was
>>> first
>>> introduced into the code. There was a good deal of work done on the Alert
>>> framework
>>> after that, but whether it was enough to make this unnecessary, I do not
>>> know. There's
>>> one way to find out
>>
>> It works well when I take it out (i.e. apply the patch), but I'm not
>> sure if that is only because I have tested it in a certain situation
>> and only on Linux.
>
>
> Unless you hear any objection, I'd go ahead and put it in. I am pretty sure
> that all the work that Peter K"ummel did with the InGuiThread classes dealt
> with this issue.

Sounds good. I will still wait a few days to see if anyone has feedback.

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Sun, Feb 22, 2015 at 11:32 PM, aparsloe apars...@clear.net.nz wrote:

 On 23/02/2015 9:45 a.m., Scott Kostyshak wrote:

 Attached are a sequence of patches addressing issues related to LyX's
 error reporting and log parsing.

 Dear Scott,

 Not strictly on topic, but for one giddy moment I thought there might have
 been some attention paid to #9211. Alas no. (Instant preview allows the
 running of latex programs quite independently of the main document. It would
 be good to have easy access to the logs for these files, say the preview log
 when the main document is opened, and the preview log of the last preview
 created -- only two logs, rather than the last few suggested in #9211.)

 Andrew

Hi Andrew,

Indeed, this has nothing to do with #9211. I have a question for #9211
but I will post it on the ticket.

Scott

Re: [patches] Improve error reporting and log parsing

[Scott Kostyshak]

On Sun, Feb 22, 2015 at 11:32 PM, aparsloe  wrote:
>
> On 23/02/2015 9:45 a.m., Scott Kostyshak wrote:
>>
>> Attached are a sequence of patches addressing issues related to LyX's
>> error reporting and log parsing.
>
> Dear Scott,
>
> Not strictly on topic, but for one giddy moment I thought there might have
> been some attention paid to #9211. Alas no. (Instant preview allows the
> running of latex programs quite independently of the main document. It would
> be good to have easy access to the logs for these files, say the preview log
> when the main document is opened, and the preview log of the last preview
> created -- only two logs, rather than the "last few" suggested in #9211.)
>
> Andrew

Hi Andrew,

Indeed, this has nothing to do with #9211. I have a question for #9211
but I will post it on the ticket.

Scott

[patches] Improve error reporting and log parsing

[Scott Kostyshak]

Attached are a sequence of patches addressing issues related to LyX's
error reporting and log parsing. I give more detailed descriptions of
them in the actual commit messages of the attached patches, but below
I list important points as well as a couple of questions. I have
brought up a couple of these topics in separate emails but since the
patches are dependent, I prefer to start this new thread and I will
reference the other threads when necessary (once the topics are
resolved here I will update the other threads for archive purposes).

0001-Clarify-message-about-an-empty-file.patch
- In brief testing, when I compile a .tex file that does not produce
output, no .pdf is created (not even an empty .pdf). Can anyone
confirm this?

0003-Remove-an-outdated-comment.patch
- A dummy function means that the function has no effect, correct?

0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
- This is the patch I am least confident about. Conditioning on
!buffer.isClone() caused the condition to always fail so the alerts
were never shown. Is that conditioning still needed? I don't
understand this process well. I imagine that whenever I compile from
the LyX GUI, it clones the buffer (so that I can change the buffer
while compiling is going on). In which case is !buffer.isClone() true
(can you give me steps to reproduce)? Can anyone get the warning to
activate *without* this patch (e.g. try to compile a blank .lyx file)?

Can anyone explain further the necessity of this commit and whether
the Alert system has indeed been rethought in the last few years?
commit bea0925f8ccd617293d9171eef8453d938e3a44f
Author: Abdelrazak Younes you...@lyx.org
Date:   Fri Dec 18 22:59:59 2009 +

Converter: add a safe guard to Alerts because those cannot be
called from another thread. The whole Alert system must be rethought I
am afraid.

0005-Check-exit-code-of-LaTeX-process-in-LaTeX-run.patch
- To see why this patch is useful, open New  New from Template 
ACM-sigplan.lyx and compile. It says that compilation was successful
and shows the PDF. However, there was an error that was missed in
parsing (the terminal shows support/Systemcall.cpp (288): Systemcall:
'pdflatex  newfile1.tex' finished with exit code 1).
- For a related email thread, see
https://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg185316.html

0006-Improve-log-scanner-to-correctly-report-error.patch
- This fixes the parsing that lead to the particular instance of the
bug fixed in patch 0005.
- For a related email thread, see
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg185567.html
From 26fe6b3101e530cc4809d947f263affaac9f523c Mon Sep 17 00:00:00 2001
From: Scott Kostyshak skost...@lyx.org
Date: Sat, 21 Feb 2015 00:00:51 -0500
Subject: [PATCH 6/6] Improve log scanner to correctly report error

When scanning the LaTeX log, previously we only looked ahead 10 lines
after a ! line and if we did not find a line number we did not count
an error. This lead to the problem that templates/ACM-sigplan.lyx was
showing a successful export and the PDF was shown (it is still
created despite the error). Now that the exit code of the latex
command is checked (as of the previous commit), an error is correctly
given, but by parsing the log better with this commit, a more
informative error is given.

Increasing the look-ahead to 15 lines leads to correct parsing of
the ACM-sigplan log. The excerpt in the log file where there are more
than 10 lines in-between the ! line and the line number is below:

! Undefined control sequence.
\@toappear ...ent http://dx.doi.org/10.1145/\@doi

argument ...n is removed.]\par \else \@toappear
  \fi \if \@reprint
\noinden...

\@begin@tempboxa ...mpboxa #1{\color@begingroup #2
  \color@endgroup }\def
\wid...

\@iiiparbox ...tempdima \@parboxrestore #5\@@par }
  \ifx \relax #2\else
\setle...

\@copyrightspace ...planconf@finalpage}.\par \fi }
  }\end@float
\maketitle ... \@copyrightwanted \@copyrightspace
  \fi
l.34 \maketitle
---
 src/LaTeX.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/LaTeX.cpp b/src/LaTeX.cpp
index e0259e6..346fea6 100644
--- a/src/LaTeX.cpp
+++ b/src/LaTeX.cpp
@@ -830,7 +830,10 @@ int LaTeX::scanLogFile(TeXErrors  terr)
 if (!getline(ifs, tmp))
 	break;
 tmp = rtrim(tmp, \r);
-if (++count  10)
+// 15 is somewhat arbitrarily chosen, based on practice.
+// We used 10 for 14 years and increased it to 15 when we
+// saw one case.
+if (++count  15)
 	break;
 			} while (!prefixIs(tmp, l.));
 			if (prefixIs(tmp, l.)) {
-- 
2.1.0

From 05704d0a84067ad7a415891ad9646b09ac897305 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak skost...@lyx.org
Date: Fri, 20 Feb 2015 16:17:03 -0500
Subject: [PATCH 5/6] Check exit 

Re: [patches] Improve error reporting and log parsing

[aparsloe]

On 23/02/2015 9:45 a.m., Scott Kostyshak wrote:

Attached are a sequence of patches addressing issues related to LyX's
error reporting and log parsing.

Dear Scott,

Not strictly on topic, but for one giddy moment I thought there might 
have been some attention paid to #9211. Alas no. (Instant preview allows 
the running of latex programs quite independently of the main document. 
It would be good to have easy access to the logs for these files, say 
the preview log when the main document is opened, and the preview log of 
the last preview created -- only two logs, rather than the last few 
suggested in #9211.)


Andrew

[patches] Improve error reporting and log parsing

[Scott Kostyshak]

Attached are a sequence of patches addressing issues related to LyX's
error reporting and log parsing. I give more detailed descriptions of
them in the actual commit messages of the attached patches, but below
I list important points as well as a couple of questions. I have
brought up a couple of these topics in separate emails but since the
patches are dependent, I prefer to start this new thread and I will
reference the other threads when necessary (once the topics are
resolved here I will update the other threads for archive purposes).

0001-Clarify-message-about-an-empty-file.patch
- In brief testing, when I compile a .tex file that does not produce
output, no .pdf is created (not even an empty .pdf). Can anyone
confirm this?

0003-Remove-an-outdated-comment.patch
- A "dummy function" means that the function has no effect, correct?

0004-Allow-cloned-buffers-to-give-alerts-in-runLaTeX.patch
- This is the patch I am least confident about. Conditioning on
!buffer.isClone() caused the condition to always fail so the alerts
were never shown. Is that conditioning still needed? I don't
understand this process well. I imagine that whenever I compile from
the LyX GUI, it clones the buffer (so that I can change the buffer
while compiling is going on). In which case is !buffer.isClone() true
(can you give me steps to reproduce)? Can anyone get the warning to
activate *without* this patch (e.g. try to compile a blank .lyx file)?

Can anyone explain further the necessity of this commit and whether
the Alert system has indeed been rethought in the last few years?
commit bea0925f8ccd617293d9171eef8453d938e3a44f
Author: Abdelrazak Younes 
Date:   Fri Dec 18 22:59:59 2009 +

Converter: add a safe guard to Alerts because those cannot be
called from another thread. The whole Alert system must be rethought I
am afraid.

0005-Check-exit-code-of-LaTeX-process-in-LaTeX-run.patch
- To see why this patch is useful, open New > New from Template >
ACM-sigplan.lyx and compile. It says that compilation was successful
and shows the PDF. However, there was an error that was missed in
parsing (the terminal shows support/Systemcall.cpp (288): Systemcall:
'pdflatex  "newfile1.tex"' finished with exit code 1).
- For a related email thread, see
https://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg185316.html

0006-Improve-log-scanner-to-correctly-report-error.patch
- This fixes the parsing that lead to the particular instance of the
bug fixed in patch 0005.
- For a related email thread, see
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg185567.html
From 26fe6b3101e530cc4809d947f263affaac9f523c Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Sat, 21 Feb 2015 00:00:51 -0500
Subject: [PATCH 6/6] Improve log scanner to correctly report error

When scanning the LaTeX log, previously we only looked ahead 10 lines
after a "!" line and if we did not find a line number we did not count
an error. This lead to the problem that templates/ACM-sigplan.lyx was
showing a successful export and the PDF was shown (it is still
created despite the error). Now that the exit code of the latex
command is checked (as of the previous commit), an error is correctly
given, but by parsing the log better with this commit, a more
informative error is given.

Increasing the look-ahead to 15 lines leads to correct parsing of
the ACM-sigplan log. The excerpt in the log file where there are more
than 10 lines in-between the "!" line and the line number is below:

! Undefined control sequence.
\@toappear ...ent http://dx.doi.org/10.1145/\@doi

 ...n is removed.]\par \else \@toappear
  \fi \if \@reprint
\noinden...

\@begin@tempboxa ...mpboxa #1{\color@begingroup #2
  \color@endgroup }\def
\wid...

\@iiiparbox ...tempdima \@parboxrestore #5\@@par }
  \ifx \relax #2\else
\setle...

\@copyrightspace ...planconf@finalpage}.\par \fi }
  }\end@float
\maketitle ... \@copyrightwanted \@copyrightspace
  \fi
l.34 \maketitle
---
 src/LaTeX.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/LaTeX.cpp b/src/LaTeX.cpp
index e0259e6..346fea6 100644
--- a/src/LaTeX.cpp
+++ b/src/LaTeX.cpp
@@ -830,7 +830,10 @@ int LaTeX::scanLogFile(TeXErrors & terr)
 if (!getline(ifs, tmp))
 	break;
 tmp = rtrim(tmp, "\r");
-if (++count > 10)
+// 15 is somewhat arbitrarily chosen, based on practice.
+// We used 10 for 14 years and increased it to 15 when we
+// saw one case.
+if (++count > 15)
 	break;
 			} while (!prefixIs(tmp, "l."));
 			if (prefixIs(tmp, "l.")) {
-- 
2.1.0

From 05704d0a84067ad7a415891ad9646b09ac897305 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Fri, 20 Feb 2015 16:17:03 -0500
Subject: [PATCH 

Re: [patches] Improve error reporting and log parsing

[aparsloe]

On 23/02/2015 9:45 a.m., Scott Kostyshak wrote:

Attached are a sequence of patches addressing issues related to LyX's
error reporting and log parsing.

Dear Scott,

Not strictly on topic, but for one giddy moment I thought there might 
have been some attention paid to #9211. Alas no. (Instant preview allows 
the running of latex programs quite independently of the main document. 
It would be good to have easy access to the logs for these files, say 
the preview log when the main document is opened, and the preview log of 
the last preview created -- only two logs, rather than the "last few" 
suggested in #9211.)


Andrew