If you read carefully upthread I've stated in this thread is MY experience and MY usage scenario, which I have been carefully qualified. What makes you think I've extrapolated anything?
the fact that you speak up zealously after reading a commit log and admitting that you not even tried the patch. because it's either the result of extrapolation of you preferences to others, or ignoring the fact that there are other preferences. i don't think you ignore others, so i kinda assume the former. (but don't worry, the latter is also very human, i also do that sometimes, unfortunately).
Tobias seems to recognize that the others usage scenarios are results of miscoding/not understanding how restart contours work.
sure. so you say that it's a mistake that stefil installs some restart when a test (an instrumented defun) is invoked, like rerun that specific test.
keep in mind that tests (defun's) can call each other to any number of times, and i in no ways want to keep track of the available restarts to wrap places where an error can from with a reversed (restart-case ...). let alone it's not possible either because errors can come from anywhere, not only from stefil's own assertion macros.
for me, tcr's example of the restart-case around the error call was meant to be irony. errors can come from just about anywhere, not only from your own error calls.
|> And if we are at it, why does SLDB give a number for restarts which do |> already have a 1 keystroke keybinding? |> q, a, c could just be written in place of the numbers, and those |> numbers could be saved for other restarts... but this would be my |> personal taste and I'm sure you can find arguments in your taste |> against it.
Because of consistency, you always want to invoke the innermost restart with 0. This is not always Q.
no, sorry, but i don't. :)
because of consistency *i* always want the kill-thread restart be 0.