Awful completion buffer behaviour

Awful completion buffer behaviour

[Po Lu]

Pressing tab in the minibuffer when a completions buffer is visible used
to scroll the window containing that buffer.

In Emacs 29, it selects that window instead, and moves point to the next
visible completion.

That behaviour is horrid, and even worse, I didn't find a NEWS entry
detailing how to turn it off (it should be off by default anyway).

Please remove the offending change or put it behind a switch.  Thanks.

Re: Awful completion buffer behaviour

[Juri Linkov]

> Pressing tab in the minibuffer when a completions buffer is visible used
> to scroll the window containing that buffer.
>
> In Emacs 29, it selects that window instead, and moves point to the next
> visible completion.

Maybe TAB should not try to switch to the completions buffer
when it's already visible.

Re: Awful completion buffer behaviour

[Po Lu]

Juri Linkov <juri@linkov.net> writes:

>> Pressing tab in the minibuffer when a completions buffer is visible used
>> to scroll the window containing that buffer.
>>
>> In Emacs 29, it selects that window instead, and moves point to the next
>> visible completion.
>
> Maybe TAB should not try to switch to the completions buffer
> when it's already visible.

I think TAB should scroll the window containing the buffer, and if it is
not visible, it should make the buffer visible without selecting it.

Otherwise, you have to press C-x o if you want to continue typing
without selecting anything.

Re: Awful completion buffer behaviour

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Pressing tab in the minibuffer when a completions buffer is visible used
> to scroll the window containing that buffer.
>
> In Emacs 29, it selects that window instead, and moves point to the next
> visible completion.
>
> That behaviour is horrid, and even worse, I didn't find a NEWS entry
> detailing how to turn it off (it should be off by default anyway).
>
> Please remove the offending change or put it behind a switch.  Thanks.

If nobody minds, I will add a NEWS entry about `completion-auto-select'
and disable it by default.

Thanks.

Re: Awful completion buffer behaviour

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Wed, 22 Dec 2021 11:10:57 +0800
> 
> Pressing tab in the minibuffer when a completions buffer is visible used
> to scroll the window containing that buffer.
> 
> In Emacs 29, it selects that window instead, and moves point to the next
> visible completion.
> 
> That behaviour is horrid, and even worse, I didn't find a NEWS entry
> detailing how to turn it off (it should be off by default anyway).
> 
> Please remove the offending change or put it behind a switch.  Thanks.

I agree that this new behavior is an unpleasant surprise for me.

I'm not sure I understand the purpose of the month-long experiment
with turning this on by default.  Is it to decide whether it will stay
on in Emacs 29?  If so, the experiment can be terminated now: we will
not make this the default, certainly not in Emacs 29, and maybe not
even in Emacs 30.  It is too radical departure of age-old Emacs
behavior in the default completion commands.

If the reason for the experiment is to decide whether to revert this
change because this behavior is hated too much, we can continue with
the experiment, of course.  But I don't see why we shouldn't offer
this as optional behavior anyway, so I think the experiment is not
needed, and the best way ahead is to document this as optional
behavior, and turn it off by default.

Thanks.

Re: Awful completion buffer behaviour

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I agree that this new behavior is an unpleasant surprise for me.
>
> I'm not sure I understand the purpose of the month-long experiment
> with turning this on by default.  Is it to decide whether it will stay
> on in Emacs 29?  If so, the experiment can be terminated now: we will
> not make this the default, certainly not in Emacs 29, and maybe not
> even in Emacs 30.  It is too radical departure of age-old Emacs
> behavior in the default completion commands.

Thanks, will you mind if I install a change that documents the option
in the NEWS entry and changes its default value to nil now?

Thanks.

Re: Awful completion buffer behaviour

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I agree that this new behavior is an unpleasant surprise for me.
>>
>> I'm not sure I understand the purpose of the month-long experiment
>> with turning this on by default.  Is it to decide whether it will stay
>> on in Emacs 29?  If so, the experiment can be terminated now: we will
>> not make this the default, certainly not in Emacs 29, and maybe not
>> even in Emacs 30.  It is too radical departure of age-old Emacs
>> behavior in the default completion commands.
>
> Thanks, will you mind if I install a change that documents the option
> in the NEWS entry and changes its default value to nil now?
>
> Thanks.

Oops, I pushed that by accident when pushing a fix to pgtkterm.c, but I
think it's appropriate anyway, so I'm not going to revert it unless
someone says so.

Thanks.

Re: Awful completion buffer behaviour

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 20:56:00 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I agree that this new behavior is an unpleasant surprise for me.
> >
> > I'm not sure I understand the purpose of the month-long experiment
> > with turning this on by default.  Is it to decide whether it will stay
> > on in Emacs 29?  If so, the experiment can be terminated now: we will
> > not make this the default, certainly not in Emacs 29, and maybe not
> > even in Emacs 30.  It is too radical departure of age-old Emacs
> > behavior in the default completion commands.
> 
> Thanks, will you mind if I install a change that documents the option
> in the NEWS entry and changes its default value to nil now?

I'd like to hear from Juri and Philip first.

Re: Awful completion buffer behaviour

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 21:35:32 +0800
> 
> > Thanks, will you mind if I install a change that documents the option
> > in the NEWS entry and changes its default value to nil now?
> >
> > Thanks.
> 
> Oops, I pushed that by accident when pushing a fix to pgtkterm.c

Too bad.

Re: Awful completion buffer behaviour

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 22 Dec 2021 20:56:00 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I agree that this new behavior is an unpleasant surprise for me.
>> >
>> > I'm not sure I understand the purpose of the month-long experiment
>> > with turning this on by default.  Is it to decide whether it will stay
>> > on in Emacs 29?  If so, the experiment can be terminated now: we will
>> > not make this the default, certainly not in Emacs 29, and maybe not
>> > even in Emacs 30.  It is too radical departure of age-old Emacs
>> > behavior in the default completion commands.
>> 
>> Thanks, will you mind if I install a change that documents the option
>> in the NEWS entry and changes its default value to nil now?
>
> I'd like to hear from Juri and Philip first.

The idea was to gather feedback, and this thread is one form of
feedback.  If the feature is as intrusive as described here (for which I
would like to apologise), then it seems like it should be disabled.

-- 
	Philip Kaludercic

Re: Awful completion buffer behaviour

[Juri Linkov]

> I'm not sure I understand the purpose of the month-long experiment
> with turning this on by default.  Is it to decide whether it will stay
> on in Emacs 29?  If so, the experiment can be terminated now: we will
> not make this the default, certainly not in Emacs 29, and maybe not
> even in Emacs 30.  It is too radical departure of age-old Emacs
> behavior in the default completion commands.
>
> If the reason for the experiment is to decide whether to revert this
> change because this behavior is hated too much, we can continue with
> the experiment, of course.  But I don't see why we shouldn't offer
> this as optional behavior anyway, so I think the experiment is not
> needed, and the best way ahead is to document this as optional
> behavior, and turn it off by default.

Like Philip already said the idea was to gather feedback,
both positive and negative, to decide how to develop this feature further.

Note that no one complained about the default value of another variable
'completion-wrap-movement' that is enabled now too.

So now it's clear we have two possible directions: try to find such new keys
that don't get in the way in the long-standing usage scenarios, and provide
more variables (possibly optional) for customization.

Re: Awful completion buffer behaviour

[Juri Linkov]

>>> Pressing tab in the minibuffer when a completions buffer is visible used
>>> to scroll the window containing that buffer.
>>>
>>> In Emacs 29, it selects that window instead, and moves point to the next
>>> visible completion.
>>
>> Maybe TAB should not try to switch to the completions buffer
>> when it's already visible.
>
> I think TAB should scroll the window containing the buffer, and if it is
> not visible, it should make the buffer visible without selecting it.
>
> Otherwise, you have to press C-x o if you want to continue typing
> without selecting anything.

Please note that auto-selecting the completions buffer might still
be useful when using completion-at-point (C-M-i) in any buffer
because there is no easy-to-type key to select it.
So would be nice if 'completion-auto-select' allowed
auto-selection only for completion-at-point.

Re: Awful completion buffer behaviour

[Robert Pluim]

>>>>> On Wed, 22 Dec 2021 19:40:00 +0200, Juri Linkov <juri@linkov.net> said:

    Juri> Note that no one complained about the default value of another variable
    Juri> 'completion-wrap-movement' that is enabled now too.

I donʼt see that in NEWS.

Robert
-- 

Re: Awful completion buffer behaviour

[Juri Linkov]

>>>>>> On Wed, 22 Dec 2021 19:40:00 +0200, Juri Linkov <juri@linkov.net> said:
>
>     Juri> Note that no one complained about the default value of another variable
>     Juri> 'completion-wrap-movement' that is enabled now too.
>
> I donʼt see that in NEWS.

I agree it should be mentioned in NEWS.