Re: [RFC] New GDB/MI command "-info-gdb-mi-command"

[Joel Brobecker <brobecker@adacore.com>]

> > Regarding invalid switches, we may have to extend the current proposal
> > to allow the command to specific what in the usage caused problem?
> 
> Not sure about that.  Sounds more complicated than it's worth it.
> 
> > In my proposal, it was easy to extend by adding a "feature=[...]"
> > list to the output. Or maybe that's overkill? Or use list-features
> > for that instead?
> 
> As list-features already exists, and works just as well, that might
> indeed be overkill.  Or put another way, is there a use case that
> list-features doesn't cover, or something about "feature=[]"
> that'd make ours and frontend writers' lives easier?  Just like with
> list-features, we'd always have to manually take care of listing the
> new command feature in "features=[]", so on our end it doesn't seem
> to buy anything.
> IOW, thinking in terms of KISS seems to suggest sticking with
> list-features.

OK, I think will work well enough in practice, and, really, worrying
about a few more bytes at a time was a bit of an overreaction :).

> > I'd like us to decide to something I can go and implement. Either way,
> > I think we can start by concentrating with the initial goal, which is
> > to determine whether a command exists or not.
> 
> Yeah.  I have no problem with your proposal.  There's actually one
> case where it works, and '^error,code="unknown-command"' does not,
> which is when a command works and has effects without options.  In such
> cases, you can't probe for the command's existence without causing
> the (side) effects.

I think the intent was not to provide a probing mechanism, but
rather to provide an approach where the FE just fires the command
when it needs to, and then fallback on a CLI-based approach if
detecting an 'unknown-command' error.

But, on the other hand, I am thinking that some FEs might still
want to probe ahead of time, for instance if they do not wish to
provide a fallback mechanism (thus disabling the relevant parts
of the GUI ahead of time); or even if it is easier programatically
for them to probe, instead of having to handle this specific error.

> > People seem to have reacted
> > more positively to the idea of try-and-fallback approach, shall we go
> > with Pedro's idea (without the "invalid switch"/"usage" part)?
> 
> If I had infinite time, I'd go for all of the above.  Command to
> probe existence of commands, and make ^error indicate both
> unknown command, and bad usage.  :-)

I don't have infinite amount of time, but the first 2 (new GDB/MI
command and new ^error for unknown commands) are fairly small tasks,
so I'm happy sending patches for both. That way, we get the best
of both worlds, without must cost, I think, in terms of extra
maintenance, since both patches would be pretty small, and localized.

For invalid usage, I could add that to my list, but that'll have
to be next year... (/me wishes I would say that on Dec 31st...)

-- 
Joel