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

[Doug Evans <dje at google dot com>]

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.