Re: [PATCH 3/3 v2] Implement completion limiting

[Doug Evans <dje@google.com>]

On Wed, Jan 7, 2015 at 12:42 AM, Gary Benson <gbenson@redhat.com> wrote:
> Doug Evans wrote:
>> 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.
>
> If you want it in 7.9 then how about I commit it as it is then submit
> a followup patch to remove the #ifdef, and you can make your own patch
> to add whatever functionality you want.  The readline part of this
> series took a good week to get right and I can guarantee you this will
> drag past 7.9 if I touch it.

No worries.  I have a tentative combined patch which I'll submit tomorrow.