emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs 29 expand command in minibuf


From: Stefan Monnier
Subject: Re: emacs 29 expand command in minibuf
Date: Tue, 21 Jun 2022 16:31:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]