[slime-devel] Restart Numbering

[Madhu]

* "Tobias C. Rittweiler" <87k4yjeuhl.fsf at 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