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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: rgm <at> gnu.org, 6830 <at> debbugs.gnu.org
Subject: bug#6830: widget-complete bad completions in :type 'file
Date: Sat, 25 Feb 2012 08:54:24 +0200

> From: Chong Yidong <cyd <at> gnu.org>
> Cc: Glenn Morris <rgm <at> gnu.org>,  6830 <at> debbugs.gnu.org
> Date: Sat, 25 Feb 2012 11:30:30 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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?

I think it's quite clear: the internal details of how qsort is
implemented on each system.

> 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 didn't try, but I don't see how this would help.  The above overlay
_is_ the cause of the problem: it causes find_field to fail work as
expected.  Here's the relevant fragment of find_field:

  before_field
    = (XFASTINT (pos) > BEGV
       ? get_char_property_and_overlay (make_number (XINT (pos) - 1),
					Qfield, Qnil, NULL)
       /* Using nil here would be a more obvious choice, but it would
          fail when the buffer starts with a non-sticky field.  */
       : after_field);

  /* See if we need to handle the case where MERGE_AT_BOUNDARY is nil
     and POS is at beginning of a field, which can also be interpreted
     as the end of the previous field.  Note that the case where if
     MERGE_AT_BOUNDARY is non-nil (see function comment) is actually the
     more natural one; then we avoid treating the beginning of a field
     specially.  */
  if (NILP (merge_at_boundary))
    {
      Lisp_Object field = get_pos_property (pos, Qfield, Qnil);
      if (!EQ (field, after_field))
	at_field_end = 1;
      if (!EQ (field, before_field))
	at_field_start = 1;

The last comparison of `field' with `before_field' is the culprit: to
work correctly, they must be equal, but the above overlay causes
get_char_property_and_overlay to return `completion' instead of the
expected field value, so find_field decides we are both at the
beginning and at the end of the field, i.e. the field is empty.

Having the priority of the above overlay higher will just cause the
completion fail on GNU/Linux as well, AFAIU.  We would need this
overlay to have a _lower_ priority, for the code to DTRT, but (a) the
ELisp manual says not to use negative priorities, and (b) doing so
might very well cause trouble elsewhere, if the completion code calls
get-char-property-and-overlay and expects to get the `completion'
thing back.

Previous Next

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