bug#10721: 24.0.93; M-TAB for :type (file :must-match t) in Customize

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

> But if the recipe involves face names, the bug title is 
> misleading.  It appears that general inline completion in
> fields is broken

> nothing to do with (file :must-match t) types.

Correct - it seems that all such completion fields are broken (or at least all
that I have tried).  The bug report mentioned `(file :must-match t)' because
that is where I first noticed this regression.

Here's another recipe, this time with `(file :must-match t)'.  This provides a
little more info that might help: For file names, it seems that
`default-directory' is used, even if the input file name starts with "~/".

(defcustom foobar "~/.emacs"
  ""
  :type  '(file :must-match t)         
  :group 'convenience)

Note: "~/" is "c:/" for me.  Change the default value of the option to a
corresponding file on your system, and change the rest of the recipe
accordingly.

`M-x customize-option foobar'

Put point after the `e' in "~/.emacs", and hit C-k, so the field text is "~/.e"
and point is after the `e'.

Hit M-TAB.  All files in the _current directory_, are shown in *Completions*.
That is, (a) the "~/" is ignored, and `default-directory' is used for
completion, and (b) the file names shown do not necessarily contain `e'.

IOW, as with the previous desciptions I've given, the text before point is
ignored for matching.

If I put point before the `e' then *Completions* shows the names of all files in
"~/" that start with `.' and contain `e'.

I'm not sure what matching algorithm you're using - it does not include all
names that contain both `.' and `e' or `.' followed somewhere by `e'.  It
contains only the names that start with `.' and contain `e' somewhere.

If I put point before the `.' then *Completions* apparently shows all names that
contain `.e' as a substring.  (That's a very different set than when point is
between the `.' and `e'.)

If I put point before the `/' then Emacs says are no matches at all.

If I put point before the `~' then *Completions* shows only the file names that
contain a (literal) `~'.

(To me, besides the bug reported, this mix of matchings does not seem very user
friendly, but I do not expect you will agree about that.)