Madhu enometh@meer.net writes:
- "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).
Yes, I meant that you can easily define keybindings to functions which use sldb-invoke-restart-by-name. E.g. you could use the Fnn keys.
|> 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.
I'm not sure there really has been given much thought to this. It's more likely that implementations just numbered the return value of COMPUTE-RESTARTS without a detailed decision making process.
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
You really orientate yourself on the actual numbers? I orientate myself on the order of appearance -- i.e. what comes on top has a more recent binding.
| 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.
No that does not seem to be right. I'll demonstrate old and new behaviour with examples below.
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,
Yeah, that's why I suggest to to solidify the interface with custom Fnn bindings and not to rely on the order. (Fnn bindings on top of invoke-restart-by-name would of course always invoke the most recently established restart -- dunno if you actually tend to have lots of identically-named restart at the same time.)
|> 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
Ah. Yes, I can see your point now. OTOH, the new behaviour does have a technical advantage (see below) and, while it's probably true that if I had been accustomed to the old way as much as you, I wouldn't have made the change. So, erm, this kind of boils down to: "Sorry that I've screwed you, but I haven't screwed me, and I like the new way."
Placing
;; Keys 0-9 are shortcuts to invoke particular restarts. (dotimes (number 10) (let ((fname (intern (format "sldb-invoke-restart-%S" number))) (docstring (format "Invoke restart numbered %S." number))) (eval `(defun ,fname () ,docstring (interactive) (sldb-invoke-restart number))) (define-key sldb-mode-map (number-to-string number) fname)))
into your .emacs should get you back the old behaviour.
| 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.
That's unfortunately not true. Let me demonstrate:
Old behaviour:
(length 12)
The value 12 is not of type SEQUENCE. [Condition of type TYPE-ERROR]
Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [TERMINATE-THREAD] Terminate this thread (...)
(with-simple-restart (TCR-RESTART "Foof.")
(length 12))
The value 12 is not of type SEQUENCE. [Condition of type TYPE-ERROR]
Restarts: 0: [TCR-RESTART] Foof. 1: [RETRY] Retry SLIME REPL evaluation request. 2: [ABORT] Return to SLIME's top level. 3: [TERMINATE-THREAD] Terminate this thread (...)
New behaviour:
(length 12)
The value 12 is not of type SEQUENCE. [Condition of type TYPE-ERROR]
Restarts: 2: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 0: [TERMINATE-THREAD] Terminate this thread (...)
(with-simple-restart (TCR-RESTART "Foof.")
(length 12))
The value 12 is not of type SEQUENCE. [Condition of type TYPE-ERROR]
Restarts: 3: [TCR-RESTART] Foof. 2: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" RUNNING {C115E01}>)
As you can see, in the new behaviour, shared restarts established in the same code-path will now be numbered identically. It's true that I'm screwing you, but I hope I was able to give reason for doing so.
-T.