From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OOCeIE70pmXn/j0AWB0awg (envelope-from ) for ; Tue, 16 Jan 2024 16:25:34 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=DOQ2SVsB; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 806CB1E110; Tue, 16 Jan 2024 16:25:34 -0500 (EST) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6B0981E098 for ; Tue, 16 Jan 2024 16:25:32 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C02313858424 for ; Tue, 16 Jan 2024 21:25:31 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 77683385843B for ; Tue, 16 Jan 2024 21:24:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 77683385843B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 77683385843B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705440260; cv=none; b=ahs1X4jW3QVS6m4uJyx/28gP4zli8+xqXXwCkbPyuf60pAbf066YYVCQfxpSCteI9zi0YnV/2k78rbdBnXfhSiB23UBJjUZL39xrz33iXANZ1X5P34uwUfcflHeDetKwF/4L+Icn02BkdtQczDypeeFhBHeECLZs00VI+eKujLM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705440260; c=relaxed/simple; bh=7lrqt+IA5XZeCZJNnXig0xGskirQfEbGZr/Qv6kqVp8=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=M/eHqOid0eXO4P1Cwk6UmurAnCIn60AydlpeQ+xEiKaSHzY5k++qPq1o6vc+yhnsWd+zLSH5nYIbZoHmIVVE0c+ikFvcWYEk1p7ND3qIxxsd4YvqEbwHtYjy6mkbfq96t2Nfe9vQG2P8aOGyWM3jdz4KYujZk8TupD7h0zs5j5w= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1705440256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=00WLMUTf/ongNSSLICV+e3MxIQYE5WgPcmMbSRlUhJA=; b=DOQ2SVsBPkQZBBTkXcTEiDa25oNNamyKFbENpwqmb27gDcjB3HrrEJI1z5YFVovbZqCi8s FGg6K88T8IQi5jEKvgbvV7O3yBVcyHEw5zpUUBgnS1ydfhDr+guqIJS65pl7sAVmaYpqq4 DxlsL+AT8Rhow+We1xXXsusLh4pjCHQ= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-391-ou31p-YnPbiPYWJprigJpA-1; Tue, 16 Jan 2024 16:24:14 -0500 X-MC-Unique: ou31p-YnPbiPYWJprigJpA-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-337bf81e1efso374742f8f.2 for ; Tue, 16 Jan 2024 13:24:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705440253; x=1706045053; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=00WLMUTf/ongNSSLICV+e3MxIQYE5WgPcmMbSRlUhJA=; b=ru6OTwLOjQBD1SsCMH8/O8dQtZl4k79xcG7f/E79/Sz23iZ1+ePZrw5FPugaNli+xt IS33oMM3xnTWIYRBu3M4Ua6q001JaEEazordbXAo7fnjkP2+8biDdUqiGIaO51anvQJB ZC0lQ9PVzfZtEFtWSakFb0gRUzgUK+BloiSlH82GPvTab1WTKrNLyIFbpE/zyr1XSk1G 0WrgQaX9GEPwTUUmOrwKfCtxJ7GZIXwP8fke7ysv0oBS1zB1wsAKUH+01QRYLRWMowYA /NCRLF9lVTL6dt8hW/tEP0I0bSTkx5r0XdUHdPIUrdGt8rZKlhd07PJ7albqDUU7HZdC Fqjw== X-Gm-Message-State: AOJu0YwTIxHB9s77jeS4grwUQpqHmrXBdOjFN3cs1d4p/G0NSKCkaurk BknCAWYJIxl4rHLP8Y7vx1Ohuie6D7/XIOmub0GlQUFydAcu0rxXfhxfj2UXXK5Mkb6Xepa83uY 477US7cjPbRvqQe50nvjuHbm81WJy628kvhbX7MlK+24AeBuOR3pt9t/zTqGrXiF/9GXDmAyk4r 8Yo4c5fP8v+/MeYg== X-Received: by 2002:a5d:43d1:0:b0:336:81d8:3ed0 with SMTP id v17-20020a5d43d1000000b0033681d83ed0mr4831167wrr.26.1705440252865; Tue, 16 Jan 2024 13:24:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IG2z7Tdl9jkDvO0PsHpxfh4AnGUcscxZuLK6cCnMl4+/JFi+nqoHfZjEYziQnBbEu0oeF7Trg== X-Received: by 2002:a5d:43d1:0:b0:336:81d8:3ed0 with SMTP id v17-20020a5d43d1000000b0033681d83ed0mr4831163wrr.26.1705440252600; Tue, 16 Jan 2024 13:24:12 -0800 (PST) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id x11-20020a5d54cb000000b00336e32338f3sm62775wrv.70.2024.01.16.13.24.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jan 2024 13:24:12 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess , Eli Zaretskii Subject: [PATCH 5/5] gdb: remove special case completion word handling for filenames Date: Tue, 16 Jan 2024 21:24:02 +0000 Message-Id: <048fa74bfb249273becb517d9edc9fd7a129e205.1705439706.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-13.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Eli, CC-ing you directly as the work I'm touching was originally done by you, see: https://sourceware.org/pipermail/gdb-patches/2001-February/007313.html The original email mentions 4 cases: - completion on a file name in a list of file names didn't work; - GDB would not always append a slash if the completion is a directory; - completion failed when the file name had non-file-name characters, such as redirection, around it; - on DOS/Windows, completion would fail with files with a drive letter. I believe I've tested the first 3 of these and they all seem to work fine still, but I don't have a working Windows machine on which I can test case #4. I just wanted to bring this change to your attention in case you wanted to build/test this and check that completion around drive letters was still working as expected. --- This commit removes some code which is special casing the filename completion logic. The code in question relates to finding the beginning of the completion word and was first introduced, or modified into its existing form in commit 7830cf6fb9571c3357b1a0 (from 2001). The code being removed moved the start of the completion word backward until a character in gdb_completer_file_name_break_characters was found, or until we reached the end of the actual command. However, I doubt that this is needed any more. The filename completer has a corresponding filename_completer_handle_brkchars function which provides gdb_completer_file_name_break_characters as the word break characters to readline, and also sets rl_completer_quote_characters. As such, I would expect readline to be able to correctly find the start of the completion word. There is one change which I've needed to make as a consequence of removing the above code, and I think this is a bug fix. In complete_line_internal_normal_command we initialised temporary variable P to the CMD_ARGS; this is the complete text after the command name. Meanwhile, complete_line_internal_normal_command also accepts an argument WORD, which is the completion word that readline found for us. In the code I removed P was updated, it was first set to WORD, and then moved backwards to the "new" start of the completion word. But notice, the default for P is the complete command argument text, and only if we are performing filename completion do we modify P to be the completion word. We then passed P through to the actual commands completion function. If we are doing anything other than filename completion then the value of P passed is the complete argument text. If we are doing filename completion then the value of P passed is the completion word. Thus in filename_completer we get two arguments TEXT and WORD, the TEXT argument gets the value of P which is the "new" completion word, while WORD is the completion word that readline calculated. However, after I removed the special case in complete_line_internal_normal_command, the temporary P is removed, we now always pass through the complete argument text where P was previous used. As such, filename_completer now receives TEXT as the complete argument text, and WORD as the readline calculated completion word. Previously in filename_completer we actually tried to generate completions based on TEXT, which due to the special case, was the completion word. But after my change this is no longer the case. So I've updated filename_completer to generate completions based on WORD, the readline calculated completion word. If I'm correct, then I don't expect to see any user visible changes after this commit. --- gdb/completer.c | 25 ++++--------------------- 1 file changed, 4 insertions(+), 21 deletions(-) diff --git a/gdb/completer.c b/gdb/completer.c index 9c89aa43810..b78946d66dd 100644 --- a/gdb/completer.c +++ b/gdb/completer.c @@ -210,7 +210,7 @@ filename_completer (struct cmd_list_element *ignore, while (1) { gdb::unique_xmalloc_ptr p_rl - (rl_filename_completion_function (text, subsequent_name)); + (rl_filename_completion_function (word, subsequent_name)); if (p_rl == NULL) break; /* We need to set subsequent_name to a non-zero value before the @@ -239,7 +239,7 @@ filename_completer (struct cmd_list_element *ignore, } tracker.add_completion - (make_completion_match_str (std::move (p_rl), text, word)); + (make_completion_match_str (std::move (p_rl), word, word)); } } @@ -1193,23 +1193,6 @@ complete_line_internal_normal_command (completion_tracker &tracker, complete_line_internal_reason reason, struct cmd_list_element *c) { - const char *p = cmd_args; - - if (c->completer == filename_completer) - { - /* Many commands which want to complete on file names accept - several file names, as in "run foo bar >>baz". So we don't - want to complete the entire text after the command, just the - last word. To this end, we need to find the beginning of the - file name by starting at `word' and going backwards. */ - for (p = word; - p > command - && strchr (gdb_completer_file_name_break_characters, - p[-1]) == NULL; - p--) - ; - } - if (reason == handle_brkchars) { completer_handle_brkchars_ftype *brkchars_fn; @@ -1223,11 +1206,11 @@ complete_line_internal_normal_command (completion_tracker &tracker, (c->completer)); } - brkchars_fn (c, tracker, p, word); + brkchars_fn (c, tracker, cmd_args, word); } if (reason != handle_brkchars && c->completer != NULL) - (*c->completer) (c, tracker, p, word); + (*c->completer) (c, tracker, cmd_args, word); } /* Internal function used to handle completions. -- 2.25.4