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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  6830@debbugs.gnu.org
> Date: Sat, 25 Feb 2012 00:26:05 -0500
> 
> >> On GNU/Linux, the first overlay in the sorted array happens to be the
> >> one whose `field' value is equal to the text property, so find_field
> >> works.  On MS-Windows, the first overlay is the one whose value is
> >> `completion', so find_field decides that the field begins and ends at
> >> the same position.  The rest, as they say, is history.
> > Interesting.  The overlays code should be independent of operating
> > system.  Any idea what causes the sort order to be different?
> 
> > Does the problem go away if in
> 
> >     (let ((minibuffer-completion-table collection)
> >           (minibuffer-completion-predicate predicate)
> >           (ol (make-overlay start end nil nil t)))
> >       (overlay-put ol 'field 'completion)
> 
> > you also specify a `priority' of (say) 5?
> 
> 
> I'm wondering what is this other overlay, why it's here

It's created by widget-specify-field here:

    (let ((overlay (make-overlay from to nil nil rear-sticky)))
      (widget-put widget :field-overlay overlay)
      ;;(overlay-put overlay 'detachable nil)
      (overlay-put overlay 'field widget) <<<<<<<<<<<<<<<<<<<<<<<<<<<<
      (overlay-put overlay 'local-map keymap)
      (overlay-put overlay 'face face)
      (overlay-put overlay 'follow-link follow-link)
      (overlay-put overlay 'help-echo help-echo)))

The Lisp backtrace looks like this when this is called:

  "widget-specify-field" (0x82eac8)
  "widget-setup" (0x82ed24)
  "custom-buffer-create-internal" (0x82ef94)
  "custom-buffer-create" (0x82f1e4)
  "customize-variable" (0x82f4c4)
  "call-interactively" (0x82f704)
  "execute-extended-command" (0x82f954)
  "call-interactively" (0x82fb84)

IIUC, this code is part of setting up editable fields of a widget.

> and why it ends up sometimes taking precedence,

This one I think I already explained: the order in which we get
overlays of the same priority having the same property depends on the
implementation of qsort.

In any case, looking only at the first of a list of overlays for the
same property, when we are interested in a specific value of the
property and not just for any value, is asking for trouble, I think.