More error context options for racket-test

[greghendershott]

Make racket-test use similar C-u command prefixes approach as racket-run and racket-run-module-at-point:

With C-u prefix use errortrace for improved stack traces.
Otherwise follow the `racket-error-context' setting.

With C-u C-u prefix also run the
tests with coverage instrumentation and highlight uncovered code
using `font-lock-warning-face'.

(With the run commands, the double C-u prefix means to annotate for step debugging. It makes sense for that to differ from racket-test.

Where it makes sense for them to be consistent is the no-C-u or single C-u cases -- either follow racket-error-context or use the high i.e. errortrace more-context setting for this one invocation of the command.)

---

Via Racket Slack discussions with @capfredf

capfredf
Jul 20th at 3:50 PM
@greg
is there a config to tweak so that racket-mode shows only error traces when running racket-test? Most of the time, I don't need coverage. (edited)
16 replies
greg
23 hours ago
Instrumenting for coverage only happens if you use a C-u prefix for the racket-test command, so just don't use that prefix?
greg
23 hours ago
https://www.racket-mode.com/#racket_002dtest
greg
23 hours ago
I'm not certain what you mean by error traces. For the run commands in general, racket-error-context controls whether it gets errortrace style instrumentation to have more details for error message "Context:" displays.
greg
23 hours ago
https://www.racket-mode.com/#racket_002derror_002dcontext
greg
23 hours ago
If you mean something else by "error traces" please let me know?
capfredf
22 hours ago
I wasn't clear. It looks to me that the c-u prefix for racket-test adds both instrumenting for coverage and better stack trace. I was asking if there is a config to toggle off showing coverage, i.e. make the c-u prefix for racket-test behave the same way it does for other commands, such as racket-run-module-at-point (edited)
greg
19 hours ago
Ah OK I understand now.
greg
19 hours ago
There's no such option for racket-test now.
greg
19 hours ago
But keep in mind that plain racket-test (without the coverage stuff) is effectively the same as doing racket-run-module-at-point with point inside some test submodule. And you could use C-u with that (to get the better errortrace context).
greg
19 hours ago
So that would be my suggested hack or work-around, until/unless racket-test gets some enhancement. idk, maybe plain racket-test should just do the errortrace context automatically, as if it set racket-error-context to 'high temporarily. I don't see a downside; assuming that's OK that would be straightforward. (edited)
capfredf
32 minutes ago

But keep in mind that plain racket-test (without the coverage stuff) is effectively the same as doing racket-run-module-at-point with point inside some test submodule. And you could use C-u with that (to get the better errortrace context).

Thanks for the pointer. if I am editing test cases in the test submodule, then this is my go-to approach. However, when I am editing main parts of my code, racet-test is handier.
greg
17 minutes ago
What do you think about these two choices:1. Plain, racket-test (without C-u) should just always use high for racket-error-context, that is more, errortrace context.OR2. Plain racket-test remains the same, follows the racket-error-context variable.
C-u racket-test means more, errortrace context.
C-u C-u racket-test means full coverage.
greg
17 minutes ago
Neither is quite backward compatible, but maybe that's OK?
greg
16 minutes ago
The 2nd option seems better to me, "clean sheet of paper", it's closer to how racket-run-module-at-point works. (However it's even less backward-compatible).
greg
16 minutes ago
If you prefer either, or have some 3rd or more ideas, please let me know
@capfredf
.
capfredf
14 minutes ago
I prefer the 2nd as well (edited)