Re: [RFA] Improve completion of locations

["Eli Zaretskii" <eliz@is.elta.co.il>]

> Date: Sun, 6 May 2001 12:38:00 -0400 (EDT)
> From: Daniel Berlin <dan@www.cgsoftware.com>
> 
> At 4am in the morning, everything seems miserable.
> :)

I can imagine ;-)

> > Note that Readline has its own ideas about breaking user input into
> > ``words'', and it does that even before our completion functions are
> > called.  So, in contrast to our code which parses the full location spec,
> > completion cannot be much smarter than it currently is, because Readline
> > doesn't give us a chance to be smarter.  Most of the time I debugged this
> > code went into trying to get along with Readline's idiosyncrasies.
> 
> Yeah, I figured as much.
> 
> Still, wouldn't it be easier to just say something like:
> 
> if (filename_spec_p(userstring))
> else if (symbol_location_spec_p(userstring))

Indeed, it would be great.  But this kind of stuff will only be
possible if several functions in symtab.c and wherenot which do their
own ``parsing'' will all be rewritten to use those new functions you
suggest.  If this is the plan, I'm with you all the way, I'm far from
happy wading through all that code each time I want to understand what
the heck is it doing, and inventing my own code to work around any of
its misfeatures.

Also, AFAICS there's no formal definition of the location syntax
accepted by GDB, so you'd probably need to set the rules as you go.
Which might be a Good Thing in and of itself.

Finally, if we want to solve this in a reliable way in the context of
completion, I think there's a real need to ask Readline for more hooks
than what it currently provides.  One thing that is sorely needed is
the way for GDB to tell Readline to use the right word-break
characters _before_ it breaks the line into ``words'' and calls the
completer.

> We have like the same type of parsing going on in quite a few places, and
> it just all seems completley ad-hoc.

Yes.  What's more, almost any more-or-less reasonable change you do in
that ad-hoc code won't change the end result except in a few marginal
and hard-to-come-by cases, so it is very hard to debug.