* Tobias C. Rittweiler [2009-10-25 09:41+0100] writes:
- Reversing the printed order of restarts means, when you have more than a handful of restarts, you cannot restart 0 or 1 (the "first restart the user would want to invoke"), because it is hidden; SLDB only lists the first few restarts, you have to move the cursor down to the "--more--" button and hit RET to see more restarts. (This slime UI element is an intensely painful part of slime, subject of a different rant).
There's a slight misunderstanding of my change, I think: The restarts _themselves_ are _not_ reversed, just their numbering is reversed; it's done this way exactly for reasons of giving importance to locality.
An argument could be made that the hot end of the stack is more important and that the good keys should be used for the top of the stack.
I can see that quickly accessible restarts at the bottom are nice too but Slime has keys for those already. Why then burn all keys for the bottom?
And if you think of it, the reversed numbering actually does make sense (beyond its technical advantage) as it reflects the stack-like behaviour of binding.
Forth's PICK numbers stack items starting from the top and it would be completly useless if the numbering were reversed. Starting from the top obviously makes more sense to Forthers.
[I think I agree on the --more-- part, but I don't see it that often myself. I'd feel content with a keybinding which shows full detail of the restart list and the backtrace.]
Look up sldb-initial-restart-limit, you bunch of whiners.
[...]
Quick example: Slime's RETRY restart which is wrapped around REPL requests will now always be numbered 2 on SBCL.
[...]
Notice that you can easily add your own symbolic bindings for your application-specific restarts by means of `sldb-invoke-restart-by-name'.
Maybe sldb-invoke-restart-by-name should have an option to start the search from the bottom so that you can invoke your RETRY restart more easily.
Helmut