From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20932 invoked by alias); 13 May 2013 18:42:23 -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 20870 invoked by uid 89); 13 May 2013 18:42:22 -0000 X-Spam-SWARE-Status: No, score=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 13 May 2013 18:42:22 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4DIgKZ3026419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 May 2013 14:42:20 -0400 Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4DIgJEr027384 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 13 May 2013 14:42:19 -0400 Message-ID: <5191340B.60100@redhat.com> Date: Mon, 13 May 2013 18:42:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Doug Evans CC: "gdb-patches@sourceware.org ml" Subject: Re: [RFC] Cleanup for make_source_files_completion_list References: <51895A2F.8000504@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00452.txt.bz2 On 05/09/2013 04:45 PM, Doug Evans wrote: > The caller of make_source_files_completion_list explains the decision > to pass "text" for "word" here: > > /* If we only have file names as possible completion, we should > bring them in sync with what rl_complete expects. The > problem is that if the user types "break /foo/b TAB", and the > possible completions are "/foo/bar" and "/foo/baz" > rl_complete expects us to return "bar" and "baz", without the > leading directories, as possible completions, because `word' > starts at the "b". But we ignore the value of `word' when we > call make_source_files_completion_list above (because that > would not DTRT when the completion results in both symbols > and file names), so make_source_files_completion_list returns > the full "/foo/bar" and "/foo/baz" strings. This produces > wrong results when, e.g., there's only one possible > completion, because rl_complete will prepend "/foo/" to each > candidate completion. The loop below removes that leading > part. */ > > Note that if you remove "word" from make_source_files_completion_list > then add_filename_to_list collapses to a trivial function (which would > otherwise be great except there's basic core functionality that I > think should be kept). :-) Indeed. I looked into this a bit further after Tom's comments, too. As it is, I am convinced that this patch should not be accepted. [aka, Tom is right -- those callers of make_source_files_completion_list which pass text twice are suspicious.] However, I think that the comment quoted above (and the surrounding block of code which does the copying) should be removed and the callers of make_source_files_completion list should pass text AND word instead of text and text. add_filename_to_list (in symtab.c) does this text - word adjustment already, so it is not necessary to repeat it here. WDYT? > OTOH the "text" arg to completion_list_add_name can go, it's unused. I'll take a look at that, too, while I'm at it. That didn't come up during my completer implementation, so it escaped scrutiny. Keith