Re: [PATCH] Re: Other details about completion.

[Ergus <spacibba@aol.com>]

On Wed, Apr 06, 2022 at 07:48:40PM +0300, Juri Linkov wrote:
>>>> 1) I think it is more intuitive to invert and use the M-S-<arrow>
>>>> minibuffer-choose-** and M-<arrow> for
>>>> minibuffer-{previous|next}-completion for not insert commands...
>>>
>>> Easier to type M-<arrow> were intended as the primary way to use this feature.
>> I know, but such primary behavior is too intrusive IMO.
>>
>>> Whereas more hard to type M-S-<arrow>/M-RET as a rarely used alternative.
>> Mi proposal (the suffix one) is basically to avoid the need of M-RET.
>
>So your proposal is something in between.  Then maybe instead of two sets
>of commands (that either insert the current completion or not) we could have
>one set of commands bound to M-<up>/M-<down>, and a customizable option with
>three values: insert, don't insert, use transient suffix.
>
I would prefer something simpler even if we need to sacrifice some
functionality or customization...

>> I took the idea basically from some configs around for fish and zsh..
>> ...
>> But OTOH I will strongly recommend the C-g and arrow navigation
>> behavior... That could be maybe implemented with a set-transient-map...
>
>What is also interesting to note is that even every web browser
>uses own completion logic:
>
>1. in Firefox: the suffix of the first completion is inserted to the
>   address bar as the selected region, but <up>/<down> inserts
>   the completion without selecting its suffix, like M-<up>/M-<down>
>   currently does in Emacs.  One ESC closes the completions window,
>   another ESC clears the address bar.
>
>2. in Chromium: <up>/<down> inserts the completion without any selection,
>   like M-<up>/M-<down> currently does in Emacs.  One ESC clears the
>   inserted string, another ESC closes the completions window and clears
>   the address bar.
>
Yes but there are three key differences there: 

1) browsers show the completion list immediately (like icomplete and
it's family), so they don't require a tab to show the completion list or
any binding to jump to/exit the completions list either.

2) the browser completions are shown vertically only, so no horizontal
navigation is needed and not modifiers to the keys are needed either as
there is not any collision of bindings. With the plus that the user can
go to the initial prompt (without completions) just by moving to the
first candidate (up arrow)... so no applicable to us either.

3) The search they perform is on the history, so when the candidate is
unique it is inserted and selected, so easier to erase the suffix if
needed with backspace or insert at the end (right arrow).

In either case 1) there is not a two step to insert+execute 2) there are
not special bindings 3) There is an intuitive way to keep the
completions like it started (remove the suffix) either hiding or keeping
the completion window.

Maybe we must look more at the fish/zsh behaviors than browsers, because
browsers are too far from our infrastructure...

BTW: do we have any sort of history search based on the inserted text
like bash history-search-backward??

>>> But what about M-<left>/M-<right> for not one-column format?
>>
>> This just confirms me that the initial approach implemented with a minor
>> mode (or using a set-transient-map) may be a solution.
>
>We started with non-intrusive keybindings.  But indeed, more intrusive keys
>should be enabled only depending on a new customizable option.
>

>Here is the next patch that does this and allows using all arrow keys
>only when the completions window is visible:
>
I will try this and comment, thanks!!

Best