From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24312 invoked by alias); 7 Jan 2015 08:44:04 -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 24295 invoked by uid 89); 7 Jan 2015 08:44:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 07 Jan 2015 08:44:01 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t078gvIS023497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 7 Jan 2015 03:42:58 -0500 Received: from blade.nx (ovpn-116-83.ams2.redhat.com [10.36.116.83]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t078gtkG013776; Wed, 7 Jan 2015 03:42:56 -0500 Received: by blade.nx (Postfix, from userid 1000) id 4FED526267F; Wed, 7 Jan 2015 08:42:55 +0000 (GMT) Date: Wed, 07 Jan 2015 08:44:00 -0000 From: Gary Benson To: Doug Evans Cc: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [PATCH 3/3 v2] Implement completion limiting Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21671.20308.262958.475080@ruffy2.mtv.corp.google.com> X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00096.txt.bz2 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. Cheers, Gary -- http://gbenson.net/