Re: [RFA] Improve completion of locations

[Elena Zannoni <ezannoni at cygnus dot com>]

Eli Zaretskii writes:
 > 
 > 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.
 > 

[Sorry I got sidetracked on other things...]

I was wondering how readline would get this right in case of
completion on filenames. I had a closer look, and also in that case it
gets it wrong. '.' is a word-break character, but not a filename-break
character. The first time rl_complete() is invoked by pressing TAB,
readline has the set of work-break characters installed. So it ends up
calling line_completion_function() with an empty string, just like
above.  But line completion function switches the set of break chars
from under readline's nose, installing the file-break ones, and
basically redoing what readline got wrong before. So later on, gdb
will try to complete on 'symtab.' and get it right. Fascinating.


 > 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.

Yes, we could play a trick like for filename_completer, but you are
right, it could be a structure/class name. So we are stuck.

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

BTW, I was playing with an older gdb, and a TAB after 'symtab.'
wasn't doing anything. Somehow the behavior has changed in the last
year.

 > 
 > 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.
 > 

I spent some time looking at this, and I don't see a way to do it
either, unless we invent a heuristic like, try on filenames, then on
symbols. But there should be some query mechanism for the user to
reject, say, the filenames. Too convoluted.

 > > 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.

No, my bad. Wasn't thinking straight.

 > 
 > > Do we want those?  Probably not.
 > 
 > Probably, but not positively.  Someone could type something like this:
 > 
 >    (gdb) break symtab.c:*(long *)&foobar
 > 

Yes, true. 

 > > (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.
 > 

Yes. If we could decide what set of break characters to install before the
tab is hit, it would be already a step in the right direction.
Or make readline's find_completion_word() a hook for a gdb function.

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

The basic problem is (as you said in another mail) that the definition
of location is really broad. MI tried some more strict syntax, but
that is an internal interface, not a user interface. I don't think a
more limited syntax in the UI would be long lived. Unless you make the
commands more specific, like break-on-line and break-on-function,
etc. But that also has its disadvantages.

 > > 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.
 > 

Anyway, now that I've looked stuff over more in detail, I think this
can go in. (With the fix for the ':').  But Fernando is the
completer.c maintainer, so we must give him a chance to go over the
patch as well.

Elena