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

[Ergus <spacibba@aol.com>]

On Wed, Apr 06, 2022 at 10:35:36AM +0300, Juri Linkov wrote:
>> Thanks for this... Sadly after trying it for a while I find it very
>> uncomfortable. :( maybe we can do something to improve it please??
>
>This is not surprising.  This explains why we still had no such feature
>for a long time.  It's because there are too many different expectations
>how it should work.  But maybe it would be possible to find a set of
>customizable options that will cover most use cases.  As least we could try.
>
>> 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.

>> Alternatively (IMHO much better one):
>>
>> Maybe you could consider to insert the candidate, but keep the cursor in
>> the same place and add a shadowed suffix after the cursor in the
>> minibuffer.  So M-<arrow> navigates, and inserts suffix but if the user
>> types a letter the suffix disappears and the letter is inserted in the
>> right place. In contrast if the user press RET, as the candidate is
>> already inserted the current behavior is unchanged.
>
>Isn't this behavior too confusing?  When the suffix is shadowed,
>do you think the user will have the clear idea what will happen
>after typing RET?
I took the idea basically from some configs around for fish and zsh..

>How will it indicate that typing
>a self-inserting character will delete the suffix?
That's just an option. We could also enable a C-g like in default zsh:

som<tab> -> some
some<tab> -> Completion list with: `someone, something, sometime`.

There is a custom to auto-select the first candidate inmediately or
require a second tab... (similar to our completion auto-select
values...)

Whenever a candidate is selected, the prompt is completed (similar to
your code as now) but the list can be explored with the normal arrows
while it is visible.

The main difference is that the user may cancel at any time with C-g, so
the candidates list is automatically hidden BUT the prompt goes back to
`some` (not cleared as now); so the user can continue typing and <tab>
again.

If the user inserts a letter at any moment with the completion list
visible and a candidate selected, then the candidate is keep and the
letter inserted after a space.

`some<tab>o` will produce `someone  o`
`some<tab><C-g>o will produce `someo`

In any case you will see the full `someone` after the <tab> and the
whole list, so RET will finish the completion and a second RET will use
it...

We can simplify part of this behavior because the emacs minibuffer does
not use multicommands or multientries on a command like: command arg1
arg2 and so on... So RET could maybe complete and use as now...

But OTOH I will strongly recommend the C-g and arrow navigation
behavior... That could be maybe implemented with a set-transient-map...

> Maybe better to activate the region over the suffix?
>Then it will follow rules of delete-selection where
>a self-inserting character is expected to remove the suffix region.
>
>> 2) The M-<up>/M-<down> is not intuitive when completions are not in
>> one-column format,
>
>M-<up>/M-<down> could be rebound to call next-line in the
>completions buffer.
>
>> and the M-<left>/M-<right> cannot be used because
>> they are already taken.. Do we have any other alternative?
>
>Indeed, horizontal navigation is a problem since M-<left>/M-<right>
>can't be used by default, only after enabling a new option.
>
set-transient-map??

>> I think there is a problem any way because 2d navigation with this
>> is impossible...
>
>Why 2d navigation is impossible?  It's possible in the completions
>buffer where <right> is next-completion, and <down> is next-line.
>
Yes, but from minibuffer it will collide with one way or the other
right?

>> 3) I think that the bindings in the minibuffer must be enabled in the
>> completions buffer as well, otherwise it becomes unconfortable;
>> specially with completion-auto-select.
>
>Agreed, M-<up>/M-<down> can be bound in the completions buffer.
>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.

>>>I noticed that your patch broke some corner cases:
>>>when using minibuffer completion navigation commands,
>>>it fails to go to the previous completion at the top.
>>>But since this is now in master, you can see it yourself.
>>
>> My patch can only affect the TAB and backtab commands (look at the if
>> condition)... So I don't see how it could affect you commands ;(... I
>> will give it a look tomorrow...
>
>Sorry, now I can't reproduce the previous problem, it seems to work fine,
>except the problem reported in bug#54374.

Best,
Ergus