From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#6830: widget-complete bad completions in :type 'file Date: Sat, 25 Feb 2012 08:54:24 +0200 Message-ID: <83linrs8rj.fsf@gnu.org> References: <871v99wgb1.fsf@stupidchicken.com> <87tym5ufk0.fsf@stupidchicken.com> <83ty2grpn0.fsf@gnu.org> <87d393zj1l.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1330152821 26610 80.91.229.3 (25 Feb 2012 06:53:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 25 Feb 2012 06:53:41 +0000 (UTC) Cc: 6830@debbugs.gnu.org To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 25 07:53:40 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S1BVj-0001Qr-3U for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Feb 2012 07:53:39 +0100 Original-Received: from localhost ([::1]:44476 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1BVi-0004kV-Dv for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Feb 2012 01:53:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1BVa-0004kM-U3 for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2012 01:53:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S1BVV-0000K4-6Q for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2012 01:53:30 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1BVV-0000Jz-20 for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2012 01:53:25 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1S1BY2-0004mv-7i for bug-gnu-emacs@gnu.org; Sat, 25 Feb 2012 01:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Feb 2012 06:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6830 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6830-submit@debbugs.gnu.org id=B6830.133015290418342 (code B ref 6830); Sat, 25 Feb 2012 06:56:02 +0000 Original-Received: (at 6830) by debbugs.gnu.org; 25 Feb 2012 06:55:04 +0000 Original-Received: from localhost ([127.0.0.1]:55008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S1BX6-0004lm-Di for submit@debbugs.gnu.org; Sat, 25 Feb 2012 01:55:04 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58028) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S1BX3-0004lL-OS for 6830@debbugs.gnu.org; Sat, 25 Feb 2012 01:55:03 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LZX00H00RNSES00@a-mtaout22.012.net.il> for 6830@debbugs.gnu.org; Sat, 25 Feb 2012 08:52:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.12.178]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LZX00H1HSF9AA60@a-mtaout22.012.net.il>; Sat, 25 Feb 2012 08:52:22 +0200 (IST) In-reply-to: <87d393zj1l.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:57223 Archived-At: > From: Chong Yidong > Cc: Glenn Morris , 6830@debbugs.gnu.org > Date: Sat, 25 Feb 2012 11:30:30 +0800 > > Eli Zaretskii 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.