From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.bugs Subject: bug#65137: 29.1; completion-substring-try-completion doesn't return the longest common substring Date: Tue, 08 Aug 2023 12:40:01 +0000 (UTC) Message-ID: <875y5pk8rj.fsf@catern.com> References: <83a5v1okwm.fsf@gnu.org> 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="16344"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Spencer Baugh , Stefan Monnier , 65137@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 08 14:41:13 2023 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 1qTM1Q-00044w-4c for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 08 Aug 2023 14:41:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTM1K-0003aW-Ma; Tue, 08 Aug 2023 08:41:06 -0400 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 1qTM1G-0003ZN-IW for bug-gnu-emacs@gnu.org; Tue, 08 Aug 2023 08:41:04 -0400 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 1qTM1F-0004fU-U3 for bug-gnu-emacs@gnu.org; Tue, 08 Aug 2023 08:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qTM1F-0007NF-Pl for bug-gnu-emacs@gnu.org; Tue, 08 Aug 2023 08:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: sbaugh@catern.com Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Aug 2023 12:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65137 X-GNU-PR-Package: emacs Original-Received: via spool by 65137-submit@debbugs.gnu.org id=B65137.169149840928271 (code B ref 65137); Tue, 08 Aug 2023 12:41:01 +0000 Original-Received: (at 65137) by debbugs.gnu.org; 8 Aug 2023 12:40:09 +0000 Original-Received: from localhost ([127.0.0.1]:35487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTM0O-0007Lu-QB for submit@debbugs.gnu.org; Tue, 08 Aug 2023 08:40:09 -0400 Original-Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:12222) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qTM0M-0007LL-Ul for 65137@debbugs.gnu.org; Tue, 08 Aug 2023 08:40:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: cc:content-type:from:subject:to; s=s1; bh=ZwIFR48YET0vxH4lTSdnWqtXXBGJxdmoxbdxPy5AaYw=; b=R6M9emzXJezgBrBVfCh3gnPw9pmD9fWFLijpKgZhk9IH4L6ixbUlOm5o3zw5Y2deleFS YwsAB3e9wArOc85bQ17j/uSFO7j06uHB9JGy00cLCSLCRvRr6yVOaAhfIy6TdilRj6+4cv co6MJnnEl9M4cxShYFjOgAw0KspdeIHYT4P38D51P8pQhws7aWDSlH5GWFdIzGJ2QbK0I5 MD0sxlJF3PAQLAE18Rh8CiGUwgEgGPv1qvjFCHHrMsFcLlf1vekGmovQluICf9QN2nYNeg ENvxq34n/mEr8ZNzh7VFot2JAjZLocBlg7xSkehWMWqgSSOwHWPUBIR5V5Qf7vog== Original-Received: by filterdrecv-d7bbbc8bf-5tzkl with SMTP id filterdrecv-d7bbbc8bf-5tzkl-1-64D237A1-3 2023-08-08 12:40:01.230615167 +0000 UTC m=+1517970.612753905 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-15 (SG) with ESMTP id hKdtv99BRqOFW27OGeIWJA Tue, 08 Aug 2023 12:40:01.149 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Original-Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id B2C6F60080; Tue, 8 Aug 2023 08:40:00 -0400 (EDT) In-Reply-To: <83a5v1okwm.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 08 Aug 2023 14:04:09 +0300") X-SG-EID: ZgbRq7gjGrt0q/Pjvxk7wM0yQFRdOkTJAtEbkjCkHbK9GmGdCsIOC1DpypswWWhsnMTsSJMIV7AwwV9E2jzsmrOjd0ZdQyF7L50d6flRF92+Vc7jyMKK1gcntx2J3oc2knX9kGoFEenyq4NjqkHY2qF2goz1ruI6hfsv8X2pRnFqnDMS1++DE+iFbmueWejZre0ykOKbD4DQMAOhNDeYZA== X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== 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:266948 Archived-At: --=-=-= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eli Zaretskii writes: >> From: Spencer Baugh >> Date: Mon, 07 Aug 2023 19:24:15 -0400 >> >> >> The substring completion style differs from the "basic" style by >> performing completion at the start of the input string. So for example, >> both of these are valid completions for "bar": >> >> (completion-substring-all-completions "bar" '("foobar" "foobarbaz") #'identity (length "bar")) >> -> ("foobarbaz" "foobar" . 0) >> >> However, the substring completion style's try-completion implementation >> does not reflect this. Since "foobar" is a prefix of all the valid >> completions, it should be returned by try-completion. But it is not, >> regardless of the location of point: >> >> (completion-substring-try-completion "bar" '("foobar" "foobarbaz") #'identity 0) >> -> ("bar" . 3) >> >> (completion-substring-try-completion "bar" '("foobar" "foobarbaz") #'identity (length "bar")) >> -> ("bar" . 3) >> >> This breaks completion when one completion candidate is a prefix of >> other completion candidates. The recourse is moving point to the start >> of the input, so that the "basic" completion style takes over, which >> will correctly insert the common prefix: >> >> (completion-basic-try-completion "bar" '("foobar" "foobarbaz") #'identity 0) >> -> ("foobar" . 6) >> >> However, even this does not work in the project-file and xref-location >> completion categories, for which the "basic" style is not included in >> completion-category-defaults. For such completion categories, there's >> simply no way to use completion to insert a common prefix. This is bad, >> because a filename or identifier might easily be a prefix of another >> filename or identifier. >> >> The solution is completion-substring-try-completion to be fixed to >> insert these common prefixes. I'll try and fix this, although the code >> is a bit intimidating. > > Adding Stefan, in case he has some comments or ideas. See also (v2 of) my patch. Now a one-line change, much simpler than my earlier patch: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Correctly-handle-common-prefixes-in-substring-comple.patch >From 48627fdedf44aa48f235c4c550318d0ad2500c16 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 8 Aug 2023 08:37:49 -0400 Subject: [PATCH] Correctly handle common prefixes in substring completion substring completion is implemented by passing the `prefix' symbol as part of the pattern passed to completion-pcm--merge-completions. This symbol is supposed to "grow" the completion only as a suffix, not as a prefix. The old behavior of completion-pcm--merge-completions when processing a `prefix' element in the pattern was to find the common prefix of all the completions in that part of the pattern (using try-completion) and then completely discard that common prefix. Then the actual logic for `prefix' would run with completion--common-suffix. However, the completion--common-suffix logic would be skipped when the prefix covers the entirety of this part of the pattern. (When "unique" is non-nil, in the code). For example, in this call: (completion-pcm--merge-completions '("ab" "ab") '(star "b")) -> ("b" "a") there is no need to calculate a common suffix of '("a" "a") after finding the common prefix "a". (Note the return value is in reverse order.) But for `prefix', we discard the common prefix, so this behavior would result in us skipping the calculation of both common prefix and common suffix. Like in this call: (completion-pcm--merge-completions '("ab" "ab") '(prefix "b")) -> ("b") The correct behavior is to include the common prefix even for `prefix' elements if it covers the entirety of this part of the pattern, because then it is then also a common suffix. Then we get: (completion-pcm--merge-completions '("ab" "ab") '(prefix "b")) -> ("b" "a") which is correct. * lisp/minibuffer.el (completion-pcm--merge-completions): Don't ignore a common suffix in a `prefix' pattern element when there's also a common prefix. --- lisp/minibuffer.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 186a4753df1..cc50427b5bd 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -4029,7 +4029,9 @@ completion-pcm--merge-completions (unique (or (and (eq prefix t) (setq prefix fixed)) (and (stringp prefix) (eq t (try-completion prefix comps)))))) - (unless (or (eq elem 'prefix) + ;; if the common prefix is unique, it also is a common + ;; suffix, so we should add it for `prefix' elements + (unless (or (and (eq elem 'prefix) (not unique)) (equal prefix "")) (push prefix res)) ;; If there's only one completion, `elem' is not useful -- 2.41.0 --=-=-=--