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

["Drew Adams" <drew.adams@oracle.com>]

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

As you recognize, it is better to test a known symbol (e.g. `envvar') than a
completion table (function or list or hash table or obarray...).

What I suggest is this:

Use a data structure (an alist), to have a standard list of symbols (the keys of
the alist) that can be tested.

@ In the case of completion styles (determining which style performed the
completion), just reuse `completion-styles-alist': be able to test the alist key
- `basic', `emacs22', `emacs21', or `partial-completion'. (But using whatever
real alist entries are in `completion-styles-alist' at the time of testing.)
This will provide a knowable and unambiguous set of symbols to test.

@ In the case of env-var and file-name completion: Do the same thing. Implement
something similar to `completion-styles-alist'. It would be good to use an alist
here anyway, for flexibility of use and ease of maintenance.

After successful completion, set a global variable to the symbol that represents
the completion style.

This is simply additional information to be, in effect, returned by the
completion function. We already return the set of completions, and you've hacked
that list to also carry the base size in its last cdr. This third piece of info
about the completion state can be returned in a global variable. (It can be at
least as important as the base size, IMO.)

Your code comments acknowledge the hackiness of how base-size is returned, and
they point to possibly also returning a `completion-extra-size' and
`completion-no-auto-exit' in the future. The point is that completion is a
complex process, and it can return more useful info than simply the list of
completions.

--

Also, it is somewhat inconvenient to have `completion-styles-alist' as a defvar,
not a defcustom. It is the real fulcrum for all of the code. It is baked once by
Emacs development, and then it is used as the basis for the rest. User
customization of `completion-styles' is limited to choosing among predefined
styles.

It would be better to have a single option that lets users both (a) choose the
styles to use and (b) define new styles (their names and their defining
completion functions). IOW, combine `completion-styles-alist' with
`completion-styles' as a single option that users can customize.

That way, the code would still automatically adjust to the possible set of
completion styles, but those styles would not be limited to choices from a
predefined list. Users could still just as easily add or remove predefined
styles, but they could also more easily add their own.

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

See above.