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?
prev parent 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.