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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Hypothetical example that might make the request clearer:
> (completion-all-completions
>  STRING 'read-file-name-internal nil (length STRING))

> The result returned might be a list of relative file names, or it
> might be a list of env vars.  A result such as ("CATACOMBS"
> "CATAPHILE" "CATASTROPHE" . 4) could be either.

> I would like (via Lisp) to know which kind of completion was in fact used
> successfully: file-name completion per se or env var completion.

In which form?  Do you want a symbol like `file' vs `envvar', or do you
want a completion-table (which can then be a has-table, an obarray, an
alist, a list, a symbol-function, or a lambda expression)?
The second might be doable in many cases (actually more so in Emacs-23
than in Emacs-22, since most functional completion tables now get
composed using primitives like complete-with-action or
completion-table-*, so we could add a 5th method (additionally to the
original 3, try-completions, all-completions, and test-completion, plus
the new completion-boundaries) a bit more easily), but I'm not sure it
would be easy to use.

> I don't want to analyze STRING (e.g. check for `$') to figure out what
> might be the case. (completion-boundaries STRING
> 'read-file-name-internal nil "") just gives something like (0 . 0),
> indicating the whole STRING.

(completion-boundaries "to/to" 'read-file-name-internal nil "") returns
(3 . 0),
(completion-boundaries "to/$to" 'read-file-name-internal nil "") returns
(4 . 0) and 
(completion-boundaries "to/${to" 'read-file-name-internal nil "") returns
(5 . 0), so by looking at (aref STR (1- (car (completion-boundaries STR ...))))
you can "easily" tell which case is currently relevant.  But of course,
that requires knowledge of the behavior of read-file-name-internal.

> Emacs should be able to tell me directly what the last completion
> table/function used was.  It should be easy to make this info
> available somehow, e.g. in a global variable.

It might be easy in 99% of the cases, depending on exactly what
you want.  In my experience, providing this info before seeing actual
uses for it is a perfect recipe for "features" which are unusable in
practice because they don't quite give the info we need.  So I'm
definitely not opposed to providing this info, but I'll wait for
a practical use for it, so I'll be in a better position to provide the
right info.

> Similarly, for multiple, successive completion types using
> `completion-styles', I would like to know which type (style) was in
> fact successful.

Same answer here.  Actually, this one is even a bit worse, because
I strongly suspect that if some code needs this info, it's probably not
doing the right thing.  But in any case, we'll see it when we get there.


        Stefan