Re: [patch/rfc] mi interpreter-complete enh req 8058.

[Tom Tromey <tromey@redhat.com>]

>>>>> "Matt" == Matt Rice <ratmice@gmail.com> writes:

Matt> Attached is a patch i've ported from Apple's gdb...
Matt> it implements a tab-completion like function for MI
Matt> http://sourceware.org/bugzilla/show_bug.cgi?id=8058
Matt> I figured I would post a basic port of the patch for discussion,
Matt> before doing to much to it.

Thanks.

Matt> it only implements complete_proc for the console interpreter, why
Matt> then 'interpreter-complete' if only the console interpreter
Matt> implements it?

I have no idea.

Matt> it has arbitrary limits of 200 completions which has never really been
Matt> a part of the gnu credo:
Matt> one idea is to introduce a limit argument to the mi command, but that
Matt> brings up the idea of bringing in a starting point for resuming
Matt> completion, and getting multiple batches

Matt> without some form of a continuation it'd have to redo the
Matt> completion each batch, it seems difficult/impossible to invalidate
Matt> the completion e.g. if loading/completing symbols

Matt> so maybe we should forgo the batching but add the limit to the mi command?

Yeah, some solution here would be nice to have.
This is related to http://sourceware.org/bugzilla/show_bug.cgi?id=9007

I suppose some kind of continuation is not out of the question.

Matt> I also notice it doesn't implement the all? argument that he mentioned
Matt> in the bug report.

If you don't need that, you can ignore it, IMO.

Matt> also need to add a  -list-features thing...

I think it is probably fine not to do that and just let clients catch
the error coming from older GDBs.

Matt> adding arguments and things obviously would break compatibility with
Matt> their gdb, is this an issue?

IMO, it is not an issue.  But, if it is easy to be compatible, we might
as well be.

Matt> -interpreter-complete console "b ma"
Matt> ^done,completions=[c="main",c="malloc",c="malloc@plt"]

It is weird to see all those useless "c=" strings in there :-)

The patch seems reasonable enough.  There are some GNU style issues to
clean up.  And, this would need an update to the manual.

Tom