Re: Questions about the `completing-read-function' interface

[Oleh Krehel]

Drew Adams <address@hidden> writes:

>> I'd like to know, if a function calls `completing-read', should the
>> members of DEF be inside COLLECTION? I haven't found info on this in the
>> doc, and `completing-read-default' doesn't seem to handle DEF not being
>> in COLLECTION.
>
> Completion can be lax: user input need not match any of the completion
> candidates (null REQUIRE-MATCH argument).  Whether DEF is one of the
> candidates is generally irrelevant in this case.
>
> And COLLECTION can be a function, returning any string it wants.
> It can even return a value that cannot be known at coding time.
> What applies to user input pretty much applies to what DEF can be.
>
> So in the general case no, DEF need not be one of the candidates
> (or a subset of them, if it is a list).
>
> The calling function (context) knows whether DEF should be one of
> the candidates.  And only the calling function.

That's kind of what I'm saying. The calling function knows all the
candidates, excepting the REQUIRE-MATCH case, yet it still sends the
candidates in two batches: COLLECTION and DEF.

>> But, for instance, `magit-completing-read' (and some other functions) do
>> make that assumption.
>
> Then they need to prepare for that assumption.  They have a particular
> requirement for the relation between COLLECTION and DEF, and they need
> to manage that use case.
>
>> And `helm-mode' has code to deal with that.  I'm thinking of adding a
>> similar work-around to `ivy-mode' as well, but maybe it would be better
>> if it was somehow mandated that DEF should be in COLLECTION.  Because,
>> theoretically, DEF can be a list, and it would be inefficient for the
>> completion engine to go through the whole collection just to make sure
>> that DEF isn't there, and then add it there.
>
> Please don't.  Any given *caller* of `completing-read' that needs to
> rely on DEF being a member (or a subset) of COLLECTION can just DTRT.

I don't get this statement.

>> So that each time `set-completing-read-function' is called, the current
>> minor mode is properly shut down in the callback.  We could keep the
>> current interface for single-use completion through a let binding. But
>> all the minor modes mentioned would use `set-completing-read-function'.
>
> Again, please do not try to hard-wire any such behavior.  Leave it
> up to the various libraries or other callers of `completing-read' to
> handle any such possible interactions, if they see the need.

I said nothing of hard-wiring. I just described an interface to which
diverse packages can subscribe in order to get a benefit.
If they don't want to do it, it's it's only an opportunity lost for them.

I've seen the more generic packages playing around so many things that
could be happening on the system. Could the system not give some
facilities to manage the contested resources?

Oleh