master f6967d2 1/3: Allow for the completion buffer to be automatically selected

master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Daniel Martín]

I don't think I like this change to the minibuffer defaults.  It breaks
muscle memory and IMO is more incovenient when you need to show the
completion list many times.

One typical workflow I have is doing something like C-x C-f TAB TAB to
see the list of completions and then continue typing to narrow the list
of completions.  After this commit, you need to switch back to the
minibuffer to continue completing things, which is annoying.

I'd prefer that the new setting completion-auto-select is not enabled by
default.  What do other people think?

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Juri Linkov]

> I don't think I like this change to the minibuffer defaults.  It breaks
> muscle memory and IMO is more incovenient when you need to show the
> completion list many times.

But now it works exactly like in other apps.  For example, open a new
browser tab, and it immediately switches focus to its completion list
where you can select a completion candidate with arrow keys.  Now Emacs
does the same.

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Po Lu]

Juri Linkov <juri@linkov.net> writes:

> But now it works exactly like in other apps.

[...]

> For example, open a new browser tab, and it immediately switches focus
> to its completion list where you can select a completion candidate
> with arrow keys.  Now Emacs does the same.

In other apps, you can continue typing even when a completion candidate
is selected.

Not so in Emacs.

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> For example, open a new browser tab, and it immediately switches focus
>> to its completion list where you can select a completion candidate
>> with arrow keys.  Now Emacs does the same.
>
> In other apps, you can continue typing even when a completion candidate
> is selected.

Yeah, the new behaviour would be better if you could continue typing.
It's too awkward currently.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Juri Linkov]

>> For example, open a new browser tab, and it immediately switches focus
>> to its completion list where you can select a completion candidate
>> with arrow keys.  Now Emacs does the same.
>
> In other apps, you can continue typing even when a completion candidate
> is selected.

True (although navigating in completions inserts every navigated completion
to their minibuffer, thus replacing the initial contents, this could be
optional in Emacs).

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[tomas]

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

On Wed, Dec 22, 2021 at 10:58:43AM +0200, Juri Linkov wrote:
> > I don't think I like this change to the minibuffer defaults.  It breaks
> > muscle memory and IMO is more incovenient when you need to show the
> > completion list many times.
> 
> But now it works exactly like in other apps.  For example, open a new
> browser tab, and it immediately switches focus to its completion list
> where you can select a completion candidate with arrow keys.  Now Emacs
> does the same.

Which I, personally, hate with passion (even though you can continue
typing, as Po Lu notes in this thread).

But hey, that's browsers.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Philip Kaludercic]

Daniel Martín <mardani29@yahoo.es> writes:

> I don't think I like this change to the minibuffer defaults.  It breaks
> muscle memory and IMO is more incovenient when you need to show the
> completion list many times.
>
> One typical workflow I have is doing something like C-x C-f TAB TAB to
> see the list of completions and then continue typing to narrow the list
> of completions.  After this commit, you need to switch back to the
> minibuffer to continue completing things, which is annoying.

Understandable, enabling the options by default is just an experiment
for now to gather feedback.

What would you think about completion-auto-select could also be set to a
number, indicating how many non-completions have to be made before
*Completions* is selected?

> I'd prefer that the new setting completion-auto-select is not enabled by
> default.  What do other people think?

-- 
	Philip Kaludercic

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Juri Linkov]

> What would you think about completion-auto-select could also be set to a
> number, indicating how many non-completions have to be made before
> *Completions* is selected?

So when completion-auto-select is 1 then select the completions buffer on
the first TAB?  When 2, then the second TAB will select it instead of
starting to scroll the completions buffer.  But I don't think anyone might
want to customize it to a number more than 2.

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>> What would you think about completion-auto-select could also be set to a
>> number, indicating how many non-completions have to be made before
>> *Completions* is selected?
>
> So when completion-auto-select is 1 then select the completions buffer on
> the first TAB?  When 2, then the second TAB will select it instead of
> starting to scroll the completions buffer.  But I don't think anyone might
> want to customize it to a number more than 2.

Probably true, but if you implement support for 1 and 2, all other
natnums are trivial.

But on second thought, this won't do the job either, since scrolling on
tab and selecting on tab are always in conflict with one another.

-- 
	Philip Kaludercic

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Date: Wed, 22 Dec 2021 20:02:59 +0000
> Cc: emacs-devel@gnu.org, Daniel Martín <mardani29@yahoo.es>
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> >> What would you think about completion-auto-select could also be set to a
> >> number, indicating how many non-completions have to be made before
> >> *Completions* is selected?
> >
> > So when completion-auto-select is 1 then select the completions buffer on
> > the first TAB?  When 2, then the second TAB will select it instead of
> > starting to scroll the completions buffer.  But I don't think anyone might
> > want to customize it to a number more than 2.
> 
> Probably true, but if you implement support for 1 and 2, all other
> natnums are trivial.
> 
> But on second thought, this won't do the job either, since scrolling on
> tab and selecting on tab are always in conflict with one another.

Indeed, if we ever want to have some of these features turned ON by
default, they cannot be on TAB.

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Juri Linkov]

>>> What would you think about completion-auto-select could also be set to a
>>> number, indicating how many non-completions have to be made before
>>> *Completions* is selected?
>>
>> So when completion-auto-select is 1 then select the completions buffer on
>> the first TAB?  When 2, then the second TAB will select it instead of
>> starting to scroll the completions buffer.  But I don't think anyone might
>> want to customize it to a number more than 2.
>
> Probably true, but if you implement support for 1 and 2, all other
> natnums are trivial.
>
> But on second thought, this won't do the job either, since scrolling on
> tab and selecting on tab are always in conflict with one another.

Maybe when all completions fit to the buffer, so scrolling is not applicable,
the second TAB could switch to the completions buffer?  Or when this might
be unexpected for users, it could be provided as an optional value.

RE: [External] : Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Drew Adams]

I hesitate to post this, in particular because
I have _not_ at all been following this thread.

[I also don't yet have access to a Emacs 28
pretest MS Windows binary, so I'm pretty far
removed from any development these days.  I
fully expect (but I hope not) that when I get
Emacs 28 the behavior of *Completions* and
the minibuffer, especially for a standalone
minibuffer frame, will be completely broken
for my use.  (That's already the case for
Emacs 27 - but I retain hope.)]
___


Just in case it helps...here are some comments
(suggestions) about key bindings, based on what
I defined for Icicles.

1. TAB should be for completing.  In particular,
   it should not be for scrolling *Completions*.

   (Vanilla Emacs long ago made it do both of
   those.  That was long before Emacs supported
   any kind of cycling.)

2. C-v and M-v in the minibuffer should scroll
   *Completions*.  Users know these keys, and
   they're a natural choice.  In *Completions*,
   a mouse wheel should scroll.

   Scrolling of *Completions* should wrap around.

   (In *Completions*, C-v and M-v also scroll,
   but they don't wrap around.  The global C-v
   and M-v bindings apply there.)

3. TAB can also be for cycling.  In Icicles, 2nd
   and subsequent TABs cycle.  TAB should cycle
   whether you're in minibuffer or *Completions*.

   Preferably, users should also have other keys,
   by default, that only cycle (do not complete).

4. Cycling should wrap around, by default.  But
   this should be controllable by a user option.

5. It should be easy to move between minibuffer
   and *Completions*.  A single key can do this.
   Icicles uses C-insert, by default.  

   When moving to *Completions*, C-insert moves
   to the current completion candidate there.
   When moving to the minibuffer, it inserts the
   candidate at point in *Completions* into the
   minibuffer, at point.

6. All such key bindings should only be defaults.
   Users should be able to change them easily,
   without needing to know anything about keymaps
   used for the minibuffer and *Completions*.

In Icicles, in practice you seldom move to
*Completions* (i.e., C-insert or mouse-1).  You
can do so at any time, but you never need to do
so.  Some users might sometimes like to do some
things there with the mouse (a direct-access
pointing device), but though you can, you never
need to.
___

HTH.
My advice is to keep it simple, and to not use a
key such as TAB for both cycling and scrolling.

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Theodor Thornhill]

Daniel Martín <mardani29@yahoo.es> writes:

> I don't think I like this change to the minibuffer defaults.  It breaks
> muscle memory and IMO is more incovenient when you need to show the
> completion list many times.
>

Sorry for my ignorance, (and partly offtopic question) but why would you
want to show the completion list many times?  Isn't that very slow when
moving around files?

> One typical workflow I have is doing something like C-x C-f TAB TAB to
> see the list of completions and then continue typing to narrow the list
> of completions.  After this commit, you need to switch back to the
> minibuffer to continue completing things, which is annoying.
>

This feels very inefficient.  Wouldn't it be faster just having the
completion candidates open, then narrowing?  I have always found the
default emacs completion system very arcane, but I might be missing
something.

Theo

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Daniel Martín]

Theodor Thornhill <theo@thornhill.no> writes:

> Daniel Martín <mardani29@yahoo.es> writes:
>
>> I don't think I like this change to the minibuffer defaults.  It breaks
>> muscle memory and IMO is more incovenient when you need to show the
>> completion list many times.
>>
>
> Sorry for my ignorance, (and partly offtopic question) but why would you
> want to show the completion list many times?  Isn't that very slow when
> moving around files?
>
>> One typical workflow I have is doing something like C-x C-f TAB TAB to
>> see the list of completions and then continue typing to narrow the list
>> of completions.  After this commit, you need to switch back to the
>> minibuffer to continue completing things, which is annoying.
>>
>
> This feels very inefficient.  Wouldn't it be faster just having the
> completion candidates open, then narrowing?  I have always found the
> default emacs completion system very arcane, but I might be missing
> something.

Many people prefer to use a selection workflow for the minibuffer, yes,
the popularity of packages like ivy, selectrum, ido, icicles, helm,
etc. speak for itself.  But on master the implemented solution was more
or less an intermediate one where the completion list was not shown
automatically and the results were not filtered "on the fly".  IMO, that
kind of intermediate solution doesn't help much to attract people used
to that kind of workflow from other applications/Emacs packages, and
only annoy people used to vanilla completion.

Another experiment that might be more successful is to enable an ELPA
package like mct[1] by default, and offer a single option to revert to
the default minibuffer behavior, for people used to vanilla completion.

[1]: https://elpa.gnu.org/packages/mct.html

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Theodor Thornhill]

Daniel Martín <mardani29@yahoo.es> writes:

>
> Many people prefer to use a selection workflow for the minibuffer, yes,
> the popularity of packages like ivy, selectrum, ido, icicles, helm,
> etc. speak for itself.  But on master the implemented solution was more
> or less an intermediate one where the completion list was not shown
> automatically and the results were not filtered "on the fly".  IMO, that
> kind of intermediate solution doesn't help much to attract people used
> to that kind of workflow from other applications/Emacs packages, and
> only annoy people used to vanilla completion.
>

Right, I see your point.

> Another experiment that might be more successful is to enable an ELPA
> package like mct[1] by default, and offer a single option to revert to
> the default minibuffer behavior, for people used to vanilla completion.
>

I actually use mct, and have for a while.  I like that it is not as
intrusive as the other projects.

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Philip Kaludercic]

Daniel Martín <mardani29@yahoo.es> writes:

> But on master the implemented solution was more
> or less an intermediate one where the completion list was not shown
> automatically and the results were not filtered "on the fly".  IMO, that
> kind of intermediate solution doesn't help much to attract people used
> to that kind of workflow from other applications/Emacs packages, and
> only annoy people used to vanilla completion.

The motivation was not to attract people from either side, but to fix an
annoyance I had when a string couldn't be expanded, but was not unique.

With completion-auto-select disabled you either have to edit the
minibuffer yourself, or switch to the *Completions* buffer using the
(imo inconvenient) M-v key.  The idea is that completion-auto-select and
completion-wrap-movement provide is a method to reduce all completion
operations to a single key (tab), without having to change modifiers.

(Looking back, I understand the change was too radical for the master
branch, though I still think that it is a considerable improvement, and
provides a basis upon which incremental narrowing could be implemented,
without falling for a lot of the issues that other popular "frameworks"
have)

> Another experiment that might be more successful is to enable an ELPA
> package like mct[1] by default, and offer a single option to revert to
> the default minibuffer behavior, for people used to vanilla completion.

I don't see how this is any better or worse than enabling
completion-auto-select by default.

-- 
	Philip Kaludercic

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Juri Linkov]

> The idea is that completion-auto-select and completion-wrap-movement
> provide is a method to reduce all completion operations to a single
> key (tab), without having to change modifiers.

Every time I customize completion options, first I change
completion-auto-help and completion-auto-select, then spend
time trying to find the third related variable under the same prefix.
Does this suggest it would be better to share the same prefix,
i.e. to name the third variable completion-auto-wrap?

Re: master f6967d2 1/3: Allow for the completion buffer to be automatically selected

[Philip Kaludercic]

Juri Linkov <juri@linkov.net> writes:

>> The idea is that completion-auto-select and completion-wrap-movement
>> provide is a method to reduce all completion operations to a single
>> key (tab), without having to change modifiers.
>
> Every time I customize completion options, first I change
> completion-auto-help and completion-auto-select, then spend
> time trying to find the third related variable under the same prefix.
> Does this suggest it would be better to share the same prefix,
> i.e. to name the third variable completion-auto-wrap?

I think that would make sense, or at least I would never object to
consistency.