Re: Question about completion behavior

[Ergus <spacibba@aol.com>]

Hi juri

On March 10, 2022 7:50:43 PM GMT+01:00, Juri Linkov <juri@linkov.net> wrote:
>> I just added a new branch feature/completions-customs.
>
>Thank you.  I hope these small steps that add new options
>will gradually place the default completion UI on a par with
>modern completion packages.
>
>One question - please explain what values of completion-auto-help
>nil/t/lazy/visible/always now do in these cases that you posted earlier:
>
>  1. no unique        (shows or update completions)
>  2. unique common    (complete-common and UPDATE completions)

The new values only change this case. Always shows or update  completions and visible only updates if they are already visible. The other previous values just hide completions.

>  3. unique candidate (complete and hides completion)
>  4. unique common but completion is a valid entry (complete-common and hides completion)
>
>> The changes there are minimal and finished in my opinion.  Whenever any
>> of the maintainers decide they can correct, fix, or merge into
>> master. (there is a small issue with the reference in the manual, so
>> please fix it, but I don't have any more time)
>
>I fixed these and some other issues in the branch.
>

Thanks :)

>> The changes include the max-height for completion window, a
>> completions-highlight-mode and the new values for completion-auto-help.
>
>Why not highlight the completions by default?  Unlike other changes,
>highlighting doesn't change the previous behavior.
>

You know...

>> I didn't include the zcomplete-mode because I am not sure how to name it
>> and didn't receive any feedback except from Juri.  In total it is 53
>> lines and provides an interaction similar to zsh (as explained before)
>> which may be very suitable for new users.
>
>I'm still unsure about this mode.  It's unclear what is the answer
>to the main question: should it select the completion buffer or not?
>

This one only works with the buffer selected. I minimized the hacks as much as possible. The only change is that when pressing a letter key or when attempting to edit the read only completions buffer, it will try to go to the mini buffer immediately and execute the key command there. Just give it a luck.

>I'll soon post a patch to allows navigation in the completion buffer
>without selecting it, i.e. from the minibuffer. 

We already tried that, but you are a much better lisper... Let's hope ;)

 This will handle
>the problem of self-inserting keys that will continue working
>in the minibuffer.  When this will prove to be insufficient,
>then we could add new mode to auto-select the completions buffer.
>But then why don't just use the recently added completion-auto-select?
>

The zcomplete-mode is intended to be used with completion-auto-select for a better experience indeed. As I said what it does is just to skip the completions when any letter, DEL or edit attempt is done in the Completions. Then it tries to execute the command directly in the mini-buffer before signaling an error... Basically it saves to explicitly jump to the mini-buffer before inserting another letter or delete one. 


>> Apart from that I am wondering if it makes sense to add an option to
>> propertise/configure the Initial line in the Completions buffer (there
>> is one to remove the help, but not the other)
>
>Do you mean completion-show-help whose nil doesn't remove
>text "Possible completions are:"?
>
Yep

>> (for example to remove it or add properties like intangible, a face etc)
>> could we also add a sort of counter there to indicate the total number
>> of candidates?
>
>Good idea.
>
Best,
Ergus
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.