From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#70217: [PATCH] Add substring-partial-completion style Date: Tue, 28 May 2024 16:01:53 -0400 Message-ID: References: <86a5kpgdo7.fsf@gnu.org> <86ttilvsy8.fsf@gnu.org> <86ikz0wozc.fsf@gnu.org> <86o78qt1hl.fsf@gnu.org> <86fru1u6km.fsf@gnu.org> <86bk4pu4ip.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19904"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 70217@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 28 22:03:09 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 1sC32K-0004rE-My for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 May 2024 22:03:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sC327-0002lO-5l; Tue, 28 May 2024 16:02:55 -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 1sC325-0002ke-2p for bug-gnu-emacs@gnu.org; Tue, 28 May 2024 16:02:53 -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 1sC324-0008SA-R8 for bug-gnu-emacs@gnu.org; Tue, 28 May 2024 16:02:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sC32E-0002aE-8L for bug-gnu-emacs@gnu.org; Tue, 28 May 2024 16:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 May 2024 20:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70217 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70217-submit@debbugs.gnu.org id=B70217.17169265329837 (code B ref 70217); Tue, 28 May 2024 20:03:02 +0000 Original-Received: (at 70217) by debbugs.gnu.org; 28 May 2024 20:02:12 +0000 Original-Received: from localhost ([127.0.0.1]:55085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sC31P-0002YY-Uo for submit@debbugs.gnu.org; Tue, 28 May 2024 16:02:12 -0400 Original-Received: from mxout1.mail.janestreet.com ([38.105.200.78]:48581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sC31N-0002YH-8m for 70217@debbugs.gnu.org; Tue, 28 May 2024 16:02:10 -0400 In-Reply-To: <86bk4pu4ip.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 May 2024 22:21:02 +0300") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1716926513; bh=4sAsnBE7ppoONy3dy59AdRm8ndJ9u/qqEi0b/utwa2I=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=STjbBA/N8A4QUTqERXcaL1r+uc6VoabpDwi3x4GncgL7tbHnmiMqVTw74cQu96aO7 ONkwm9gg/zW8sz6XhoSGBRhSBSlorCKsTYaEEw3/JXwlOHw4KxThGHxEPObbDpPeXJ xMtTkAp5ojj3JavzZFvQ/3NFrLfktvOOJ5/P2Ud9j19nm+0LsbTFe874Dzeezmjphn J2wjhWiKxPZZQ+iDusIXwkh56NLkyagdOV9A8kNTIZg3QqbjZq7I4sGFm7IlkMib7X V7XvxrvhcMKp3AoduaG+tbFa74dBestmzEVDlhCBD6ya2NhWgxIOd794Vv+A1+DyJT pCKS1Mt1DS3SQ== 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:286124 Archived-At: Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: 70217@debbugs.gnu.org, monnier@iro.umontreal.ca >> Date: Tue, 28 May 2024 14:51:37 -0400 >> >> Eli Zaretskii writes: >> >> >> From: Spencer Baugh >> >> Cc: 70217@debbugs.gnu.org, monnier@iro.umontreal.ca >> >> Date: Tue, 28 May 2024 14:16:30 -0400 >> >> >> >> > and (b) please do not use examples with repeated characters, because >> >> > they can lead readers to make the wrong conclusions due to accidental >> >> > situations. For example, AFAIU valid candidates for "b*/c*" include >> >> > "bcdxyz/c1234" and also "b/x/y/z/c/1/2/3", but readers might >> >> > mistakenly think that "b*" stands for a string made only of "b", or >> >> > that there can be only one slash and it must precede "c". Avoiding >> >> > repeated characters prevents such misunderstandings. >> >> >> >> Excellent point, fixed. >> > >> > Thanks. >> > >> >> > But please (a) don't use "glob" and file wildcard notation, use >> >> > regexps instead; >> >> >> >> True, I removed the word "glob", I agree that's confusing since >> >> e.g. [a-z] or {foo,bar} are valid globs but not valid in >> >> partial-completion. >> >> >> >> Note however that "*" is literally valid syntax with partial-completion, >> >> where as the regexp notation (".*") is not. The partial-completion >> >> documentation already mentions this in (info "(emacs) Completion >> >> Styles"). So I slightly reworded it and continued using "*". >> > >> > Please don't. I really meant what I wrote: "glob" is confusing to >> > users, because of the file-name wildcards connotation. >> > >> > The natural way of describing string patterns in Emacs is regular >> > expressions, not globs. >> >> Just to be clear, if you type C-h v ffap-*-path TAB it will complete to >> variables whose name starts with "ffap-" and end with "-path". This is >> a partial-completion feature which has nothing to do with globs. >> >> I agree that the natural way of describing string patterns in Emacs is >> regular expressions, not globs. There are no globs in this docstring. >> I am mentioning only * which is what partial-completion natively >> supports. * has nothing to do with globs, it is a feature of >> partial-completion which is similar but distinct from shell globs. >> >> partial-completion works in terms of * not regular expressions, so it >> would be confusing to use a regular expression here. > > I know. But you are not talking about partial completion in that > text, you are talking about strings that match or don't match. The > natural way of describing those is regular expressions. Okay, I'll remove mention of matching, and try to make it clear that I'm just talking about completion. How about one of the following two options? If non-nil, partial-completion completes as if there's a leading wildcard. 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 `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. Or: If non-nil, partial-completion completes as if there's a leading wildcard. partial-completion interprets "*" as a wildcard, replacing it with any string of characters while completing. partial-completion also adds wildcards before characters in `completion-pcm-word-delimiters', and adds a wildcard at the end of the minibuffer text; the behavior is identical to typing "*" at all of those sites. If nil (the default), "a/b" will complete the same as if you had typed "a*/b*". If non-nil, partial-completion additionally adds a wildcard at the start of the string; then "a/b" will complete the same as if you had typed "*a*/b*". This makes partial-completion behave more like the substring completion style.