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

[Ergus <spacibba@aol.com>]

On Sat, Apr 02, 2022 at 09:09:29PM +0300, Juri Linkov wrote:
>> Hi again...
>>
>> Here I attached a small patch that makes 3 small changes:
>>
>> 1) Remove the trailing newline in completions one-column
>> 2) Use another condition in next-completion to jump to minibuffer.
>>
>> Normally next-completion with tabs at the end of the buffer needs an
>> extra tab because it goes to the end of the last completion before
>> jumping to the minibuffer or wrap.. That extra tab is because the
>> condition to jump or wrap was eobp/bobp assuming that there is not text
>> unproppertized after the last candidate.
>>
>> 3) Remove a comment in switch-to-completions. That comment suggested that
>> the next-completion action must be called inside
>> minibuffer-completion-help but IMO that is not totally correct when
>> completion-auto-select has some of the new values.
>>
>> Please, if anyone could review,correct and push I would be very
>> grateful.
>
>Do you mean that you fixed the problem reported in bug#54374?
I have no idea about bug#54374 I will check when I have some time.

>I hope Philip could help to verify that your patch works
>smoothly with the new features completion-auto-select
>and completion-wrap-movement.
>
Actually I use both... completion-auto-select and
completion-wrap-movement

==========================================

What is annoying for me is that this behavior is limited to TAB and
backtab... I would like to have this same behavior for any interactive
call to next/previous-completion (for example when using arrows or
n/p). I tried this:

In simple.el I changed previous-completion for this:

(defun previous-completion (n)
   "Move to the previous item in the completion list.
With prefix argument N, move back N items (negative N means move
forward)."
   (interactive "p")
   (funcall-interactively next-completion (- n)))

And then in next-completion I changed:

(member (this-command-keys) '("\t" [backtab]))

for this:

(called-interactively-p 'any)

But the second one always return false when using
previous-completion... like ignoring the funcall-interactively... Is
this a issue or intended??

Alternatively I could use:

(memq this-command '(next-completion previous-completion))

But that may be like hiding the called-interactively-p issue under the
carpet if it is an issue.

Best,
Ergus.