cli/1902: excessive completions: ignores readline's completion-query-items

[eddy at opera dot com]

>Number:         1902
>Category:       cli
>Synopsis:       excessive completions: ignores readline's completion-query-items
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 30 18:58:00 UTC 2005
>Closed-Date:
>Last-Modified:
>Originator:     eddy@opera.com
>Release:        6.3-debian
>Organization:
>Environment:
Linux whorl 2.4.27-2-686-smp #1 SMP Thu Jan 20 11:02:39 JST 2005 i686 GNU/Linux
Running gdb within emacs 21.4.1 using M-x gdb.
>Description:
If I hit TAB to complete at an inopportune moment, gdb in gud-mode will recite (in the gdb window, not an other-window of prompts) *all* 72 thousand or so symbols it knows about, as possible completions, without warning or confirmation.

I typed function name, TAB gave me several param types, I typed some letters of the next, TAB completed it - though gud-mode wanted to offer me lots of other choices in other-window - but this still left the function ambiguous (I never did like C++ overloading) so I used TAB TAB, hoping to see what candidates I needed to chose amongst for the next parameter type.  Presumably the fact that I did so after a space is material to why it thought I wanted a list of all known symbols ...  Each line also has, as prefix, everything I've typed thus far, so looked like:

 break 'ClassName::Method(char*, unsigned int, Descriptor*

followed by a symbol, which did wonders for the total byte count.

It is of course totally useless to list this many symbols, even when they're relevant (there are quicker ways for me to obtain the right answer and no way am I going to read all that lot) and it takes ages simply to display them all, which C-g doesn't seem to be enough to interrupt.  Plus, of course, the gud-mode buffer grows by 9 Mb each time this happens, which is a wicked way to squander resources.  (Gah - and I just had to do it *again* to check my How-To-Repeat does actually work ...)

Even listing this many symbols in other-window (as single TAB does, I see) is worse than useless: again, it takes for ever and chews up resources, and I can only see the first few dozen anyway.

The readline section of gdb's info manual says that, since I have completion-query-items unset (I have no ~/.inputrc), I should be queried if completion would list over 100 items.  (Now that I've read it I'm going to go and set that to something a lot smaller - even 100 is more than I ever want to see - about a dozen should do !)

Hopefully, this will just be a matter of some missing glue between readline and gdb/gud-mode ...

Severity: annoyance
Scope: probably only affects those of us who aren't very sophisticated readline users; probably only rarely (I've hit this before, didn't bug-report it, learned the "don't do that, then" lesson, haven't done it for a year or two, forgot the lesson ...)
Impact: may cause users unfamiliar with readline to be scared of trying to use TAB completion, hence limiting uptake of some useful functionality.
>How-To-Repeat:
If necessary, remove any setting of completion-query-items from your ~/.inputrc and type C-x C-r; this may be unnecessary, unless your setting is very very high; but, for all I know, an overt setting may be honoured, where the implicit default setting of 100 isn't.

Fire up emacs, M-x gdb, tell it some program you've compiled with -g, let gdb get started in its new buffer.  Type
  break 'write(int, void*
and hit TAB.  Be patient.
How patient depends on the size of the program, I suppose.
Eventually *Completions* will offer you unhelpfully many options to chose amongst.
If you're feeling masochistic, hit TAB again to see gdb print out all those options.

You may need to be in the middle of a long and difficult debugging run of the program for this to work, for all I know, but it seems unlikely.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: