From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74772: [PATCH] Consistently add wildcards for completion-pcm-leading-wildcard Date: Tue, 10 Dec 2024 12:48:23 -0500 Message-ID: Reply-To: Spencer Baugh Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10590"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier To: 74772@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 10 18:51:25 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tL4OL-0002Zl-FZ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Dec 2024 18:51:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tL4O2-0005vY-8M; Tue, 10 Dec 2024 12:51:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tL4Ny-0005ty-K7 for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 12:51:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tL4Ny-0007vA-C7 for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 12:51:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:From:To:Subject; bh=rw+tc/bYEMDaJw8SUT7odwFELvCyV/kUzy+GdaAZPOA=; b=UxMj/MJ8CuiuzBv1WmumzpFFcRsanw7pV8mGgTtQbJFqvmTJJTrD8M/3rYEyvEnlgOEzpGVWQUMufrEAr/K5nJrruq8Rnxmpnhwq1aXVESzNAvNWrBQn3rxxn0o6fAmzDcVDFB+TcHprM6/I3XMo3pt/g+knjfclYJPzn2UMeKE0riFoklA7WTfOGpeHaUL0ib/o5GQiVS8+u72KnDu+QZ20+Pl6PL/lwNp5pCa8+IN1zJ6rPDYXKVZ+8kN96QlaDNVApPH4oF1Ei9wDTLQOqmq4Hq0mcQW5ePCiMELjb8m6lc9h4dEXZx6uDNJrSZSoAgaDowVpwpW6L9w4drnVdQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tL4Ny-0002KQ-5k for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 12:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Dec 2024 17:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 74772 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.17338530438908 (code B ref -1); Tue, 10 Dec 2024 17:51:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 10 Dec 2024 17:50:43 +0000 Original-Received: from localhost ([127.0.0.1]:59499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tL4Ne-0002Jb-OR for submit@debbugs.gnu.org; Tue, 10 Dec 2024 12:50:43 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:56598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tL4Nb-0002JR-Nq for submit@debbugs.gnu.org; Tue, 10 Dec 2024 12:50:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tL4LV-0004Ia-Jk for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 12:48:29 -0500 Original-Received: from mxout6.mail.janestreet.com ([64.215.233.21]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tL4LS-0007RU-EB for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 12:48:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1733852903; bh=rw+tc/bYEMDaJw8SUT7odwFELvCyV/kUzy+GdaAZPOA=; h=From:To:Cc:Subject:Date; b=yiwFIcWtmU8OziLmYHjI1OHSb/dXATyl0WRMZR02JZd0FWpydlnY4TANXETwNQ/3f JgXqy6mMLQwZth4lCmHNIXqyuSyqi1z1pbmhWhNM+TGGYOYgHEmdAYfbAjwBza2NOl Q4Qo/9QZw/Rp7n7qwwAaZ1ovFLXTPKPTo2hTCCwXKQAUTj07nkBy82t5FwWuSXHpDj 7y7pycWzcBbxutEgLykConliX6uWYEUJddu22PKxDPTB+tdZiBqVaDI95p2q44QEhB I9aA9u8ronYP0u3SU1rKi0Bh3dCYHk9ADogFRa+6AW7SubWMeyNhLMwUKCYV6pEpp2 GJNvr0A5kOhLQ== Received-SPF: pass client-ip=64.215.233.21; envelope-from=sbaugh@janestreet.com; helo=mxout6.mail.janestreet.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296775 Archived-At: --=-=-= Content-Type: text/plain Tags: patch completion-pcm--find-all-completions has two different phases: First we turn the minibuffer text into a regex and matches completion alternatives against it. If that finds no matches, then we strip some text off the completions and minibuffer text and call ourselves recursively to find completions, then filter the results with the removed text (converted into a regex). Because of this, completion-pcm-leading-wildcard had inconsistent behavior: in the second phase, the filter created from the removed text would have a leading wildcard. That effectively adds wildcards in the middle of the minibuffer text at the start of each "word". But the first phrase created a regex which had no such wildcards. Thus, the two phases could get substantially different results. We fix this by changing completion-pcm-leading-wildcard to consistently add a leading wildcard for each word. This was always my intention. * lisp/minibuffer.el (completion-pcm--string->pattern): Include a wildcard after each delimter with completion-pcm-leading-wildcard. * lisp/minibuffer.el (completion-pcm-leading-wildcard): Update docs. * doc/emacs/mini.texi (Completion Styles): Update docs. In GNU Emacs 29.2.50 (build 11, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2024-12-02 built on igm-qws-u22796a Repository revision: ddde0f4eead134864c7db775c0aeb93f201c35f6 Repository branch: my-emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.10 (Green Obsidian) Configured using: 'configure --with-x-toolkit=lucid --without-gpm --without-gconf --without-selinux --without-imagemagick --with-modules --with-gif=no --with-tree-sitter --with-native-compilation=aot PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-Consistently-add-wildcards-for-completion-pcm-leadin.patch >From c6229d0dc2d78486dac00e5a8a1d6f95a08b80fd Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 10 Dec 2024 12:41:49 -0500 Subject: [PATCH] Consistently add wildcards for completion-pcm-leading-wildcard completion-pcm--find-all-completions has two different phases: First we turn the minibuffer text into a regex and matches completion alternatives against it. If that finds no matches, then we strip some text off the completions and minibuffer text and call ourselves recursively to find completions, then filter the results with the removed text (converted into a regex). Because of this, completion-pcm-leading-wildcard had inconsistent behavior: in the second phase, the filter created from the removed text would have a leading wildcard. That effectively adds wildcards in the middle of the minibuffer text at the start of each "word". But the first phrase created a regex which had no such wildcards. Thus, the two phases could get substantially different results. We fix this by changing completion-pcm-leading-wildcard to consistently add a leading wildcard for each word. This was always my intention. * lisp/minibuffer.el (completion-pcm--string->pattern): Include a wildcard after each delimter with completion-pcm-leading-wildcard. * lisp/minibuffer.el (completion-pcm-leading-wildcard): Update docs. * doc/emacs/mini.texi (Completion Styles): Update docs. --- doc/emacs/mini.texi | 6 +++--- lisp/minibuffer.el | 17 +++++++++-------- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/doc/emacs/mini.texi b/doc/emacs/mini.texi index 0fcd24ed79d..8e0d58d0f7c 100644 --- a/doc/emacs/mini.texi +++ b/doc/emacs/mini.texi @@ -577,9 +577,9 @@ Completion Styles @vindex completion-pcm-leading-wildcard If @code{completion-pcm-leading-wildcard} is set to @code{t}, this style -always acts as if a @dfn{wildcard} is present at the start of the -minibuffer text, similar to the @code{substring} style. For example, -@samp{l-m} will complete to @samp{emacs-lisp-mode}. +always acts as if a @dfn{wildcard} is present at the start of each word +in the minibuffer text, similar to the @code{substring} style. For +example, @samp{l-ode} will complete to @samp{emacs-lisp-mode}. @item emacs22 @cindex @code{emacs22}, completion style diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 2d27fef44ab..cf9ff46e572 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3996,17 +3996,18 @@ completion-pcm--pattern-trivial-p trivial))) (defcustom completion-pcm-leading-wildcard nil - "If non-nil, partial-completion completes as if there's a leading wildcard. + "If non-nil, partial-completion adds a leading wildcard for each word. -If nil (the default), partial-completion requires a matching completion -alternative to have the same beginning as the first \"word\" in the -minibuffer text, where \"word\" is determined by +If nil (the default), partial-completion requires each word in a +matching completion alternative to have the same beginning as each +\"word\" in the minibuffer text, where \"word\" is determined by `completion-pcm-word-delimiters'. If non-nil, partial-completion allows any string of characters to occur -at the beginning of a completion alternative, as if a wildcard such as -\"*\" was present at the beginning of the minibuffer text. This makes -partial-completion behave more like the substring completion style." +at the beginning of each word in a completion alternative, as if a +wildcard such as \"*\" was present at the beginning of each word. This +makes partial-completion behave more like the substring completion +style." :version "31.1" :type 'boolean) @@ -4053,7 +4054,7 @@ completion-pcm--string->pattern (setq p0 p) (push (substring string p (match-end 0)) pattern) ;; `any-delim' is used so that "a-b" also finds "array->beginning". - (setq pending 'any-delim) + (setq pending (if completion-pcm-leading-wildcard 'prefix 'any-delim)) (setq p0 (match-end 0)))) (setq p p0)) -- 2.39.3 --=-=-=--