unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 70217@debbugs.gnu.org
Subject: bug#70217: [PATCH] Add substring-partial-completion style
Date: Thu, 16 May 2024 16:26:32 -0400	[thread overview]
Message-ID: <ierv83dtsef.fsf@janestreet.com> (raw)
In-Reply-To: <jwvedacjkor.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 08 May 2024 13:14:34 -0400")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> * lisp/minibuffer.el (completion-emacs22-use-pcm)
>> (completion-substring-use-pcm): Add. (bug#70217)
>> (completion-emacs22-try-completion)
>> (completion-emacs22-all-completions): Check completion-emacs22-use-pcm.
>> (completion-pcm--string->pattern, completion-pcm--find-all-completions)
>> (completion-pcm-all-completions, completion-pcm--merge-try)
>> (completion-pcm-try-completion): Add "startglob" optional argument and
>> pass through.
>> (completion-substring-try-completion)
>> (completion-substring-all-completions): Check
>> completion-substring-use-pcm and pass startglob=t.
>
> I'm not super happy about this `startglob` everywhere.
> Two things bother me about it:
>
> - Its name and doc (in my view of what "glob" means, there's no such
>   thing as a "leading glob"; I think you're talking about a leading
>   wildcard (which is one of the things that can appear in a glob
>   pattern)).

Yes, very true, changed to "anchored".

> - Its spreading all over the place.

In the attached diff it's a dynamic variable completion-pcm-anchored
checked in one place.  How's that?

> I don't have the time to dig into the second problem (which might be
> fixable by combining this info into the `string` argument (which
> wouldn't be just a string as more, so it could have too-far reaching
> consequences)), but for the first I suspect a "standard" name for this
> idea is `anchored`.
>
> Other than that, I don't have a strong opinion on whether to introduce
> the feature via new styles or as custom vars that affect
> existing styles.  Either way works for me.

As part of making it a dynamic variable, I also changed the usage.  In
the attached diff, an element in completion-styles can contain
additional dynamic variable bindings:

(setq completion-styles '(basic (partial-completion (completion-pcm-anchored nil)) emacs22))

This is powerful and elegant in some ways - for example now a user could
use completion-ignore-case only for an individual style.  Also, the
overall diff is now much shorter.

But it may be a bit too powerful.

Also, now completion uses cl-progv, which internally uses eval, which
might be undesirable.  Maybe that could be solved with a C
implementation of cl-progv?  I think a C implementation of cl-progv
might also be useful for my native modules, so I'd be happy to implement
that if it seems like a good idea.

Also, it's somewhat hard to expose this new power via customize (I
haven't bothered to update the customize type for it yet in this diff)

What do you think?

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5ce5aab5c7e..7110e7f573d 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1218,11 +1218,18 @@ completion--nth-completion
          (result-and-style
           (completion--some
            (lambda (style)
-             (let ((probe (funcall
-                           (or (nth n (assq style completion-styles-alist))
-                               (error "Invalid completion style %s" style))
-                           string table pred point)))
-               (and probe (cons probe style))))
+             (let (symbols values)
+               (when (consp style)
+                 (dolist (binding (cdr style))
+                   (push (car binding) symbols)
+                   (push (cadr binding) values))
+                 (setq style (car style)))
+               (cl-progv symbols values
+                 (let ((probe (funcall
+                               (or (nth n (assq style completion-styles-alist))
+                                   (error "Invalid completion style %s" style))
+                               string table pred point)))
+                   (and probe (cons probe style))))))
            (completion--styles md)))
          (adjust-fn (get (cdr result-and-style) 'completion--adjust-metadata)))
     (when (and adjust-fn metadata)
@@ -3780,6 +3787,17 @@ completion-pcm--pattern-trivial-p
 	     (setq trivial nil)))
 	 trivial)))
 
+(defcustom completion-pcm-anchored t
+  "If nil, the partial-completion style expands at the start of a string.
+
+If non-nil, then expansion at the start of a string only happens
+if the string begins with a wildcard.
+
+For example, if this is nil then \"b/c\" will match
+\"aaa/bbb/ccc\"."
+  :version "30.1"
+  :type 'boolean)
+
 (defun completion-pcm--string->pattern (string &optional point)
   "Split STRING into a pattern.
 A pattern is a list where each element is either a string
@@ -3830,7 +3848,12 @@ completion-pcm--string->pattern
       (when (> (length string) p0)
         (if pending (push pending pattern))
         (push (substring string p0) pattern))
-      (nreverse pattern))))
+      (setq pattern (nreverse pattern))
+      (unless completion-pcm-anchored
+        (when (stringp (car pattern))
+          (push 'prefix pattern)))
+      pattern)))
 
 (defun completion-pcm--optimize-pattern (p)
   ;; Remove empty strings in a separate phase since otherwise a ""





  reply	other threads:[~2024-05-16 20:26 UTC|newest]

Thread overview: 26+ 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 [this message]
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
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

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=ierv83dtsef.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=70217@debbugs.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).