emacs 29 expand command in minibuf

emacs 29 expand command in minibuf

[hx]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

Hi developers and users,
In 28.1 when I execute M-x em-v, it will execute emacs-version immediately,
but in 29, it will expand to emacs-v in mini-buffer first, need to press
enter again.

Could you please tell me which option can make 29 work like 28 ?

[-- Attachment #2: Type: text/html, Size: 345 bytes --]

Re: emacs 29 expand command in minibuf

[Tassilo Horn]

hx <silent2600@gmail.com> writes:

> In 28.1 when I execute M-x em-v, it will execute emacs-version
> immediately, but in 29, it will expand to emacs-v in mini-buffer
> first, need to press enter again.
>
> Could you please tell me which option can make 29 work like 28 ?

The "problem" is that in 29, there's a new command emacs-news-view-mode
which also happens to be a possible match for input "em-v" when
partial-completion is in completion-styles (which it is by default).
That emacs-version is matched by "em-v" is also due to the
partial-completion style, so removing that won't do either.

If you really need emacs-version so frequently that you need a
super-short and unambiguous name for it, define an alias:

  (defalias 'ev #'emacs-version)

Then you can do M-x ev RET.

Bye,
Tassilo

Re: emacs 29 expand command in minibuf

[Stephen Berman]

On Mon, 13 Jun 2022 06:57:27 +0200 Tassilo Horn <tsdh@gnu.org> wrote:

> hx <silent2600@gmail.com> writes:
>
>> In 28.1 when I execute M-x em-v, it will execute emacs-version
>> immediately, but in 29, it will expand to emacs-v in mini-buffer
>> first, need to press enter again.
>>
>> Could you please tell me which option can make 29 work like 28 ?
>
> The "problem" is that in 29, there's a new command emacs-news-view-mode
> which also happens to be a possible match for input "em-v" when
> partial-completion is in completion-styles (which it is by default).
> That emacs-version is matched by "em-v" is also due to the
> partial-completion style, so removing that won't do either.

I think the real problem is that after `M-x em-v TAB' expands the input
to "emacs-v", typing TAB again completes it to "emacs-version" instead
of popping up a *Completions* buffer containing both
"emacs-news-view-mode" and "emacs-version".

Steve Berman

Re: emacs 29 expand command in minibuf

[Stephen Leake]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Mon, 13 Jun 2022 06:57:27 +0200 Tassilo Horn <tsdh@gnu.org> wrote:
>
>> hx <silent2600@gmail.com> writes:
>>
>>> In 28.1 when I execute M-x em-v, it will execute emacs-version
>>> immediately, but in 29, it will expand to emacs-v in mini-buffer
>>> first, need to press enter again.
>>>
>>> Could you please tell me which option can make 29 work like 28 ?
>>
>> The "problem" is that in 29, there's a new command emacs-news-view-mode
>> which also happens to be a possible match for input "em-v" when
>> partial-completion is in completion-styles (which it is by default).
>> That emacs-version is matched by "em-v" is also due to the
>> partial-completion style, so removing that won't do either.
>
> I think the real problem is that after `M-x em-v TAB' expands the input
> to "emacs-v", typing TAB again completes it to "emacs-version" instead
> of popping up a *Completions* buffer containing both
> "emacs-news-view-mode" and "emacs-version".

+1

This behavior (on different but similar cases) bytes me quite often.

-- 
-- Stephe

Re: emacs 29 expand command in minibuf

[Tassilo Horn]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

>> I think the real problem is that after `M-x em-v TAB' expands the
>> input to "emacs-v", typing TAB again completes it to "emacs-version"
>> instead of popping up a *Completions* buffer containing both
>> "emacs-news-view-mode" and "emacs-version".
>
> +1
>
> This behavior (on different but similar cases) bytes me quite often.

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.

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...

Bye,
Tassilo

Re: emacs 29 expand command in minibuf

[Andreas Schwab]

On Jun 18 2022, Tassilo Horn wrote:

> 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.

Try moving basic after partial-completion in completion-styles.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: emacs 29 expand command in minibuf

[Stephen Berman]

On Sat, 18 Jun 2022 09:58:51 +0200 Andreas Schwab <schwab@linux-m68k.org> wrote:

> On Jun 18 2022, Tassilo Horn wrote:
>
>> 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.
>
> Try moving basic after partial-completion in completion-styles.

That fixes this issue, thanks.  So the next question is: Is there a good
reason not to have that order by default?

Steve Berman

Re: emacs 29 expand command in minibuf

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]


Am 13.06.22 um 03:48 schrieb hx:
> Hi developers and users,
> In 28.1 when I execute M-x em-v, it will execute emacs-version 
> immediately,
> but in 29, it will expand to emacs-v in mini-buffer first, need to 
> press enter again.
>
> Could you please tell me which option can make 29 work like 28 ?
>

You may also consider

(set 'frame-title-format '(multiple-frames "%b" ("" invocation-name "@" 
emacs-version)))


in order to get the version always visible.

[-- Attachment #2: Type: text/html, Size: 1197 bytes --]

Re: emacs 29 expand command in minibuf

[Stefan Monnier]

>> 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.
>
> Try moving basic after partial-completion in completion-styles.

I think removing `basic` gives the same result, and is a bit
more efficient.


        Stefan

Re: emacs 29 expand command in minibuf

[Andreas Schwab]

On Jun 18 2022, Stephen Berman wrote:

> That fixes this issue, thanks.  So the next question is: Is there a good
> reason not to have that order by default?

It breaks completion of "/foo/.." for file name completion.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: emacs 29 expand command in minibuf

[Stefan Monnier]

> 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

RE: [External] : Re: emacs 29 expand command in minibuf

[Drew Adams]

This is all a fundamental problem with the design,
which is to always fall back from one style to
another continuing to try to find a completion.

What's needed is to easily be able to choose one
or another style - during completion.

It's important to be able to know whether a given
style matches a candidate.  You may or you may not
want to try another style if the matches for one
style don't give you what you want/expect.

Better than that (being able to choose one style
at a time, on the fly) is to let you choose (again,
during completion) one or another such fallback 
list of styles.  Of course, that includes the case
of singleton fallback lists: one style at a time.

I argued for this decades ago.  And it's what
Icicles offers.

The choice to go with just one list of fallback
styles (per invocation or category of completion)
is, I think, based on the assumption that you
always want to maximize the possibility of getting
a match.  And that's far from the case, in many
contexts.