From: Doug Evans <dje@google.com>
To: Gary Benson <gbenson@redhat.com>
Cc: gdb-patches@sourceware.org, Eli Zaretskii <eliz@gnu.org>
Subject: Re: [PATCH 3/3 v2] Implement completion limiting
Date: Sat, 03 Jan 2015 02:09:00 -0000 [thread overview]
Message-ID: <21671.20308.262958.475080@ruffy2.mtv.corp.google.com> (raw)
In-Reply-To: <m3mw6v4gm8.fsf@sspiff.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.
next prev parent reply other threads:[~2015-01-03 2:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 13:16 [PATCH 0/3 v2] Abort completion when list becomes large Gary Benson
2014-11-27 13:16 ` [PATCH 1/3 v2] Add expansion_notify callback to expand_symtabs_matching Gary Benson
2014-12-05 7:56 ` Doug Evans
2014-11-27 13:16 ` [PATCH 2/3 v2] Interleave completion list building with symbol table expansion Gary Benson
2014-12-05 22:58 ` Doug Evans
2017-01-09 21:19 ` Crash regression for <tab>-completion [Re: [PATCH 2/3 v2] Interleave completion list building with symbol table expansion] Jan Kratochvil
2014-11-27 13:16 ` [PATCH 3/3 v2] Implement completion limiting Gary Benson
2014-11-27 16:25 ` Eli Zaretskii
2014-12-05 23:54 ` Doug Evans
2014-12-10 12:22 ` Gary Benson
2014-12-10 16:25 ` Doug Evans
2015-01-03 2:09 ` Doug Evans [this message]
2015-01-07 8:44 ` Gary Benson
2015-01-09 1:29 ` Doug Evans
2015-01-10 2:32 ` Doug Evans
2015-01-10 9:23 ` Eli Zaretskii
2015-01-12 18:50 ` Doug Evans
2015-01-15 15:39 ` Gary Benson
2015-01-23 7:32 ` Doug Evans
2015-01-23 10:59 ` Eli Zaretskii
2015-01-23 16:38 ` Doug Evans
2015-01-23 16:49 ` Eli Zaretskii
2015-01-23 20:28 ` Doug Evans
2015-01-24 1:55 ` Eli Zaretskii
2015-01-24 8:50 ` Doug Evans
2015-01-24 14:12 ` Eli Zaretskii
2015-01-25 15:55 ` Doug Evans
2015-01-25 19:14 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2014-11-06 10:50 [PATCH 0/3 v2] Limit tab-completion result when list is large Gary Benson
2014-11-06 10:51 ` [PATCH 3/3 v2] Implement completion limiting Gary Benson
2014-11-06 16:28 ` Eli Zaretskii
2014-11-21 10:46 ` Gary Benson
2014-11-24 6:09 ` Doug Evans
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=21671.20308.262958.475080@ruffy2.mtv.corp.google.com \
--to=dje@google.com \
--cc=eliz@gnu.org \
--cc=gbenson@redhat.com \
--cc=gdb-patches@sourceware.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).