From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23864 invoked by alias); 3 Jan 2015 02:09:41 -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 23182 invoked by uid 89); 3 Jan 2015 02:09:32 -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-ie0-f201.google.com Received: from mail-ie0-f201.google.com (HELO mail-ie0-f201.google.com) (209.85.223.201) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 03 Jan 2015 02:09:28 +0000 Received: by mail-ie0-f201.google.com with SMTP id rp18so1900350iec.4 for ; Fri, 02 Jan 2015 18:09:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=VW5+3F+8Y1AdtTyrXeowA/zVrJFPKc8Ll3c76J/gmAU=; b=OBcaxUTektie5ltJtmLTzezY96ofzp7omi0jLh41X/cqpd6nwj3l5HRJP1VqNVRJ5L z3suiiMZ+cY1q1aTaHpWCg9ka4oO8CEywS5+I+Xc+pG2GFVRLj5kMvTp+NeYu2J2TvQ+ 5EhTrZKXb3cBKr6ENoLAxIeUJiORIIcYu2raiWAphPnkfThK/bmqpmBAjbcp04KFhIis S5WXGRf3FfBI1M33cic23DsxemiV5oSr4uQ8hbmqxv0h4PdS1LYUMErmQfKIlSnK9cpg iZNaLW4QzBsA7FRtdcp4rbqQOotlNEmOH4C5siriz+CxQoumSXoVBB7GWSG/rY2onB/A L7mQ== X-Gm-Message-State: ALoCoQldDi46fNda48XOAOQ9BHK9ighuAUKTLOeOU12KkzO2l3r4d1Wf4DhPbq2cM1uYQyP3zdrR X-Received: by 10.50.120.66 with SMTP id la2mr1519030igb.8.1420250965975; Fri, 02 Jan 2015 18:09:25 -0800 (PST) Received: from corpmail-nozzle1-2.hot.corp.google.com ([100.108.1.103]) by gmr-mx.google.com with ESMTPS id v47si1570014yhn.0.2015.01.02.18.09.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jan 2015 18:09:25 -0800 (PST) Received: from ruffy2.mtv.corp.google.com ([172.17.128.107]) by corpmail-nozzle1-2.hot.corp.google.com with ESMTP id 8591fGPT.1; Fri, 02 Jan 2015 18:09:25 -0800 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21671.20308.262958.475080@ruffy2.mtv.corp.google.com> Date: Sat, 03 Jan 2015 02:09:00 -0000 To: Gary Benson cc: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [PATCH 3/3 v2] Implement completion limiting In-Reply-To: References: <1417094168-25868-1-git-send-email-gbenson@redhat.com> <1417094168-25868-4-git-send-email-gbenson@redhat.com> <20141210122233.GA7299@blade.nx> X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00019.txt.bz2 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.