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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cyd@gnu.org,  6830@debbugs.gnu.org
> Date: Wed, 07 Mar 2012 17:09:56 -0500
> 
> > The value of `field' on MS-Windows is neither `boundary' nor nil.
> > It is the value of the widget itself.  Here's just its beginning, as an
> > illustration:
> 
> Oh, I think I see, now.
> There are 2 overlays defining a field: one if the setup by the
> completion code, the other by the widget code.  both cover the same text
> area

Yes.

> so using either would be fine.

??? I don't understand this part.  It maybe OK in this particular
case, because all you care about is the range of buffer positions
covered by the overlay.  But in general, the value of the field
property is presumably of at least some importance to the Lisp
application that examines the field.  So feeding the application by
some other overlay, even if covers the same text, is generally unsafe,
don't you agree?  Or am I missing something?

> Now since both overlays cover the exact same area, and have no
> `priority', none has priority over the other, so which of the two is
> used depends on arbitrary details, e.g. implementation of the
> `sort' function.

Right.

> Now, until here, there's still no bug because indeed it doesn't matter
> which overlay we use to determine the field.

See above.  I'm not sure this is correct in general.  And what if one
of the overlays covers more buffer positions than the other?  Wouldn't
it sometimes confuse the completion code?

> Does the patch below fix the problem?

It does, but on Windows both `before_field' and `field' now have the
value of the widget, not of `completion'.

More generally, the overlay returned by get-char-property-and-overlay
in this situation is still arbitrary after your change, and the Lisp
application still has no control on which one will be returned.  So
same issue of having more than one `field' overlay on the same buffer
position still remains.