From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21622 invoked by alias); 9 Jan 2015 01:29:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21597 invoked by uid 89); 9 Jan 2015 01:29:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ob0-f172.google.com Received: from mail-ob0-f172.google.com (HELO mail-ob0-f172.google.com) (209.85.214.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 09 Jan 2015 01:29:29 +0000 Received: by mail-ob0-f172.google.com with SMTP id va8so11107857obc.3 for ; Thu, 08 Jan 2015 17:29:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n2xJXYhFr0R4krrYwGTqVwHCHtSavrIQMz5hIfHsPM0=; b=V1uMVSy2yaUPsaOP2Li2hdsBDMbBloqllWirbXmYfrHM1pNN7JVI7lFWPZPlprzZmZ IXCJtGW/aydteIpmAryY45uFc7Anp9JGzFZO7zJoh64TzKnPJwRc/AknN8o0qWpNsx1g vMyF9mvJzamzKTNhqTMfjjBhyzjqVOv11KKinr0BE5BeIrvQkfUMrQ9MB4CU8Jfnnt5T DRhKPYFvI9TxYth6IdB/C5n9tax1f1LzAg1uNqugJinu6KC6mtBXlbvcQI2frUFO+VDQ WcxpppxpIige2r4y92nOFE9rAA19eNz8cdHpQHQiIV6AU6MC+i7o7rSyVjf37B86xa+c pD8Q== X-Gm-Message-State: ALoCoQkI86E8j9JWE1FPhSbFIFvyNcD9lX0g4pWL0zyeoIQKSuLrlaL2V/L0Q20c63qUH2iN+V/I MIME-Version: 1.0 X-Received: by 10.202.61.9 with SMTP id k9mr7304023oia.116.1420766967500; Thu, 08 Jan 2015 17:29:27 -0800 (PST) Received: by 10.182.222.98 with HTTP; Thu, 8 Jan 2015 17:29:27 -0800 (PST) In-Reply-To: <20150107084255.GA17867@blade.nx> References: <1417094168-25868-1-git-send-email-gbenson@redhat.com> <1417094168-25868-4-git-send-email-gbenson@redhat.com> <20141210122233.GA7299@blade.nx> <21671.20308.262958.475080@ruffy2.mtv.corp.google.com> <20150107084255.GA17867@blade.nx> Date: Fri, 09 Jan 2015 01:29:00 -0000 Message-ID: Subject: Re: [PATCH 3/3 v2] Implement completion limiting From: Doug Evans To: Gary Benson Cc: gdb-patches , Eli Zaretskii Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00207.txt.bz2 On Wed, Jan 7, 2015 at 12:42 AM, Gary Benson wrote: > Doug Evans wrote: >> Doug Evans writes: >> > Gary Benson 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.