bug#81537: 32.0.50; Fixing icomplete-in-buffer requiring users to advice-add

Eshel Yaron [06/Aug  7:04am +02] wrote:
> Hard to say: you didn't quite tell what it is that you want, although
> I understand it's trying to see if there's just one possible completion
> under some conditions.

If there is just one possible completion left after the command has been
run, then my code does (completion-in-region-mode -1) to free the user
from having to type C-g.

> But more importantly, whatever it is exactly, there's nothing wrong with
> relying on implementation details in you private config; it just comes
> with the understanding that you may need to adapt when the
> implementation changes.  Right?

The approach you describe is perfectly reasonable, yeah.  I prefer only
to use public APIs in my private config, though.

But in any case it's not your job to work this out for me if there isn't
an obvious answer, so let's leave this aside :)

>> Not yet.
>
> Alright.
> So I'd say it currently seems that the completion-in-region-function API
> can/should be enough for icomplete-in-buffer.

To be clear, I haven't given your patch any live testing, because I
don't think changes that invasive can be justified.

> To be clear, I don't advocate this approach (yet): it only treats the
> most painful symptom of the current code (Icomplete-specific logic in
> the completion infrastructure), while a proper remedy would be using the
> pre-existing API with no changes in minibuffer.el.
> Also, I don't know what you'd like FOO to be, or if/how the hook should
> be documented...  If this is the approach you prefer, I'll have to leave
> these final details to you.

As I think that Icomplete logic in minibuffer.el is acceptable in this
case, I'm not going to work on this directly, but very happy to review
and discuss.  If you're not going to work on this imminently, though,
let's close the bug again.

-- 
Sean Whitton