This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/3 v2] Implement completion limiting
- From: Doug Evans <dje at google dot com>
- To: Gary Benson <gbenson at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Eli Zaretskii <eliz at gnu dot org>
- Date: Fri, 2 Jan 2015 18:09:24 -0800
- Subject: Re: [PATCH 3/3 v2] Implement completion limiting
- Authentication-results: sourceware.org; auth=none
- References: <1417094168-25868-1-git-send-email-gbenson at redhat dot com> <1417094168-25868-4-git-send-email-gbenson at redhat dot com> <m3y4ql4psf dot fsf at sspiff dot org> <20141210122233 dot GA7299 at blade dot nx> <m3mw6v4gm8 dot fsf at sspiff dot org>
Doug Evans writes:
> Gary Benson <gbenson@redhat.com> writes:
> > Doug Evans wrote:
> >> 1) IWBN if, when "Too many possibilities" is hit, the user was still
> >> shown the completions thus far. I'd rather not have to abort the
> >> command I'm trying to do, increase max-completions, and then try
> >> again (or anything else to try to find what I'm looking for in order
> >> to complete the command). At least not if I don't have to: the
> >> completions thus far may provide a hint at what I'm looking for.
> >> Plus GDB has already computed them, might as well print them.
> >> Imagine if the total count is MAX+1, the user might find it annoying
> >> to not be shown anything just because the count is one beyond the
> >> max.
> >> So instead of "Too many possibilities", how about printing the
> >> completions thus far and then include a message saying the list is
> >> clipped due to max-completions being reached? [Maybe readline makes
> >> this difficult, but I think it'd be really nice have. Thoughts?]
> >
> > It's a nice idea but I'm not volunteering to implement it :)
> > I already spent too much time figuring out how to thread things
> > through readline.
>
> One thought I had was one could add a final completion entry
> that was the message.
> Would that work?
I looked into this a bit.
readline provides a hook to print the completion list:
rl_completion_display_matches_hook
and a routine to display the matches:
rl_display_match_list
The code in readline/complete.c:display_matches is
pretty straightforward (though they've apparently
forgotten to export a way for the hook to set
rl_display_fixed - we'll want to be as equivalent
as possible), so I think(!) this will be rather easy to do.
> One hope I had was that this would be enough:
>
> >> > + rl_crlf ();
> >> > + fputs (ex.message, rl_outstream);
> >> > + rl_crlf ();
>
> and that the efforts tui/*.c goes to to support readline would
> make that work regardless of the value of tui_active.
> But I confess I haven't tried it.
>
> I wouldn't suggest vectorizing the tui interface.
> But I do, at the least, want to understand why this is necessary
> ("this" being the test for tui_active and the different code
> depending on whether it is true or not),
> and if it is then I would at a minimum put this code:
>
> >> > +#if defined(TUI)
> >> > + if (tui_active)
> >> > + {
> >> > + tui_puts ("\n");
> >> > + tui_puts (ex.message);
> >> > + tui_puts ("\n");
> >> > + }
> >> > + else
> >> > +#endif
> >> > + {
> >> > + rl_crlf ();
> >> > + fputs (ex.message, rl_outstream);
> >> > + rl_crlf ();
> >> > + }
> >> > +
> >> > + rl_on_new_line ();
So that leaves this as just the remaining thing to resolve (AFAICT).
I'll look into this more next week.
I'd really like to get this into 7.9.