RE: [PATCH] Add support for `user-defined` python commands

[Scott Goldman <scottjg at vmware dot com>]

Hi Doug. 

> I think there's a problem to solve here (finding one's way in the
> myriad of available commands), but I'm not sure this is the way to go.
> [Maybe it is though.]

I think you made some interesting points. From what I make of your email, the question you've proposed is something like "should we even have user-defined category at all?". I'm sure there will be a lot of opinions on this. UI debates are tougher for me than technical ones :)

I can see the discussion branching in two directions:
1) Yes, we should have a user-defined category, but we also want to either: subdivide the user-defined commands into prefix categories, or have additional custom categories.

In this case, I think it follows that my patch should be applied pretty much as-is (pending any necessary refactoring as requested). If legacy gdb macros can enter the `user-defined` category, I don't see why new python gdb macros should be excluded. Further patches can add the support for additional custom categories, and this patch would be the first step: allowing python macros to be classified as `user-defined` at all.

2) No, we should not have a user-defined category, and it should be replaced by custom categories or prefix categories.

In this case, my patch is pretty irrelevant. 


At work, the macros I deal with are intended for kernel debugging on ESXi. I was in the process of introducing our first python macro, but realized that all of our macros are indexed in `help user-defined` but, for whatever reason, the gdb python api has excluded that as one of the possible categories. My interim solution was to simply wrap some python gdb functions in legacy gdb macros (yuck!). 

Personally, though I would prefer #1, and here's why:

> Question: What if we had the ability to add new command classes?
> And what if "help <foo>"  could print all the commands in that command class?
> Then one could add a whole suite of python commands to deal with foo
> (which needn't necessarily match any existing command class), and
> "help foo" would list them all.

This is a nice idea, and we actually do have enough macros that categorizing them would probably be smart. That being said, this doesn't necessarily preclude having a catch-all `user-defined` category (or at least, the ability to list all user-defined macros). I imagine (hypothetically) trying to find a macro and not being able to determine which obvious category I should list. 

> (python commands mightn't be able to be implemented as set/show/info
> today, I forget, but it seems like a useful thing to at least not preclude).

At least `info` falls under the `status` category, which a python command can currently declare itself under.

-sjg

________________________________________
From: Doug Evans [dje@google.com]
Sent: Wednesday, May 18, 2011 6:58 PM
To: Scott Goldman
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Add support for `user-defined` python commands

On Wed, May 18, 2011 at 4:26 PM, Scott J. Goldman <scottjg@vmware.com> wrote:
> For codebases with a large pre-existing set of legacy gdb macros, it's
> nice to be able to use `help user-defined`, to refresh your memory wrt
> to existing macros. Currently, python gdb commands can't put themselves
> under the `user-defined` category. This patch aims to rectify that.

I think there's a problem to solve here (finding one's way in the
myriad of available commands), but I'm not sure this is the way to go.
[Maybe it is though.]

What does "help user-defined" buy?
It *does* buy a way to see a list of a particular set of available
commands, but the list isn't categorized along functional lines (like
managing breakpoints or examining data).  What the user will get is a
list of a random set of commands.

For completeness sake, prefix commands provide another way of
categorizing commands - one *could* put a set of new commands in a
prefix command, and then "help <prefix>" would list all of the
commands.  But it doesn't always fit what one wants to do.  E.g. it
wouldn't list anything added as a set/show or info command (python
commands mightn't be able to be implemented as set/show/info today, I
forget, but it seems like a useful thing to at least not preclude).

Question: What if we had the ability to add new command classes?
And what if "help <foo>"  could print all the commands in that command class?
Then one could add a whole suite of python commands to deal with foo
(which needn't necessarily match any existing command class), and
"help foo" would list them all.

Just a thought.