Hi, ConTeXt used to recover better from errors. Consider the following file: ============= \xyz \abc \starttext HELLO \stoptext ============= Running ConTeXt ver: 2019.03.21 21:39 MKIV beta fmt: 2019.3.26 int: english/english would catch both "Undefined control sequence" errors before exiting with the message "mtx-context | fatal error: return code: 256". (I either press enter to move to the next error, or I use the --nonstopmode option.) Now with ConTeXt ver: 2019.04.13 17:01 MKIV beta fmt: 2019.4.15 int: english/english, even when I do not supply the --nonstopmode option, ConTeXt exits abnormally with the same error message right after discovering the first undefined control sequence. The old "?" TeX prompt allowing once to fix the misspellings, etc. does not appear at all. Has some defaults changed? Is it possible to get the old behavior? Thanks, ~MHB
On Mon, 15 Apr 2019 23:11:17 -0400
Mohammad Hossein Bateni
Hi,
ConTeXt used to recover better from errors. Consider the following file:
============= \xyz \abc
\starttext HELLO \stoptext =============
Running ConTeXt ver: 2019.03.21 21:39 MKIV beta fmt: 2019.3.26 int: english/english would catch both "Undefined control sequence" errors before exiting with the message "mtx-context | fatal error: return code: 256". (I either press enter to move to the next error, or I use the --nonstopmode option.)
Now with ConTeXt ver: 2019.04.13 17:01 MKIV beta fmt: 2019.4.15 int: english/english, even when I do not supply the --nonstopmode option, ConTeXt exits abnormally with the same error message right after discovering the first undefined control sequence. The old "?" TeX prompt allowing once to fix the misspellings, etc. does not appear at all.
Has some defaults changed? Is it possible to get the old behavior?
Thanks, ~MHB
I much prefer the new behavior, for the previous prompt was pretty useless and there was little point going on without correcting an earlier error. Furthermore, the model would often leave a furtive process running in the background following a keyboard interrupt (especially on Mac OSX). The new process does not do this. Alan
On 4/16/2019 6:28 AM, Alan Braslau wrote:
On Mon, 15 Apr 2019 23:11:17 -0400 Mohammad Hossein Bateni
wrote: Hi,
ConTeXt used to recover better from errors. Consider the following file:
============= \xyz \abc
\starttext HELLO \stoptext =============
Running ConTeXt ver: 2019.03.21 21:39 MKIV beta fmt: 2019.3.26 int: english/english would catch both "Undefined control sequence" errors before exiting with the message "mtx-context | fatal error: return code: 256". (I either press enter to move to the next error, or I use the --nonstopmode option.)
this 'go to next error' instead of 'fix it now' dates from the time when a run could take hours and the console (often) was a paper terminal so then it made sense to collect a couple of errors and / or go on for a large macro package like context where an error nearly always will lead to a bad output file it makes not much sense ... fix the error and rerun ...
Now with ConTeXt ver: 2019.04.13 17:01 MKIV beta fmt: 2019.4.15 int: english/english, even when I do not supply the --nonstopmode option, ConTeXt exits abnormally with the same error message right after discovering the first undefined control sequence. The old "?" TeX prompt allowing once to fix the misspellings, etc. does not appear at all.
Has some defaults changed? Is it possible to get the old behavior?
Thanks, ~MHB
I much prefer the new behavior, for the previous prompt was pretty useless and there was little point going on without correcting an earlier error. Furthermore, the model would often leave a furtive process running in the background following a keyboard interrupt (especially on Mac OSX). The new process does not do this. Indeed and on all platforms tex could end up in a state of 'hanging somewhere around in the background' (enforcing some hard manual kill) which then also locks files (like the output file).
This is way more robust (and i should have done it sooner). If you don't want it you can disable it (but you're on your own then): \disabledirectives[system.quitonerror] There are also oler options, like \enabledirectives[system.showerror] which could pop up a browser and alike. (I'm actually considering dropping the interactive mode completely or maybe replacing it by a lua driven one if i need it, which i never do.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
Which one is better is certainly subjective :) Maybe we could get the old
TeX-y behavior via a switch or the other way around?
Alan, allow me to disagree with your assertions, though. Here are a few
reasons:
1) You could correct a spelling mistake on the prompt (as in original TeX),
although this is rarely done these days.
2) You could use the --nonstopmode or --batchmode to not get the prompt,
and not have the lingering background process (Mac bug?).
3) You could see a collection of errors which might help you in fixing them
altogether without having to run context again and again finding one error
at a time. (Same thing with compiling a C/C++ code, and getting a list of
many errors at once.)
4) There are many "errors" and "warnings" that context does not stop on.
You could perhaps claim moving on from those is also useless :) Just to
give some examples: missing modules, fonts, glyphs in fonts, etc.
So let me rephrase my original question: Is this change in behavior
intended? If so, is it possible to get the old behavior (specially for
nonstopmode) via some switch?
Thanks a lot,
~~MHB
On Tue, Apr 16, 2019 at 12:28 AM Alan Braslau
On Mon, 15 Apr 2019 23:11:17 -0400 Mohammad Hossein Bateni
wrote: Hi,
ConTeXt used to recover better from errors. Consider the following file:
============= \xyz \abc
\starttext HELLO \stoptext =============
Running ConTeXt ver: 2019.03.21 21:39 MKIV beta fmt: 2019.3.26 int: english/english would catch both "Undefined control sequence" errors before exiting with the message "mtx-context | fatal error: return code: 256". (I either press enter to move to the next error, or I use the --nonstopmode option.)
Now with ConTeXt ver: 2019.04.13 17:01 MKIV beta fmt: 2019.4.15 int: english/english, even when I do not supply the --nonstopmode option, ConTeXt exits abnormally with the same error message right after discovering the first undefined control sequence. The old "?" TeX prompt allowing once to fix the misspellings, etc. does not appear at all.
Has some defaults changed? Is it possible to get the old behavior?
Thanks, ~MHB
I much prefer the new behavior, for the previous prompt was pretty useless and there was little point going on without correcting an earlier error. Furthermore, the model would often leave a furtive process running in the background following a keyboard interrupt (especially on Mac OSX). The new process does not do this.
Alan
On 4/16/2019 11:51 AM, Mohammad Hossein Bateni wrote:
Which one is better is certainly subjective :) Maybe we could get the old TeX-y behavior via a switch or the other way around?
Alan, allow me to disagree with your assertions, though. Here are a few reasons: 1) You could correct a spelling mistake on the prompt (as in original TeX), although this is rarely done these days. 2) You could use the --nonstopmode or --batchmode to not get the prompt, and not have the lingering background process (Mac bug?).
batchmode doesn't give much on the console, nonstopmode could runs forever and generate gigs of log files before you find out i've run into 'stuck in the background' runs on windows, osx and linux ... (even in batch mode)
3) You could see a collection of errors which might help you in fixing them altogether without having to run context again and again finding one error at a time. (Same thing with compiling a C/C++ code, and getting a list of many errors at once.)
how often does that happen ... in most cases an error (say a missing }) will have side effects that either obscure other errors or when you hit return suggest errors that are not there; sometimes when a } is expected you get some confusing mode error that is hard to get out
4) There are many "errors" and "warnings" that context does not stop on. You could perhaps claim moving on from those is also useless :) Just to give some examples: missing modules, fonts, glyphs in fonts, etc.
So let me rephrase my original question: Is this change in behavior intended? If so, is it possible to get the old behavior (specially for nonstopmode) via some switch?
it is definitely intended (i just didn't consider it before otherwise it would have been there already for a decade) and you can switch it off (see previous mail) (btw this behaviour also permits a rather robust way to make sure no invalid pdf file results) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Tue, 16 Apr 2019 05:51:00 -0400
Mohammad Hossein Bateni
1) You could correct a spelling mistake on the prompt (as in original TeX), although this is rarely done these days.
As you said, doesn't happen.
2) You could use the --nonstopmode or --batchmode to not get the prompt, and not have the lingering background process (Mac bug?).
No, a consequence of the model. Lingering background processes often occurred after interrupting a run using a keyboard interrupt.
3) You could see a collection of errors which might help you in fixing them altogether without having to run context again and again finding one error at a time. (Same thing with compiling a C/C++ code, and getting a list of many errors at once.)
As Hans said, such errors are rarely limited in scope and without side consequences, so a waste of time to "collect" multiple errors.
4) There are many "errors" and "warnings" that context does not stop on. You could perhaps claim moving on from those is also useless :) Just to give some examples: missing modules, fonts, glyphs in fonts, etc.
Garbage in-garbage out. By the way, I "rarely" make errors, ever, so I'm not really affected by this change. :-) My favorite, however, was trying to launch X(11) from the console (by typing one too many X)! Alan
participants (3)
-
Alan Braslau
-
Hans Hagen
-
Mohammad Hossein Bateni