At 12:01 PM 4/27/2001 -0700, Dave Storrs wrote:
>On Fri, 27 Apr 2001, Dan Sugalski wrote:
> > At this stage, it might be better to go through and pull out the concepts
> > and capabilities we need, rather than get into the details of user
> > interface. Knowing, for example, that we need to provide help is more
> > important at this stage than knowing that the 'h' key provides it. (The
> > details arguably obscure things a bit more than we'd like at the moment)
>
> Agreed...which is why I didn't include user-interface for any of
>the new suggestions. The only elements that have a command key assigned
>are the ones in the "Existing functionality" section--and that section is
>basically just a cut'n'paste of the output from the 'h' command in the
>present debugger.
Right. What I'm thinking would be a good place to get to is a list of the
functionality that the debugger needs to provide or have available to it
from the interpreter, rather than the actual interface to the user. (Which
is important, but a separate issue)
> The fact that both you and Jarkko pointed this out raises a good
>question though...do we want to break backwards compatibility by, for
>example, reassigning some of the command keys to other commands, or
>deleting some of the less-used commands or variables? The pros and cons
>are fairly obvious, but how do people feel?
I don't particularly want to break backwards compatibility, but neither do
I care to be bound by it. We're unlikely to be using any code from perl 5's
debugger. I don't want to get into interface design at the moment yet,
though. I think we're still at the "What functionality should the
interpreter/compiler/parser provide to the person writing a debugger" phase.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
