[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#6830: widget-complete bad completions in :type 'file
From: |
Eli Zaretskii |
Subject: |
bug#6830: widget-complete bad completions in :type 'file |
Date: |
Sat, 25 Feb 2012 09:45:00 +0200 |
> 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.
- bug#6830: widget-complete bad completions in :type 'file, (continued)
bug#6830: widget-complete bad completions in :type 'file, Eli Zaretskii, 2012/02/24