From: Elena Zannoni <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: ezannoni@cygnus.com, gdb-patches@sources.redhat.com
Subject: Re: [RFA] Improve completion of locations
Date: Mon, 14 May 2001 13:39:00 -0000 [thread overview]
Message-ID: <15104.17012.924972.590369@kwikemart.cygnus.com> (raw)
In-Reply-To: <2950-Sat12May2001090418+0300-eliz@is.elta.co.il>
Eli Zaretskii writes:
> > From: Elena Zannoni <ezannoni@cygnus.com>
> > Date: Sat, 12 May 2001 00:17:54 -0400
> >
> > 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.
>
> Indeed. What this means is the the M-TAB completion, which doesn't
> get the second chance, sometimes gets its act wrong. This problem was
> there since day one.
Ah. Not nice.
>
> > 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.
>
> What version of GDB was that? I tried all the way down to 4.18, and
> it still offers all the possible symbols given "symtab.<TAB>". It
> just that older versions take about forever to grind through all the
> symbols, so you might think GDB is just sitting there idling. Dan's
> patch about a month ago made that code much, much faster.
>
It was an internal version, so it may have been different.
> > > 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.
>
> Something like that. Readline must cooperate with GDB better, for our
> completion to be less error prone. Right now, Readline does not
> support the kind of mode that GDB needs, where it completes on
> different types of objects and therefore needs to change the
> word-constituent characters. Bash completes only on file names, so it
> never needs these complications.
>
> I think we need to ask Readline maintainers to add a couple of
> features in the next releases.
>
Definitely.
> > 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.
>
> Yes, I'm waiting for Fernando's approval.
>
Elena
next prev parent reply other threads:[~2001-05-14 13:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-05 10:59 Eli Zaretskii
2001-05-05 11:26 ` Daniel Berlin
2001-05-05 23:15 ` Eli Zaretskii
2001-05-06 0:10 ` Daniel Berlin
2001-05-06 2:05 ` Eli Zaretskii
2001-05-06 9:38 ` Daniel Berlin
2001-05-06 10:04 ` Eli Zaretskii
2001-05-06 3:19 ` Eli Zaretskii
2001-05-08 13:32 ` Elena Zannoni
2001-05-09 3:46 ` Eli Zaretskii
2001-05-11 21:17 ` Elena Zannoni
2001-05-11 23:03 ` Eli Zaretskii
2001-05-14 13:39 ` Elena Zannoni [this message]
2001-05-25 1:39 ` Eli Zaretskii
2001-06-04 23:15 ` Eli Zaretskii
2001-06-05 6:10 ` Fernando Nasser
2001-06-05 10:58 ` Eli Zaretskii
2001-06-10 8:46 ` Fernando Nasser
2001-06-10 9:14 ` Daniel Berlin
2001-06-10 9:43 ` Fernando Nasser
2001-06-11 9:09 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15104.17012.924972.590369@kwikemart.cygnus.com \
--to=ezannoni@cygnus.com \
--cc=eliz@is.elta.co.il \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox