* "Tobias C. Rittweiler" 87k4yjeuhl.fsf@freebits.de : Wrote on Sun, 25 Oct 2009 09:41:10 +0100:
[quoting you out of order]
| Notice that you can easily add your own symbolic bindings for your | application-specific restarts by means of `sldb-invoke-restart-by-name'.
The point is for invoking a restart with a single (or as few keystrokes as possible).
|> 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. | | 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.
No, I think this is a general design consideration for all those implementations. If you have concentric circles, you start numbering the innermost one 0 and the next circle 1 etc.
If I have several restarts with same name, they all look the same when printed. Then one would rely on the numbering to determine which is the correct `continue' restart (say) to invoke. This order should not be messed up with
|> 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). | | 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.
I have not updated slime to your latest changes, so maybe I'm missing something, but I see the slime established restarts at the bottom of the list hidden by --more--, while application restarts are at top.
| 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.
Does it? I'm not sure Earlier the slime established restarts (the first circle) numbered 0 at the top. (first circle), then application established restarts, etc.
Right now, (as usual :) I am working on reverting these changes for my setup to get the old behaviour back, I'll check again]
| | [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.]
I see it all the time, I use the debugger as a (damn useful!) dungeon-User Interface,
|> 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.') | | 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".
Not q, 0. We are talking of numbers (reachable in the numkeypad) here besides the `continue' i want may not be the `continue' restart which slime would invoke with `c', and now I cannot use the numbering to decide which is earlier and which is later
| 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?
No, I cannot see how this changed from previous behaviour. SLIME established restarts always had consistent numbers.
-- Madhu