On Thu, 26 Apr 2001, Jarkko Hietaniemi wrote:
>
> You list the particular commands as 'existing functionality'. I think
> this is a mistake, even if you didn't mean it that way, if it was just
> an artifact of your presentation format. I know that breaking
> debugging habits that have been ingrained in at the spinal level may
> be hard to break, but thinking that "we must save t" (or any particular
> command) is in my opinion the wrong to approach a new design.
>
> Rather, look at the higher level concepts; take a look, nay, several
Ok, this is a good idea. I'll go back and do it again in that
light.
> Collect and group the concepts. Take a look at graphical debuggers
Some of the things I suggest actually have come from
graphical-land...e.g. the "dump a class hierarchy" feature.
> see it.) The debugger must be able to see two scopes at the same time:
> its own and the debuggee's.
Could you expand on this?
> Finally my personal pet peeve that I wish would be banished: 'h'
> should give just a short summary, not the full story that needs
> a pager.
Okay...this is exactly the reason that I suggested including a
default pager, but it would probably actually be better if "h" gave a
short summary and "h h" gave the complete story, requiring a pager...which
would, of course, be supplied.
Dave
