bug#6830: widget-complete bad completions in :type 'file

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

> > If I enter "~/aaa" in the widget field and there is no file starting
> > with "aaa" in my home directory, M-TAB does nothing except for
> > displaying "No match" in the echo area.
> >
> > This is with the latest trunk, on GNU/Linux.
> 
> I also cannot reproduce this.
> If no-one can reproduce this using stock Emacs on MS Windows, 
> I suggest closing this.

I can reproduce it immediately, AFAICT.  I wonder how you actually tried to
reproduce it.

I tested for less than a minute, with emacs -Q:

In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-02-15 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

This seems to be similar to bug #6757 (?).

If I type a file name and then do `M-x widget-complete', exactly as the bug
recipe says, then, just as the bug report says, I get all of the files in the
current directory as completion candidates.

If I move point back one or more chars, so it is is not _after_ all of the text
typed into the entry field, then I get completions that correspond to the text
before point (more or less - see below). However, with point at some positions
in the field I get all of the files in the current directory again, and point
gets moved to the field end.

E.g. with `foo' as the text in the field, left justified, no spaces:

* With point after `foo', all files in the current dir are candidates.

* With point after `fo', only files (in dir) with _prefix_ `fo' are candidates.

* With point after `f', all files (in dir) are candidates, even though there are
some files that begin with `f' and others that do not. Furthermore, point is
automatically moved to the end of the field.  What's that about?

* With point before `f' (cursor on `f'), only files (in dir) that contain
_substring_ `fo' are candidates.

If you add some spaces before `foo', the behavior gets even weirder.  Unlike
most editing of text in Emacs (and most edit fields anywhere else), using such
an edit field is odd, because it is apparently already filled with spaces and is
in a mode similar to overwrite.  It is as if you were in picture mode.  Click in
the middle and point stays there, as if preceded by spaces.

Pretty incomprehensible behavior, if you ask me.  I'm sure there's a logical
explanation, and perhaps some or all of the behavior is even intentional (how to
know?).

However, users will never guess the behavior pattern without some explanation.
I have no idea whether all of the behavior is intentional or there are one or
more bugs.