Madhu enometh@meer.net writes:
| diff -u slime/ChangeLog:1.1880 slime/ChangeLog:1.1882 | | +2009-10-23 Tobias C. Rittweiler tcr@freebits.de | + | + Restarts in SLDB are now numbered reversely. The rationale is that | + always-existing restarts are likely to be associated with the same | + number now. | + | + * slime.el (sldb-insert-restarts): Number restart reversely. | + (sldb-restart-number-for-swank): New; recompute the unreversed | + number for the swank side. | + (sldb-restart-number-at-point): Previously `sldb-restart-at-point'. | + (sldb-invoke-restart): Adapted accordingly.
I see 2 issues here, but I think the idea is bad for several reasons including:
It fails to meet the stated purpose. Always existing restarts (provided by slime already had the same number); If the goal was to match the order of presentation with what the implementation debugger would provide consider
Inner restarts have lower numbers than outer restarts. See how implementations number the restarts in
(with-simple-restart (barf-outer "barf") (with-simple-restart (foo-inner "foof") (error "bARF")))
Every implementation's debugger numbers a restart for FOO-INNER at a smaller number than the restart for BARF-OUTER. SLDB now reverses this ordering.
I think this is a true complaint for the case when you're used to use the native debugger equally often as the Slime debugger. I'm eager to say that this is probably the unusual case for users of Slime, but I'm solely extrapolating from my own.
- 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.
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.
[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.]
- This is confusing to my muscle memory which has been trained to hitting 0 for the first restart expected from the lisp program being evaluated (an argument i started making in 2008-08-25, but did not complete). Consider the the numeric keypad. However I assume you did want to ensure the restart 0 was `return to slime top-level.')
No not because of that: notice that `q' is bound to "return to toplevel", and `a' is bound to "invoke abort", and `c' to "invoke continue".
The point of the change is that the numbering of restarts is almost static for errors resulting from similiar code paths. Does this make sense?
Quick example: Slime's RETRY restart which is wrapped around REPL requests will now always be numbered 2 on SBCL.
-T.
PS.
Notice that you can easily add your own symbolic bindings for your application-specific restarts by means of `sldb-invoke-restart-by-name'.