Re: [RFA] Improve completion of locations

[Eli Zaretskii <eliz at is dot elta dot co dot il>]

On Tue, 8 May 2001, Elena Zannoni wrote:

> Eli, one minor problem with your patch is that your sources are not up
> to date. The #include of completer.h in tracepoint.c and infcmd.c was
> removed by JT on March 27. So you will have to add it back in when you
> commit the patch.

Okay, thanks for the heads-up.

> Using a gdb with your patch applied to debug another gdb I am getting
> something I don't understand:
> 
> (top-gdb) b symtab.<TAB>
> Display all 10987 possibilities? (y or n)
> 
> what is it trying to do (note the '.')?

Granted, I've bumped into this as well.  The immediate problem here is
that Readline passes an empty string to our completion function,
because `.' is not a word-constituent character.  The completer then
simply comes up with a list of all the symbols in the program.

I thought about writing special code for this specific case, which
would realize that this is a file name without an extension.  However,
it isn't clear that this is the right thing to do, because the user
could well mean to write symtab.foobar, meaning the field foobar of
the struct named symtab.  GDB has no simple way of knowing what case
it is faced with.  Also, the symbol completion is not smart enough to
see if there is indeed a symbol named symtab, if it is a struct or a
class, and only list members of that struct after the dot.

When presented with the same input, the original completion would also
do the same, so this isn't a regression.

If you (or someone else) has suggestions how to improve this, I'd be
glad to hear them.  But this would be an additional improvement.

> Using the ':' I get a list of completions which includes:
> (top-gdb) b symtab.c:
> __builtin_va_list                  int
> _initialize_symtab                 keep_going
> add_filename_to_list               long double
> block_found                        long int
> block_function                     long long int
> bound                              long long unsigned int
> builtin_type_error                 long unsigned int
> char                               lookup_block_symbol
> completion_list_add_name           lookup_partial_symbol
> complex double                     lookup_partial_symtab
> complex float                      lookup_symbol
> complex int                        lookup_symbol_aux
> complex long double                lookup_symtab
> contained_in                       lookup_symtab_1
> cplusplus_hint                     lookup_transparent_type
> [...many more...]
> 
> But why am I getting the types names, like 'char', 'long double', etc?
> They must be coming from the minsymbols, maybe.

I saw this, but my testing indicates that these symbols are indeed
inside the symtab for the file (symtab.c, in this case), not inside a
minsym.  In fact, the function make_file_symbol_completion_list which
I added doesn't even look at minsyms.  AFAIU, the symtab for a file
holds all the data types that were visible to the compiler when the
file was compiled.  If you see something different, please tell,
perhaps there's a bug in my code.

> Do we want those?  Probably not.

Probably, but not positively.  Someone could type something like this:

   (gdb) break symtab.c:*(long *)&foobar

> (top-gdb) b symtab
> symtab              symtab.h            symtab_fns          symtab_to_filename
> symtab.c            symtab_and_line     symtab_symbol_info  symtabs_and_lines
> 
> (top-gdb) b symt<TAB>
> symtab              symtab_and_line     symtab_to_filename  
> symtab.c            symtab_fns          symtabs_and_lines   
> symtab.h            symtab_symbol_info  symtoken            
> 
> (top-gdb) b symtab.c:make_<TAB>
> make_cleanup_free_search_symbols   make_symbol_completion_list
> make_file_symbol_completion_list   make_symbol_overload_list
> make_source_files_completion_list  
> 
> These all seem to work now and didn't before, which is really neat.
> 
> I think some more refinements are needed.

I'd be glad to make this more smart, but it's not simple.  By far the
nastiest problem is that Readline decides what is the word which is
being completed on _before_ our completion function is called.  This
defeats many nifty tricks we could do using the context of the
completion.

But I'm open to ideas which would make completion even more useful.

> Syntactically, there is a line I don't like :
> 
>  > +  (*list)[*list_used += 1] = NULL;
> 
> Could you just use '++'?

Yes; I will change that.

> Sorry, I don't have much more time right now to look at it in more
> detail. I think I am starting to understand this whole patch. I may
> have some more comments tomorrow.

Thanks.