From patchwork Wed Mar 6 10:23:37 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 86864 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DB579385801C for ; Wed, 6 Mar 2024 10:25:28 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 21118385843A for ; Wed, 6 Mar 2024 10:24:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 21118385843A 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 21118385843A 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=1709720645; cv=none; b=ij/L4H3vZCPvB4vo7+KqkRFEBAoC7SOp/V97oSpkQFTS1H1AY8QFmHv4BKFerAa1AEjthoMj3+hjxBXz/xs3X04bQRh944mfbzUiaWHwWVdTBywaahtMasgpb/3XWj8L2ElNhfBTOOUuoLYZ0EMpXxRQTSmfR+5Aqxw4dHm1FDE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709720645; c=relaxed/simple; bh=hLBG9jodGnferuNzlYbdSksM67LLA2C5oHtZ0/WUqus=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=Nr9o87grI5vNDNDPkMYXxeDK7BmGrF3Hb31yRG6T7ewAKcW5/lYTEzmABIRPnuIBqZBC633lRJld0SwAVNKngxbEiTzgCZBKCWDdFZN2crZUvrtExtClCOwmEY3oEWDseibBH321gEOF6HgHCKXnL3HotXJGbx//XFUHtI9iQ94= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709720642; 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=tWbctKYH8AaADxcaY3FrYeL+F5sx9kmshZPKdBe16kE=; b=VnnGD0GhAfZ/d3fziEbLlN7QXrAIF/ZPeYZQMmdpyjCFXMIxL+M1EXzWKtGxCh1PgjO2sP NjZtLpQb76ke36960ZLcQqQSZcyelR6KrOilN4xRKTh3BSqj7Rx7cRjgeGiIUfsZkHGcwG zhFaMNft4N1WPSrxndqeEMmyOdBEOdg= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-145-jwHs-jA7OJO2cllOk0RF2w-1; Wed, 06 Mar 2024 05:24:01 -0500 X-MC-Unique: jwHs-jA7OJO2cllOk0RF2w-1 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-a4533388b03so189741266b.0 for ; Wed, 06 Mar 2024 02:24:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709720640; x=1710325440; 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=tWbctKYH8AaADxcaY3FrYeL+F5sx9kmshZPKdBe16kE=; b=cvxPuWzDSp9tTGWPFLmeMxZBtvk01hd0HNG/Sh/kYXWiEipvxq43xHqg2+ct+SKo5l 2swRsjJugi5oqKlh/nov2istsk2NkyGkOffLBoDeZ949SvjCwNxfW36EVL+8MdnNrz88 eR+J04nYmN1FSOwkIqK0AtgWiBHcdJR2OoheR45bzvZL3h8SBhJr1P3srRM/4BWbm10i V9hWRCTZ4N73N79dCWKL6x7ePGcRBthFzK/gnAS1LwcjUq+xbAo35+thakpgOK71VFlx T4dN9lkcCyBzDvT5kDkKahyV600gPRhyeiH7i6Zu8eGt/ZtvYcCVbxxqVMdtMczyDbrO RcSA== X-Gm-Message-State: AOJu0YzwMVpn6p6xf7dLN0DWcdINMyqs6KmhjWtOw797FH8LDMQ8BK7H TO5zIbI0LSyS6oYeYo0o7sWVvV+9RYA3m/pyiqU2KKMedjNMcikrIzRm4f7mjodi4lAJRj2asSB PSz7CUoA1fUhnwT2USxlyZRoGHUdQRaDEuCirnKiOaCxpglRzEllTTvRg+RlkjBeKqgNBa91uJn axl2qraiLEq9IinKelEfDVgqv5yPWdU4FccfdxSyH0yZE= X-Received: by 2002:a17:906:8c6:b0:a3e:9aa3:7024 with SMTP id o6-20020a17090608c600b00a3e9aa37024mr10033404eje.34.1709720639823; Wed, 06 Mar 2024 02:23:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IH/U/S883/GPHCCCT3fkSzssmv0r5M4k/vvv6GC46HyOgajuHH8XfNK2f6H7M3x/gRs1rcoyA== X-Received: by 2002:a17:906:8c6:b0:a3e:9aa3:7024 with SMTP id o6-20020a17090608c600b00a3e9aa37024mr10033388eje.34.1709720639251; Wed, 06 Mar 2024 02:23:59 -0800 (PST) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id pv13-20020a170907208d00b00a451dc6055fsm3832724ejb.212.2024.03.06.02.23.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Mar 2024 02:23:58 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv2 5/7] gdb: remove special case completion word handling for filenames Date: Wed, 6 Mar 2024 10:23:37 +0000 Message-Id: <42a053369278a30fc6502e45eb4e4e9903a8ba3d.1709720449.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 X-Spam-Status: No, score=-12.2 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, 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+patchwork=sourceware.org@sourceware.org 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 330c39598c5..04354120621 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.