[Changeset] Re: Q: Low hanging fruit?

[John W. Eaton]

On  9-May-2008, David Bateman wrote:

| Bill Denney wrote:
| > Out of curiosity, how could a user find them without knowing the
| > functions are there already?  I can't find those functions with which,
| > help, or iskeyword.  It seems like they should show up somehow
| > (especially with help).  I could add them to the help documentation for
| > keyboard, but that doesn't help too much if they don't have their own
| > help pages.
| 
| 
| Good point. There is nothing to stop these being easily documented with
| DEFCMD functions in debug.cc though they are trapped in
|  to makeinput.cc(get_user_input). However, if we do that it probably
| makes sense them matlab compatible. The current behavior is that "dbstep
| in" in matlab is the equivalent of "dbsrtep" in Octave, and "dbstep" in
| matlab is teh equivalent of "dbnext" in Octave. Octave doesn't support
| the "dbstep N" or "dbstep out" syntax.
| 
| The attached patch makes the dbstep command matlab compatible and adds
| the dbquit command. However this change should be documented in the NEWS
| file for 3.1 as it changes the behavior of the dbstep.

Instead of adding ad-hoc parsing to the get_user_input function, I
think it would be better to make dbstep a normal function that
examines its arguments and sets some global variables that are used by
the get_user_input function.  Is that possible?  It might also be
worth trying to use the normal parse/eval loop instead of eval_string
so that we can accept multiple line input in debug mode.

jwe