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
capfredfJul 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
greg23 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?
greg23 hours agohttps://www.racket-mode.com/#racket_002dtestgreg23 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.
greg23 hours agohttps://www.racket-mode.com/#racket_002derror_002dcontextgreg23 hours ago
If you mean something else by "error traces" please let me know?
capfredf22 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)
greg19 hours ago
Ah OK I understand now.
greg19 hours ago
There's no such option for racket-test now.
greg19 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).
greg19 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)
capfredf32 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.
greg17 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.
greg17 minutes ago
Neither is quite backward compatible, but maybe that's OK?
greg16 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).
greg16 minutes ago
If you prefer either, or have some 3rd or more ideas, please let me know
@capfredf
.
capfredf14 minutes ago
I prefer the 2nd as well (edited)
Make
racket-testuse similarC-ucommand prefixes approach asracket-runandracket-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-contextor use thehighi.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
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)