From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Tassilo Horn <tsdh@gnu.org>
Cc: Stephen Leake <stephen_leake@stephe-leake.org>,
Stephen Berman <stephen.berman@gmx.net>,
hx <silent2600@gmail.com>,
emacs-devel@gnu.org
Subject: Re: emacs 29 expand command in minibuf
Date: Tue, 21 Jun 2022 16:31:02 -0400 [thread overview]
Message-ID: <jwva6a5u5r4.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87v8syquog.fsf@gnu.org> (Tassilo Horn's message of "Sat, 18 Jun 2022 09:37:07 +0200")
> Indeed, that looks at least surprising. When you do em-v<TAB> the basic
> completion style cannot do anything and so the partial-completion style
> completes to emacs-v which is the common prefix of both emacs-version
> and emacs-news-view-mode for this style. But when doing emacs-v<TAB>
> afterwards, the basic style can complete and only to emacs-version.
Indeed, the way most/all `completion-try-completion` functions are
designed such that the returned string results in the exact same set of
matching candidates *when using the same style*.
That can result in surprises when the returned string ends up suddenly
having matching candidates in styles with higher-priority, which thus
"capture" the completion.
For `partial-completion`, it might be possible to work around this
problem by making it try the higher-priority styles to detect such
captures and "neuter" them by adding appropriate `*` e.g. completing
`em-v` to `emacs*-v` instead of to `emacs-v`.
Not sure how easy/ugly it would be, but it doesn't sound impossible
(even more so if we limit ourselves to targetting the case of `basic`
completion).
> Maybe there should be a way to "lock in" a completion style, i.e., when
> a more fuzzy style has computed completions in a previous step, it
> should not fall back to a more strict one later in the process. Now of
> course, there are more completion-styles than those in vanilla so the
> level of fuzzyness is not known for all...
That's another approach, indeed, tho "later in the process" is sadly
ill-defined, so we'd have to find a heuristic which works well enough.
Stefan
next prev parent reply other threads:[~2022-06-21 20:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 1:48 emacs 29 expand command in minibuf hx
2022-06-13 4:57 ` Tassilo Horn
2022-06-13 11:06 ` Stephen Berman
2022-06-17 22:15 ` Stephen Leake
2022-06-18 7:37 ` Tassilo Horn
2022-06-18 7:58 ` Andreas Schwab
2022-06-18 8:32 ` Stephen Berman
2022-06-21 14:39 ` Andreas Schwab
2022-06-18 13:30 ` Stefan Monnier
2022-06-21 20:31 ` Stefan Monnier [this message]
2022-06-21 20:56 ` [External] : " Drew Adams
2022-06-18 8:39 ` Andreas Röhler
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=jwva6a5u5r4.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=silent2600@gmail.com \
--cc=stephen.berman@gmx.net \
--cc=stephen_leake@stephe-leake.org \
--cc=tsdh@gnu.org \
/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).