Gary King gwking@metabang.com writes:
Although it makes perfect sense, I find it irritating that the number for the [abort-request] restart in SLDB depends on how many other restarts are active. For clarity's sake, here is a list of restarts:
Restarts: 0: [RETRY] Retry performing #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6>. 1: [ACCEPT] Continue, treating #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6> as having been successful. 2: [ABORT-REQUEST] Abort handling SLIME request. 3: [ABORT-BREAK] Reset this process 4: [ABORT] Kill this process
In this case, I should type '2' to give up on this request and try something else. In other cases, however, I might need to type '7' or 5' or whatever. This means that I have to look and see what to type every single time I hit an error (and, hey, I hit a lot of errors in my code!). It also scares me that I could misread and type the key for [abort-break] or [abort] by accident. Here is my suggestion as to
Isn't q bound to ABORT-REQUEST for just this reason?
It may not be immediately obvious from the documentation that it is equivalent, but it indeed is. Maybe just the documentation needs to be improved?
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."