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

[Drew Adams]

> > Since the Emacs 23 changes to minibuffer completion, there is little
> > doc, and there are few doc strings.  It's not always obvious how to
> > determine the current state of evaluation.
> 
> I do not know what you mean.  Please give a concrete example 
> showing how you used to do it in Emacs-22.

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

The point is that it is impossible (difficult?) to know which kind of completion
function is currently being attempted, or which type completed successfully.
Previously, comparing `minibuffer-completion-table' against a given function
gave some idea.

And surely you know what I mean wrt doc and doc strings. ;-)

> > In particular, when completion tables are tried in sequence 
> > under the covers, how is it possible to know at some point
> > which table is actually being tried?
> 
> If you mean uses of completion-table-in-turn: you can't and neither
> could you in Emacs-22; and this is not strictly a change in the
> minibuffer completion but in the implementation of some completion
> tables (yes, I made changes to both because the minibuffer completion
> changes needed some adjustments in the competion tables to 
> work better, and because I wanted to rewrite in Lisp the C implementation 
> of some of the completion tables, and because I wanted to give the
> code more structure).

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.

> > For example, how to know, during file-name completion, 
> > whether the table currently being tried is
> > `(completion--make-envvar-table)' or
> > `(completion--file-name-table)'?
> 
> You can't (and neither could you before, AFAICT).
> Could you give us some context to beter understand when you need it?

No. I didn't say I needed it in some concrete way.

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). I would
like to be able to know which phase of that completion processing I'm in, or
which phase succeeded if completion was successful.

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.

> > We have the global variable `minibuffer-completion-table', 
> > but that is apparently useless in this context. That var might
> > be bound to some function `foo', but that doesn't mean that
> > it is `foo' that is actually trying to perform completion
> > at the moment, since completion now can involve several
> > completion attempts using different tables
> > (e.g. functions), successively.
> 
> It does mean that `foo' is the table that does the completion.

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.

> That table may be decomposed into several distinct cases, but that's
> nothing new.  The same was already the case when completing for
> Info-goto-node, for example.

Well, yes and no. Yes, this is a quantitative expansion of the kind of thing
that has already been done in `Info-read-node-name' (but it did only one kind of
completion or another, not a sequence of different kinds of completions) - but
it pretty much becomes a qualitative change because it is so pervasive now.

> > 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. I assume that all
of those occurrences still work as intended. ;-)

But I might want to do something different, depending on whether, say, an env
var is being completed or a file name (properly speaking) is being completed at
the moment (or was completed successfully). Maybe just display a msg; it really
doesn't matter what. This doesn't depend on any particular concrete case (need).
It is a general request.

> > How about (at least) recording in some global var the table that is
> > currently being used/tried?
> 
> It's not even clear what that would mean.

Maybe have a global variable `current-completion-table', analogous to
`minibuffer-completion-table. Maybe `complete-with-action' could set it to the
table it is currently using. That might make it possible to know which type of
completion was used successfully.

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

It just seems that we should be able to have some way to test what's going on -
what kind of completion is being attempted - and what kind of completion was
successful. The act of completion is now a multi-act epic play. It's good to be
able to know which act is in progress or what the outcome of the previous act
was. That's all.