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

[Drew Adams]

> > 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.

DEF entries are not completion candidates.  The completion candidates
are in one batch: COLLECTION.  Suggested defaults are in another batch:
DEF.  The two batches serve two different purposes.

In some particular use case there might be a particular relation
between the two that must hold, but not in general.  In such a use
case, the code need only enforce whatever relation is needed: call
`completing-read' with appropriate COLLECTION and DEF values.

> > 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.

What part of it do you not get?  Instead of trying to impose a relation
between COLLECTION and DEF for all purposes, leave it up to the caller
to call the function with appropriate COLLECTION and DEF arguments.

If, for a given calling context, DEF should be a member (or a subset)
of COLLECTION, then that call should make sure that it is.  That's all.

> 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.

OK, my misunderstanding then.  So you want to add something optional
for code to be able to use, rather than to change `completing-read'
etc.  (What is that something?)

I have no opinion on that, a priori.  I haven't seen the suggested
feature (e.g. code or spec), so it's hard to guess what you are
proposing.  I don't see the description of the interface to which
diverse packages would subscribe.  Maybe you could specify it more?

And I would still suggest that you might want to point to the real
problem you want to solve, before proposing solutions to it.  I say
that because I think that might help you get your point/question
across.  But that's just a suggestion, in case it helps - if not,
please ignore.

> 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?

Sorry, but "playing around so many things", and "manage the contested
resources", are too vague for me to grok what the problem is that
you are looking at solving.  Maybe others can help - I haven't seen
the problem specified clearly yet.  It may be clear to you (and maybe
to other readers), but it is not clear to me.

If my reply isn't helping you, please ignore.  Hopefully someone
else will respond with something that helps more.  FWIW, I agree
with what Stefan wrote (and I think it agrees with what I wrote).