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: Mon, 05 Mar 2012 19:28:14 +0200 Message-ID: <83linf9cup.fsf@gnu.org> References: <871v99wgb1.fsf@stupidchicken.com> <87tym5ufk0.fsf@stupidchicken.com> <83ty2grpn0.fsf@gnu.org> <87d393zj1l.fsf@gnu.org> <83linrs8rj.fsf@gnu.org> <87sjhoiu4q.fsf@gnu.org> <83zkbw9tyv.fsf@gnu.org> <87boobd9tr.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1330968626 24583 80.91.229.3 (5 Mar 2012 17:30:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 5 Mar 2012 17:30:26 +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 Mon Mar 05 18:30:25 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S4bjq-0006nl-F6 for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Mar 2012 18:30:22 +0100 Original-Received: from localhost ([::1]:39748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4bjp-0003r4-Qp for geb-bug-gnu-emacs@m.gmane.org; Mon, 05 Mar 2012 12:30:21 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4bjd-0003pa-Qg for bug-gnu-emacs@gnu.org; Mon, 05 Mar 2012 12:30:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4bjF-0000xM-7C for bug-gnu-emacs@gnu.org; Mon, 05 Mar 2012 12:30:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4bjF-0000xF-3A for bug-gnu-emacs@gnu.org; Mon, 05 Mar 2012 12:29:45 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1S4bjX-0006oI-0E for bug-gnu-emacs@gnu.org; Mon, 05 Mar 2012 12:30:03 -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: Mon, 05 Mar 2012 17:30: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.133096856826082 (code B ref 6830); Mon, 05 Mar 2012 17:30:02 +0000 Original-Received: (at 6830) by debbugs.gnu.org; 5 Mar 2012 17:29:28 +0000 Original-Received: from localhost ([127.0.0.1]:34402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S4bix-0006mS-Gd for submit@debbugs.gnu.org; Mon, 05 Mar 2012 12:29:27 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:63109) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S4bib-0006lT-Fs for 6830@debbugs.gnu.org; Mon, 05 Mar 2012 12:29:15 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M0F004009FGBA00@a-mtaout22.012.net.il> for 6830@debbugs.gnu.org; Mon, 05 Mar 2012 19:28:15 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.119.172]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M0F004F09V01R70@a-mtaout22.012.net.il>; Mon, 05 Mar 2012 19:28:13 +0200 (IST) In-reply-to: <87boobd9tr.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:57511 Archived-At: > From: Chong Yidong > Cc: rgm@gnu.org, 6830@debbugs.gnu.org > Date: Mon, 05 Mar 2012 11:07:44 +0800 > > Eli Zaretskii writes: > > > What do you get on GNU/Linux for the values of `field', > > `before_field', and `after_field'? > > This is from doing M-x customize-variable RET abbrev-file-name RET, and > doing C-M-i after the end of the file name in the editable field: > > (gdb) pp after_field > boundary > (gdb) pp before_field > completion > (gdb) pp field > completion Then it looks like my analysis was partially incorrect: I assumed that the problem was with the value of `before_field', but it actually is with the value of `field'. (Same reason, though: sorting two items whose keys compare equal.) > >> FWIW, increasing the priority of the `completion' overlay does not cause > >> widget file name completion to fail on GNU/Linux. Could you try on > >> Windows? > > > > Give me a patch to try, and I will. > > === modified file 'lisp/minibuffer.el' > *** lisp/minibuffer.el 2012-02-23 15:41:12 +0000 > --- lisp/minibuffer.el 2012-03-05 03:04:20 +0000 > *************** > *** 1483,1488 **** > --- 1483,1489 ---- > (minibuffer-completion-predicate predicate) > (ol (make-overlay start end nil nil t))) > (overlay-put ol 'field 'completion) > + (overlay-put ol 'priority 5) > (when completion-in-region-mode-predicate > (completion-in-region-mode 1) > (setq completion-in-region--data Yes, this fixes the problem, thanks. But is this a safe solution? Can we safely assume that no code in widget.el or its companions will ever run between overlay-put and delete-overlay in the above function? If some widget.el code can run in between, it will find a value of the field property different from what it expects. In general, the semantics of having more than one overlay with the same property on the same text is only clear to me when these properties specify display features, or more generally features related to the same parent feature. Otherwise, it's not really clear what the precedence means; if we use it just as a means to get the upper hand in some use-case, we are running the risk that some other use-case will lose.