unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 70217@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#70217: [PATCH] Add substring-partial-completion style
Date: Tue, 28 May 2024 16:01:53 -0400	[thread overview]
Message-ID: <ierzfs94sem.fsf@janestreet.com> (raw)
In-Reply-To: <86bk4pu4ip.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 May 2024 22:21:02 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: 70217@debbugs.gnu.org,  monnier@iro.umontreal.ca
>> Date: Tue, 28 May 2024 14:51:37 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Spencer Baugh <sbaugh@janestreet.com>
>> >> 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.





  reply	other threads:[~2024-05-28 20:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05 12:41 bug#70217: [PATCH] Add substring-partial-completion style Spencer Baugh
2024-04-05 18:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-05 19:46   ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-06  8:10     ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-18 15:19   ` Spencer Baugh
2024-05-08 16:46     ` Spencer Baugh
2024-05-08 17:14       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-16 20:26         ` Spencer Baugh
2024-05-16 22:09           ` Daniel Mendler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-17  6:23           ` Eli Zaretskii
2024-05-25 21:22             ` Spencer Baugh
2024-05-26  7:56               ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-26 12:49                 ` Spencer Baugh
2024-05-26  9:11               ` Eli Zaretskii
2024-05-26 13:02                 ` Spencer Baugh
2024-05-26 15:51                   ` Eli Zaretskii
2024-05-28 14:39                     ` Spencer Baugh
2024-05-28 15:11                       ` Eli Zaretskii
2024-05-28 18:16                         ` Spencer Baugh
2024-05-28 18:36                           ` Eli Zaretskii
2024-05-28 18:51                             ` Spencer Baugh
2024-05-28 19:21                               ` Eli Zaretskii
2024-05-28 20:01                                 ` Spencer Baugh [this message]
2024-06-01 14:20                                   ` Eli Zaretskii
2024-06-02 12:16                                     ` Spencer Baugh
2024-06-02 14:34                                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-08 13:13                                         ` Spencer Baugh
2024-08-10  8:02                                           ` Eli Zaretskii
2024-08-21 16:01                                             ` Spencer Baugh
2024-08-21 16:16                                               ` Spencer Baugh
2024-08-24  9:23                                                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ierzfs94sem.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=70217@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).