| 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:
1. 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.
2. 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).
3. 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.')
-- Madhu