Wrongly suggesting args in lexicographical order instead of definition order... The tests were unfortunately only examplifying situations where the fields where also defined in lexicographical order... thus never really showing the issue. It came up in the real world, though. Whoopsie.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
While the feedback for human users is mostly the same, it does in fact
matter for the LSP since the quickfix will be different depending on
whether we look for a top-level identifier or if we look for a
constructor.
The typical case we see in the stdlib is the `VerificationKey` and
`Script` constructors for `Credential`, often being mixed with
their types counterparts in aiken/crypto!
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
1. A new option `show_json_schema` which, when enabled, will print the JSON schema of the command output if the target isn't an ANSI-capable terminal.
2. Some modifications to the help message and error handling for the new option `show_json_schema`.
This is now done to avoid flooding the help screen with an entire
JSON schema. Plus, it makes the schema more easily exportable as an
actual JSON schema.
Before this commit, we would require those target a specific handler,
whereas they are in fact global to the entire validator.
So now, we recover the behaviour from before where we default to the
only available validator when there's no ambiguity.
Note that this also solves the need for repeatedly applying parameters
to each handler of a parameterized validator. The command now
rightfully apply parameters to each corresponding handler.
It has somehow always annoyed me that we have --trace_level (with 'trace' first) and --filter_traces (with traces, plural and last). Given that these two options are almost always used together, the inconsistency is frustrating.
Matthias Benkort