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

Previous Next

Package: emacs;

Reported by: Lennart Borgman <lennart.borgman <at> gmail.com>

Date: Mon, 9 Aug 2010 11:46:01 UTC

Severity: normal

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 6830 <at> debbugs.gnu.org, cyd <at> gnu.org
Subject: bug#6830: widget-complete bad completions in :type 'file
Date: Sat, 25 Feb 2012 09:45:00 +0200
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  6830 <at> 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.




This bug report was last modified 13 years and 75 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.