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: 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: Fri, 09 Mar 2012 11:14:35 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: cyd <at> gnu.org,  6830 <at> 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.

Previous Next

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