Michael Bynum writes:

This has burned me too. It would be nice if the errors were more prominent, perhaps repeated at the end of the output? Mike

While we are on the subject, is it possible to make it "die" when incorrect (non-existent) options are passed to a context command? Is there any way at all of knowing if the option did anything (even by examining the log?) -- John Devereux

Wolfgang Schuster writes:

Am 12.03.2009 um 15:06 schrieb John Devereux:

...

Michael Bynum writes:

...

This has burned me too. It would be nice if the errors were more prominent, perhaps repeated at the end of the output? Mike

While we are on the subject, is it possible to make it "die" when incorrect (non-existent) options are passed to a context command? Is there any way at all of knowing if the option did anything (even by examining the log?)

No, this is not possible and even such a feature would increase the compile time a lot, e.g. I used list with valid names in a earlier version of my letter module and it was 30% slower than the current version and now imagine what happens if you check each key in a assignment list.

OK. It seems strange (coming from a programming background). If it is only the compile time, then a command line switch might be an option. (But it sounds like it is inherently hard to do, now). -- John Devereux

Am 12.03.2009 um 16:20 schrieb John Devereux:

Wolfgang Schuster writes:

...

Am 12.03.2009 um 15:06 schrieb John Devereux:

...

Michael Bynum writes:

...

This has burned me too. It would be nice if the errors were more prominent, perhaps repeated at the end of the output? Mike

While we are on the subject, is it possible to make it "die" when incorrect (non-existent) options are passed to a context command? Is there any way at all of knowing if the option did anything (even by examining the log?)

No, this is not possible and even such a feature would increase the compile time a lot, e.g. I used list with valid names in a earlier version of my letter module and it was 30% slower than the current version and now imagine what happens if you check each key in a assignment list.

OK. It seems strange (coming from a programming background).

If it is only the compile time, then a command line switch might be an option. (But it sounds like it is inherently hard to do, now).

Yes, something like \traceassignments is possible but you need table with all valid values (makes only sense in MkIV) and even then a lot of thing had to be checked. Take as example \localframed (the internal command for \framed etc.), you could store all of it valid keys in a table and check against them but what should happen with high level commands like \externalfigure which use \localframed but use itself only a subset of the keys, do you want to generate a error message for the ignored keys (which are valid \localframed keys) or make a exception. Another thing are values for the keys, \setuplayerframed is a combination of \setlayer and \framed and you can set the same values for both with \setlayerframed[...][offset=...] or different values for each part with \setlayerframed[...][offset=...][offset=...] but in the first case not all values are accepted, e.g. 'offset=none' causes a error message for \setlayer but is a legal setting for \framed. Wolfgang

Hans Hagen writes:

John Devereux wrote:

...

Wolfgang Schuster writes:

...

Am 12.03.2009 um 15:06 schrieb John Devereux:

...

Michael Bynum writes:

...

This has burned me too. It would be nice if the errors were more prominent, perhaps repeated at the end of the output? Mike While we are on the subject, is it possible to make it "die" when incorrect (non-existent) options are passed to a context command? Is there any way at all of knowing if the option did anything (even by examining the log?) No, this is not possible and even such a feature would increase the compile time a lot, e.g. I used list with valid names in a earlier version of my letter module and it was 30% slower than the current version and now imagine what happens if you check each key in a assignment list.

OK. It seems strange (coming from a programming background).

If it is only the compile time, then a command line switch might be an option. (But it sounds like it is inherently hard to do, now).

i can probably implement some kind of checking (runtime switch, or maybe even switch at format generation time) but i will do so only when i've completely split of the mkiv code

Hi Hans, I really don't want to create work if you think it is not worthwhile. But - as a non-texpert - I do think it is a problem. It is compounded by: - Many command options are not documented, so one experiments a lot - Excess whitespace not only invalidates options, it does so silently. The combination is *very* unexpected, and I don't think it is that well known. At any rate I used context for 5 years without realising something pretty fundamental! (Is it even mentioned in the manual?) Anyway, the option then has no effect, so one tries a few more... Thanks, -- John Devereux

Hans Hagen writes:

John Devereux wrote:

...

I really don't want to create work if you think it is not worthwhile. But - as a non-texpert - I do think it is a problem.

It is compounded by:

- Many command options are not documented, so one experiments a lot

so .. help us with that -)

I thought you might say that :) I am hesitant to spread my ignorance, but I try to help where I think I can.

...

- Excess whitespace not only invalidates options, it does so silently. The combination is *very* unexpected, and I don't think it is that well known. At any rate I used context for 5 years without realising something pretty fundamental! (Is it even mentioned in the manual?)

Anyway, the option then has no effect, so one tries a few more...

well, it has to do with what one wants to set up with an option:

a=b,c=d,e= f,g = h

key=value with no space in between; spaces in between will be part of the key or value

of course i could be more liberal but it involves a bit more parsing; keep in mind that we had this key/value system right from the start (long ago) and then speed was more an issue than on todays machines

Understood. I *did* in fact use Context productively for the 5 years, so maybe it is not such a big deal. -- John Devereux

Michael Bynum wrote:

This has burned me too. It would be nice if the errors were more prominent, perhaps repeated at the end of the output?

ok, i do repeat it now; aborting the run is no options as some modules might have been removed due to integration in the core Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Aditya Mahajan wrote:

On Sat, 14 Mar 2009, Hans Hagen wrote:

...

Michael Bynum wrote:

...

This has burned me too. It would be nice if the errors were more prominent, perhaps repeated at the end of the output?

ok, i do repeat it now; aborting the run is no options as some modules might have been removed due to integration in the core

Then the user should know that and update the source file :-). It can be a normal error prompt, the one where you get a question mark and are asked if you want to continue or abort (rather than enter the file name prompt of \input).

I do feel that for user modules, there should be an error when the module is not found. If you do not want the above behaviour as a default, it could be a configurable option.

needs thinking ... i don't want fully automated flows to abort unseen configuration is an option but again i first need a mechanism for that (and we should all agree on 'what is fatal' and not) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On Sun, Mar 15, 2009 at 5:23 PM, Hans Hagen wrote:

...

I do feel that for user modules, there should be an error when the module is not found. If you do not want the above behaviour as a default, it could be a configurable option.

i'm thinking of something \enableoptions[...] (analogue to the mkiv \enabletrackers) but then we need to move more configuration options to this mechanisms, so it will be something mkiv only

You could move all tracing parameters in a comma list but I prefer than a different name like \enabletracing[table,layer,...]. For the modules you could use the two command \enablemodulenotfounderror with a 'wait' message on the termal and \disablemodulenotfounderror (default) to ignore missing modules. Wolfgang