* "Tobias C. Rittweiler" 87pr8bd84f.fsf@freebits.de : Wrote on Sun, 25 Oct 2009 12:29:36 +0100: | 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.
No, my Fnn and other keys are bound to other things. I come from CMUCL where I hit a single digit (a number) to invoke a restart. In this scheme if I'm facing 10+ restarts, the restart the sldb user gets the dick. he have to hit 2 digits,
When I design a nested restart-cases or restart binds for the sldb user, I want to provide a consistent restart mechanism. I have code where the innermost restarts always stay the same. However the total number of restarts may vary. Earlier I could count on the user not having to look and pick out a number to get atthe innermost restart. Now the user gets dick, For any restart provided by restart-case he has to READ all restarts, and pick a number, which is NOT the easiest number to type. |> 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.
The implementations work as expected when designing nested RESTART-CASES.
|> 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.
Top is always 0. Next is 1, next 2. Stack grows down.
[example snipped, I'll check maybe next month]
| 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.)
No, I want to use digits. I need all other keys for other purposes. The argument applies against your change: Can't you just use a custom Fnn binding for the RETRY-RESTART is so important instead of messing with the restart order supplied from the implementation?
| 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
No I cant see it. Really.
| 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."
more like `I invented the new way so I like it.' If you had tried the old way instead of rewriting it, you would have liked that too, AND not screwed all other usages.
-- Madhu