#1068 Better error messages

[Mast B.]

This has frustrated me for a long time but I could alway slive with it. The issue is simple.

The output of pdflatex says:

! Undefined control sequence.
\qnumber ->\qfont 
                  \ifnum 1>\difthreshold {\difmark \difmarkspace }\fi \thequ...
l.3 }

The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

But the log window of TexStdio says only:

Undefined control sequence. }

Which is misleading and non-informative. It would be a much better if TexStudio took the full string of the error (including the description), stripped all line endings, and made it into a single line and into the Message, which can be cropped at the window border. You can add an ellipsis "[...]" and the user can see the full message if they hover the mouse.

I know I can double click it but in my case that's completely worthless because those commands are actually defined in a .sty, and not in the file which pdflatex and texstduio point to. So going to that file isn't helpful.

Hope this gets implemented :)

Keep up the great work!

[Jan Sundermeyer]

Ticket moved from /p/texstudio/bugs/1773/

[David Carlisle]

It would be really helpful if the initial error display could show at least the name of the undefined command, this comes up all the time on stack exchange with users being confused and reporting that \begin{document} or \maketitle or similar commands are undefined, when the next (unshown) line of the underlying error message would have shown the actual undefined command.

most recently today:

http://tex.stackexchange.com/questions/311122/how-to-assign-arbitrary-latex-text-to-a-variable-for-use-in-different-places-in#comment756395_311122

[Tim Hoffmann]

Please provide a minimal example and indicate the compiler.

When I try this, I get this log

! Undefined control sequence.
l.13 \qnumber ->\qfont
                    \ifnum 1>\difthreshold {\difmark \difmarkspace }\fi \the...

which is parsed correctly.

[Mast B.]

No, I'm talking about TexStudio's lower pane when the "Log -> Issues" tab is selected ... that only shows one line of string in each row, which shows only "! Undefined control sequence" in your case.

(The full error message can be seen if the "Log -> Log File" tab is selected, but that's not what I was talking about)

[Tim Hoffmann]

I think I know, what you are talking about. If not, please prove me wrong with a MWE. Here is mine and it works:

\documentclass[10pt,a4paper]{article}
\begin{document}
undefined \command more text
\end{document}

Compiled with pdflatex:

[Mast B.]

That's because your error is already in one line. Please see the error I copy pasted above, which is on multiple lines, and which TexStudio takes only the 1st line which does not contain useful information. I was simply asking to merge all lines from the error (strip \r \n) into one line for the Log > Issues tab.

I don't have an MWE at hand, but I don't think this actually requires an MWE. If you really can't see the problem then I'll provide an MWE if I find the time (swamped now).

[Tim Hoffmann]

The difference between your and my error is that in my case the line number is printed in front of the faulty code, while in your case, it's behind.

I need to understand when this happens because if I extend the parser, I'll possibly have to test against different variants of this. Therefore I need to be able to generate the error myself. I won't implement just based on the one example output you've provided, because such an implementation might not catch the general class of these errors correctly.

[Mast B.]

Here you go, see below -- though I'm sure you can get a even simpler example to reveal the problem.

Put this in test1.sty:

\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{test1}

\newcommand{\question}[2][6]{%
  \def\qnumber{%
    \qfont\ifnum#1>5{+~}\fi}%
  #1 \qnumber
}

Put this in document.tex

\documentclass[10pt,a4paper]{article}
\usepackage{test1}
\begin{document}
\question[9]{foo
}
\end{document}

Texstudio says Undefined control sequence. }.

If you write \question[9]{foo} instead (note the closing curly bracket) then TexStudio says Undefined control sequence. \question[9]{foo} ... both errors should be improved since actual problem is \qfont, which the compiler correctly identifies, but TS parses it wrongly:

! Undefined control sequence.
\qnumber ->\qfont 
                  \ifnum 9>5{+~}\fi 
l.5 }

As I said in my first post, why not just concatenate all lines from the compiler's output about the error into a single line for TexStudio? This would be a safer and more future proof solution than if you tried to distinguish between cases.

[Mast B.]

Also, I believe this is a bug, not a feature request ... not sure why Jan moved it.

[Tim Hoffmann]

As I said in my first post, why not just concatenate all lines from the compiler's output about the error into a single line for TexStudio? This would be a safer and more future proof solution than if you tried to distinguish between cases.

I would agree if there was a format specification for the log. But as far as I've learned to know the log, there are no rules. Everything can and will happen. I would be really happy if you could tell me a universal way how to get all the lines for an error. I could throw away loads of heuristics.

By the way, https://en.wikibooks.org/wiki/LaTeX/Errors_and_Warnings#Error_messages claims a structure, that does not cover your case:

The format of an error message is always the same. Error messages begin with an exclamation mark at the start of the line, and give a description of the error, followed by another line starting with the number, which refers to the line-number in your document file which LaTeX was processing when the error was spotted.

[Mast B.]

I would agree if there was a format specification for the log. But as far as I've learned to know the log, there are no rules. Everything can and will happen. I would be really happy if you could tell me a universal way how to get all the lines for an error. I could throw away loads of heuristics.

I'm really not trying to be a smartass, but I really think this is doable. Since you ask, sure, here goes: Parse the output string (all of it) using the following regexp (perl):

(?ms^!.*?^l\.\d+ .*?$)

... then replace \r|\n with ; in each captured group to make it a single line, and put each line it in the Log > Issue tab.

That should do it. Note that I haven't tried it, but it should work (famous last words). If it doesn't, the idea is to capture all lines between the line starting with "^!" and the line that starts with "^l\.\d+" (line number of the error).

The Wikibooks description is correct and does cover my case ... error starts with "^!", ends with "l\.\d+", they are on separate lines and there can be any number of lines in between them. That's fine. See my regexp above.

[Tim Hoffmann]

That would lead to

! Undefined control sequence.; \qnumber ->\qfont ; \ifnum 1>\difthreshold {\difmark \difmarkspace }\fi \thequ... l.3 }

or

! Undefined control sequence.;<recently read> \\uspackage ;;l.3 \\uspackage

or even

! LaTeX Error: File `nonexist.sty' not found.;;Type X to quit or <RETURN> to proceed,;or enter new name. (Default extension: sty);;Enter file name: ;! Emergency stop.;<read *> ;         ;l.4\begin               

which makes it really hard to spot the actual issue.

Note also, that we have not talked yet about LaTeX3 error with the format:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! pkgname error: "message"
! 
! Text
! 
! See the pkgname documentation for further information.
! 
! Type <return> to continue.
!...............................................

A simple RegEx just won't do.

Concerning the wikibook definition, I've interpreted that "followed by another line starting with the number" immediately follows the line with !, but I agree that the definition is not quite clear about lines in between. Anyway, why do there have to be differences in

! Undefined control sequence.
\qnumber ->\qfont 
                  \ifnum 9>5{+~}\fi 
l.5 }

vs

! Undefined control sequence.
<recently read> \uspackage 

l.3 \uspackage
              {paralisi}

In particular you want the context of the broken statement \qfont vs \uspackage because that gives you the exact location, which is important in longer strings. Just concatenating everything makes it unreadable (see above). I will look into it further some time to try and improve on extracting the releavant information.

[David Carlisle]

the reason for the difference between the two examples is that the format of a tex primitive error is

1. first line starts ! and has a general description.
2. last line starts l.line number and has the source file context up to the point the error occurred then (if not the whole line) a linebreak showing the part of the line not yet processed.
3. a ? prompt for the user to ask for more help.

between the first and last line can be any number of lines (depending on \errorcontextlines and how many expansion steps occured) of further context.

so your first example shows a full line } at line 5 and two intermediate context lines, the second example shows a partial line \uspackage at line 3, and no intermediate context lines.

[Mast B.]

Tim, I can't force you to fix this bug if you don't want to. I'm still grateful for the work you put in TexStudio.

Cheers.

[Tim Hoffmann]

It's not that I don't want to. It's just that it's very difficult to do it in a reasonable way. This will stay open because I think it's possible and will be fixed, but it takes careful consideration.

Not lastly for this reason we have a synchonization of issues and the complete log, so that you can always easily get the complete context.

[Mast B.]

As you wish. In the meantime, don't you think that any concatenation of the full error (like the ones you posted above) is a hell of a lot better than what TexStudio does now?

[Jan Sundermeyer]

I agree with Tim.
Maybe a better way would be to put the whole error part (without concatenation) as tooltip on the issue, thus avoiding the switch to the log in the cramped space.

[David Carlisle]

given that the interface wants to show the message on one line I don't think catching the whole error message really works well even if you parsed it correctly. How feasible would it be to special case the undefined control sequence error and pick up the last word of the second line and just insert it into what you do now?

So for the one in the original comment here, instead of

Undefined control sequence. }

do

Undefined control sequence (\qfont). }

so you get the type of error, which command is undefined, and some context from the input source file.

Just handling this one case would cover the vast majority of cases where the truncated error message is confusing (as it isn't obviously truncated) that I see on tex forums.

[Mast B.]

I agree with David. Any of the above is better than what TS is currently doing, but David's proposal is a good compromise between my idea of concatenating all lines (I'm happy with lots of tex on one line) and Tim's.

Might we please have an option for this sometime in the future? Show first error line (David's) or full error in one line (mine).

[David Carlisle]

full error on one line isn't a lot of use as the only indication of which command is undefined is the linebreak.

[Mast B.]

@David: I must disagree. First, full error shows more context, which I want. Secondly, as in this case, commands may be defined in other included files, but the compiler only shows the line in the main file, not the actual file where the command is defined. More context is then better to identify the culprit. What's wrong with having an option for this? You can turn it off if you don't want it.

[David Carlisle]

Any chance of progress here? this still comes up most weeks on stackexchange with users getting misleading information this mornong for example https://tex.stackexchange.com/questions/396411/error-begindocument

[Tim Hoffmann]

No progress so far. I'll recheck this later.

Is it safe to assume that the second line (if present and not the l.xx line) will always finish with the unknown command?

Then, I could propose:

1. Use the general description from the first line.
2. If second line is available, use the last word from there.
3. Otherwise use the last word from the l.xx line

[David Carlisle]

yes the undefined command is always the last thing on the first line of the error your proposal looks good to me. Just came by as this came up again on tex.sx...

https://tex.stackexchange.com/questions/399234/why-cant-tex-show-us-the-actual-undefined-control-sequence

[David Carlisle]

This comes up regularly, but again today
https://tex.stackexchange.com/questions/432878/why-is-gathered-undefined