Re: master a1f5b8cf863: Don't immediately show *Completions* for icomplete-in-buffer

Sean Whitton <[email protected]> writes:

> Eshel Yaron [03/Aug  2:05pm +02] wrote:
>> Sean Whitton <[email protected]> writes:
>>
>>> branch: master
>>> commit a1f5b8cf863778d867e6ef318cc493cae4ca76f4
>>> Author: Sean Whitton <[email protected]>
>>> Commit: Sean Whitton <[email protected]>
>>>
>>>     Don't immediately show *Completions* for icomplete-in-buffer
>>>
>>>     * lisp/minibuffer.el (completion--icomplete-in-buffer-p):
>>>     New function.
>>>     (completion--do-completion, completion--in-region-1):
>>>     Use it (bug#81537).
>>
>> Hmm...
>>
>>> @@ -1686,6 +1689,7 @@ when the buffer's text is already an exact match."
>>>                (minibuffer-force-complete beg end))
>>>               ((or completed only-changed-boundaries)
>>>                (cond
>>> +               ((completion--icomplete-in-buffer-p)) ; Bug#81537.
>>>                 ((pcase completion-auto-help
>>>                    ('visible (minibuffer--completions-visible))
>>>                    ('always t))
>>
>> Icomplete is "one of many" completion frontends, so it seems odd
>> for this low-level completion infrastructure to hardcode such
>> Icomplete-specific checks.  Am I missing something?
>
> Please go look at the bug, I CC'd you.

I did.  IIUC, you explained why it's non-trivial to have Icomplete use
the existing API by implementing a proper completion-in-region-function.
But that doesn't by itself justify hardcoding Icomplete-specific logic
in the common completion infrastructure.  E.g. you could instead extend
the infrastructure with some hook that Icomplete would use to inhibit
showing the *Completions* buffer.


Eshel