unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 74420@debbugs.gnu.org
Subject: bug#74420: 31.0.50; PCM completion for ~/src/emacs/trunk/*/minibuf breaks
Date: Wed, 27 Nov 2024 14:30:36 -0500	[thread overview]
Message-ID: <ierfrncfp9f.fsf@janestreet.com> (raw)
In-Reply-To: <ierwmgzz7ix.fsf@janestreet.com> (Spencer Baugh's message of "Tue, 19 Nov 2024 08:18:30 -0500")

Spencer Baugh <sbaugh@janestreet.com> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Actually... I just realized this misses some cases, namely when we have
>>> "star point" or "point star".
>>
>> FWIW, my local patches have included for years optimizations like the
>> ones you suggested *and* they replaced `star point` and `point star`
>> with just `star`.
>>
>> Do you think it's important to preserve `point` in those cases?
>
> Hm, I'm not sure.  I've been playing around with alternative ways to
> move point in pcm-try-completion but haven't yet got something I'm
> satisfied with.  So let me defer this question until I've hacked on that
> some more :)

Okay, so I ended up not wanting to move point.

What I have instead now is something which explicitly inserts a * in the
minibuffer, specifically with completion-pcm-leading-wildcard:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 01502235403..db13c659004 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3925,7 +3925,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 'star 'any-delim))
             (setq p0 (match-end 0))))
         (setq p p0))
 
@@ -3935,7 +3935,7 @@ completion-pcm--string->pattern
       (setq pattern (nreverse pattern))
       (when completion-pcm-leading-wildcard
         (when (stringp (car pattern))
-          (push 'prefix pattern)))
+          (push 'star pattern)))
       pattern)))
 
 (defun completion-pcm--optimize-pattern (p)
-- 
2.39.3


This does two things:

- completion-pcm-leading-wildcard previously had inconsistent behavior:
  if completion-pcm--find-all-completions makes a recursive call,
  completion-pcm-leading-wildcard would effectively add a leading
  wildcard to each component.  But that wouldn't happen if the original
  pattern happens to match, in the first completion-pcm--all-completions
  call.  To make them behave identically, now
  completion-pcm-leading-wildcard changes the 'any-delim inserted at the
  start of each component into a proper wildcard.  This is just a
  bugfix.

- More radically, actually insert a * in the minibuffer text if we run
  completion-pcm-try-completion with completion-pcm-leading-wildcard=t.

Inserting a * is pretty nice for multiple reasons.

Paradoxically, inserting a * makes things more efficient for the
configuration I intend people to use, where completion-styles contains:

... partial-completion (partial-completion ((completion-pcm-leading-wildcard t))) ...

With this configuration, if partial-completion fails, we make one call
to the expensive completion-pcm-leading-wildcard=t mode, and then
afterwards the explicit *s cause us to stay in regular
partial-completion, with only the exact amount of leading wildcards that
we actually need, rather than having an extra 'prefix wildcard at the
start of every single component.

And, inserting the * ensures that we stay in this "leading wildcard"
mode.  I've found that tab-completing with
completion-pcm-leading-wildcard tends to sometimes change the minibuffer
contents such that subsequent tab-completions get handled by another
completion style.  With leading wildcards, that's pretty undesirable,
because it can make the set of completions much narrower.  But
explicitly inserting the * forces the leading-wildcard behavior to stay
around.

And it just looks pretty good: because the 'star wildcards are removed
if they can't expand to anything, when you hit TAB the * are basically
inserted everywhere that you might add new text.  This is pretty neat.

I usually use completion-pcm-leading-wildcard with project-find-file,
so e.g. this is a decent way to test:

(setf (alist-get 'project-file completion-category-overrides)
      '((styles basic partial-completion (partial-completion ((completion-pcm-leading-wildcard t))))))

Then C-x p f in the Emacs repo

What do you think?





      reply	other threads:[~2024-11-27 19:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-18 17:33 bug#74420: 31.0.50; PCM completion for ~/src/emacs/trunk/*/minibuf breaks Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-18 17:36 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-18 20:39   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-18 22:17     ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-18 23:58       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-19 13:18         ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-27 19:30           ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]

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=ierfrncfp9f.fsf@janestreet.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=74420@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=sbaugh@janestreet.com \
    /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).