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: Fri, 24 Feb 2012 21:35:15 +0200 Message-ID: <83ty2grpn0.fsf@gnu.org> References: <871v99wgb1.fsf@stupidchicken.com> <87tym5ufk0.fsf@stupidchicken.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1330112075 9641 80.91.229.3 (24 Feb 2012 19:34:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 24 Feb 2012 19:34:35 +0000 (UTC) Cc: 6830@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 24 20:34:33 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 1S10uX-0008PC-As for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 Feb 2012 20:34:33 +0100 Original-Received: from localhost ([::1]:38105 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S10uW-0004C8-Qu for geb-bug-gnu-emacs@m.gmane.org; Fri, 24 Feb 2012 14:34:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S10uT-0004Ba-73 for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2012 14:34:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S10uS-0002xp-5M for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2012 14:34:29 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S10uS-0002xl-1B for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2012 14:34:28 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1S10ww-0001N5-Ew for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2012 14:37: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: Fri, 24 Feb 2012 19:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6830 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: unreproducible moreinfo Original-Received: via spool by 6830-submit@debbugs.gnu.org id=B6830.13301122205261 (code B ref 6830); Fri, 24 Feb 2012 19:37:02 +0000 Original-Received: (at 6830) by debbugs.gnu.org; 24 Feb 2012 19:37:00 +0000 Original-Received: from localhost ([127.0.0.1]:54525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S10wt-0001Mm-MH for submit@debbugs.gnu.org; Fri, 24 Feb 2012 14:37:00 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:60850) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S10wq-0001MY-Di for 6830@debbugs.gnu.org; Fri, 24 Feb 2012 14:36:59 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LZW00D00WWR6R00@a-mtaout22.012.net.il> for 6830@debbugs.gnu.org; Fri, 24 Feb 2012 21:34:14 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.127.12.178]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LZW00D0TX111C60@a-mtaout22.012.net.il>; Fri, 24 Feb 2012 21:34:14 +0200 (IST) In-reply-to: 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:57190 Archived-At: > From: Glenn Morris > Date: Wed, 22 Feb 2012 16:33:56 -0500 > > Chong Yidong wrote: > > > If I enter "~/aaa" in the widget field and there is no file starting > > with "aaa" in my home directory, M-TAB does nothing except for > > displaying "No match" in the echo area. > > > > This is with the latest trunk, on GNU/Linux. > > I also cannot reproduce this. > If no-one can reproduce this using stock Emacs on MS Windows, I suggest > closing this. Please don't close it. IIUC (and I'm not at all sure, as the complexity of wid-edit.el and minibuffer.el is above my pay-grade), the fact that it works on GNU/Linux is sheer luck. What seems to happen is this: . widget-complete calls completion-in-region, which in turn calls minibuffer-complete, after let-binding the necessary variables: (let ((minibuffer-completion-table collection) (minibuffer-completion-predicate predicate) (ol (make-overlay start end nil nil t))) (overlay-put ol 'field 'completion) (when completion-in-region-mode-predicate (completion-in-region-mode 1) (setq completion-in-region--data (list (current-buffer) start end collection))) (unwind-protect (call-interactively 'minibuffer-complete) . minibuffer-complete calls completion--do-completion, which does this at its very beginning: (let* ((beg (field-beginning)) (end (field-end)) (string (buffer-substring beg end)) (md (completion--field-metadata beg)) On GNU/Linux, field-beginning is correctly computed to be at the beginning of the field, and thus buffer-substring correctly extracts whatever you typed into the field, and that substring is thereafter correctly completed. In contrast, on Windows, field-beginning returns the position of point, so if point is at the end of whatever you typed (as it usually is when one hits M-TAB), buffer-substring extracts an empty string, which is then "completed" to the files in the default-directory. The difference between the two system is, so it seems, that find_field, which is the workhorse of field-beginning, looks at overlays at point and before point which have the `field' property. The problem is that we have 2 such overlays before point: one whose `field' value is `completion' (as can be seen above, this overlay is put there by completion-in-region), and another whose `field' value is identical to the `field' text property at point. Both of these overlays have nil as their priority, so when get_char_property_and_overlay sorts the overlays by priority, the resulting order is arbitrary. 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. I hope that this analysis (if it is correct) will allow someone smarter than myself to figure out how to fix this.