Re: [PATCH] Support "\n" in icomplete-separator

[Ergus <spacibba@aol.com>]

On Fri, Nov 13, 2020 at 10:18:58PM +0200, Andrii Kolomoiets wrote:
>Eli Zaretskii <eliz@gnu.org> writes:
>
>> We are not talking about the default completion in this thread, we are
>> talking about icomplete-mode and its ilk.  They work differently, and
>> in particular do show completion candidates automatically in the
>> minibuffer.
>>
>>> > Without seeing the possible answers, what are your chances of knowing
>>> > what to type?
>>>
>>> Chances are pretty good: I'll press TAB to see the *Completions* buffer.
>>
>> Pressing TAB seems to be against the philosophy of icomplete, ivy, and
>> similar features, at least AFAIU: they display the candidates without
>> any prior request by the user.
>
>Among icomplete, ivy and ido modes only ivy is overriding TAB key.  With
>icomplete and ido the overlay text is not the _only_ way of knowing what
>inputs are acceptable.  Seems like they has nothing against using TAB to
>complete text.
>
Ivy has ivy-partial-or-done bind to tab by default. Which completes
common part or open on single alternative with the default action
(find-file for file; dired for directories...).

But it is possible to bind tab to ivy-partial in ivy-minibuffer-map
instead. Then you have only completion on tab which is probably more
familiar for shell users, and a more predictable behavior. Actually the
most opposed completion system to use tabs is helm not ivy ;p