> I can think of many different ways to make the stepper<->definition > correspondence manifest. As John said, I once suggested that the code > should be reduced in-place, in the definition window. Shriram doesn't > like that idea (but he has never bothered to say why.)
That's right, I didn't. Here's why. It introduces subtle state into the editor. If you start stepping, and then try to Save, are you saving the stepped version or the original? If you start stepping, forget that you are doing that, and then start editing, what are you editing? If you step, does it affect the unsavedness of the editor? (Presumably not.) If I have a textual program, and step, does it next save in graphical format? (I wouldn't want that.) One way to prevent some of the more egregious problems is to make stepping a mode. That brings its own problems -- how do you make it not suck, how do you focus attention on it, etc. I think people have a clear model of what an editor is: it's like Word, like the text box of GMail, etc. Each one offers some highlighting feedback and some rich-text editing -- but it's just an editor. It's not a place where programs run. Putting the stepper into the editor in a model way really messes with that. I certainly agree with you (and have always agreed with you, for the many years we've talked about this) that losing the correspondence to the source program is a problem. But I don't think putting it in the editor is the solution. I do find Ryan's suggestion -- to use highlighting in the editor -- very intriguing. We already highlight in the editor, and it's pretty unintrusive. In that style, it might even be possible for a stepper window to combine highlighting with showing *just* the current redex, and giving the user the option of expanding the scope of attention (ie, show me more of the current expression when I want it). Shriram _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
