Re: how to determine the current table (really) being used for minibuffer completion?

[Stefan Monnier]

> How I used to do what? There is no concrete example.

Please, then say clearly that your problem is hypothetical, that will
help us answer your questions more directly.

> So you've confirmed what I said: one cannot know. The request is to be
> able to know.  IOW, to be able to have some finer-grain knowledge of
> the completion state.

Define what you mean by "have some finer-grain knownledge of the
completion state".  I think this request is like a solution waiting for
a problem.  So once we find a concrete problem, we'll know better how to
solve it.  But in the abstract like that, it's really unclear what kind
of solution would be needed/possible.

> The point is that now there can be radically different kinds of
> completion that are used, all within the same
> `read-file-name-internal' (for example).

That has always been a possibility.  Maybe this is used a bit more now, tho.

> I would like to be able to know which phase of that completion
> processing I'm in,

When?  Who's "I"?
Do you mean, given the position of point which kind of completion will
take place?  The closest right now is to use completion-boundaries,
which won't tell you what completion table will be used, but at least
it'll tell you which part of the buffer around point will be "affected".

> I would like, for instance (just an example), to be able to distinguish
> file-name completion per se from env var completion, both of which are now
> included as part of "file-name" completion in a larger sense.

completion-boundaries can help you do that.  But again, without knowing to
what purpose you want to distinguish those two cases, it's hard to know
what would really be a good answer.

> Only in a general way. `foo' or `read-file-name-internal' is the
> overall completion function, to be sure, but the completion processing
> is now decomposed into several distinct cases (as you say, next). For
> `read-file-name-internal', these are
> `completion--embedded-envvar-table' and `completion--file-name-table'.
> `read-file-name-internal' doesn't really call directly for any
> low-level completion act (e.g. `try-completion') anymore.

read-file-name-internal is pretty much the only one that I changed in
this way, BTW.  It can now complete either files or env-vars.  In the
future it will probably also be able to complete ~<user> user names.

>> > So not only is checking `minibuffer-completion-table' against
>> > `read-file-name-internal' useless,
>> Comparing functions is usually a bad idea.  Sometimes, 
>> there's not much else we can do, admittedly.
> The Emacs code still compares `minibuffer-completion-table' against
> `read-file-name-internal', in particular, in many locations.

Not sure how you define "many", but my grep found only one place where
we do it: in complete.el which could advise read-file-name-internal
instead (but since it's on the way to obsolescence, it doesn't matter
much either way).

> I assume that all of those occurrences still work as intended. ;-)

Why wouldn't they? ;-)
BTW, all the uses I've ever found (other than complete.el's) were
changed to use minibuffer-completing-file-name or to work in all cases.

> It is a general request.

We have plenty of real concrete problems to address and improvements to
implement, so yours will inevitably end up at the very bottom of
the lot.

> I obviously don't have a great feel for how to best implement what I'm
> asking for or how best to use it.

Come back when you do know.


        Stefan