Re: [RFC][python] Add support for commands implemented in Python

[Tom Tromey <tromey@redhat.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

>> +@var{argument} is the argument to the command.  The argument
>> +ordinarily is a string, but may be @code{None}, meaning that there was
>> +no argument.

Daniel> Any opinion on making it always a string?  The 'do I get NULL
Daniel> or an empty string?' ambiguity shows up every time I write a
Daniel> new command in C.

An empty string would be fine by me.  I initially chose None to
parallel the C API, but it isn't clear how useful that is.  An empty
string is friendlier and doesn't seem to lose anything important.

>> +  /* For a prefix command, this is the list of sub-commands.  */
>> +  struct cmd_list_element *sub_list;

Daniel> What's sub_list for?  There's *command->prefixlist too.  Overall, I'm
Daniel> confused about why prefix commands are 'special' here.  When core GDB
Daniel> adds a command, it doesn't need any new code to handle it as a prefix;
Daniel> just calls add_prefix_cmd.  I'd expect to do the same here but fill in
Daniel> a local FUN.

I might be confused here.

The reason I wrote things this way is because elsewhere in gdb there
are global cmdlists which are passed by address to the various add_*
functions.  The 'prefixlist' field of the prefix command points to one
of these globals.

E.g.: in breakpoint.c, there is a global breakpoint_set_cmdlist.  The
"set breakpoint" prefix command is constructed:

  add_prefix_cmd ("breakpoint", class_maintenance, set_breakpoint_cmd, _("\
Breakpoint specific settings\n\
Configure various breakpoint-specific variables such as\n\
pending breakpoint behavior"),
		  &breakpoint_set_cmdlist, "set breakpoint ",
		  0/*allow-unknown*/, &setlist);

... this sets the new prefix command's prefixlist to
&breakpoint_set_cmdlist.

Then, calls to add_* to create sub-commands of this prefix are given
&breakpoint_set_cmdlist as an argument.

So, the idea behind this part of the patch is that we need to create
storage for this list somewhere.  In the rest of gdb this is done as a
global, but that won't fly here -- so we allocate it in the Command.

Does that answer your question?  Or, if I'm misunderstanding
something, could you say what?  I looked at this again and I still
don't see what might be wrong.

Daniel> Yes, alias and user are special.  User is where "define"'d commands
Daniel> go; should there be a command to show all Python-defined
Daniel> commands similar to "show user"?

As a user I don't really care if a command is implemented in Python.
But I don't oppose the idea if you think it is useful.

Tom