From unknown Mon Aug 18 17:57:54 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj Reply-To: "Drew Adams" , 4708@debbugs.gnu.org Resent-From: "Drew Adams" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 12 Oct 2009 19:10:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: report 4708 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125537437028880 (code B ref -1); Mon, 12 Oct 2009 19:10:06 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 12 Oct 2009 19:06:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.3 required=4.0 tests=AWL,FOURLA,STOCKLIKE, SUBJMONEY autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9CJ69rQ028877 for ; Mon, 12 Oct 2009 12:06:10 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MxQDg-0004sy-QE for bug-gnu-emacs@gnu.org; Mon, 12 Oct 2009 15:06:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxQDb-0004rN-I7 for bug-gnu-emacs@gnu.org; Mon, 12 Oct 2009 15:06:07 -0400 Received: from [199.232.76.173] (port=51847 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxQDb-0004rH-BG for bug-gnu-emacs@gnu.org; Mon, 12 Oct 2009 15:06:03 -0400 Received: from acsinet12.oracle.com ([141.146.126.234]:22977) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MxQDa-0002mu-PI for bug-gnu-emacs@gnu.org; Mon, 12 Oct 2009 15:06:03 -0400 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9CJ5sOr009709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Oct 2009 19:05:55 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9BMjkBo009511 for ; Mon, 12 Oct 2009 19:05:56 GMT Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 20355776511255374329; Mon, 12 Oct 2009 12:05:29 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Oct 2009 12:05:29 -0700 From: "Drew Adams" To: Date: Mon, 12 Oct 2009 12:05:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpLbvis20jIokH4Tx+n6K5zCjDEyg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4AD37E13.012A:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) emacs -Q M-: (completion-try-completion "c:/some-dir/$HOMj" nil 16) correctly returns: (c:/some-dir/$HOMEj" . 17) M-: (completion-try-completion "c:/some-dir/$HOMj" nil 17) returns: ("c:/some-dir/$$HOMj" . 18) That doesn't seem correct. Is it correct to have $$ here? If so, can you please explain it a bit (why)? Also, if this is correct behavior, then please explain this in the doc string of `completion-try-completion'. The doc string currently says that STRING, in the return value of (STRING . NEWPOINT), is "the completed result string". But "result string" cannot be right, if we're talking about the result of completion. There is no completion that contains $$HOM. In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-29 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4)' From unknown Mon Aug 18 17:57:54 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj Reply-To: Stefan Monnier , 4708@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 13 Oct 2009 20:20:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4708 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12554648254737 (code B ref -1); Tue, 13 Oct 2009 20:20:06 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 13 Oct 2009 20:13:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, STOCKLIKE,SUBJMONEY autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9DKDhTe004734 for ; Tue, 13 Oct 2009 13:13:44 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mxnkc-0000S2-Q3 for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 16:13:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxnkY-0000Qt-AY for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 16:13:42 -0400 Received: from [199.232.76.173] (port=39176 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxnkY-0000Qp-7n for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 16:13:38 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:55658) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MxnkX-0007A5-Pn for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 16:13:38 -0400 Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n9DKDPbf020281; Tue, 13 Oct 2009 16:13:26 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id D9BED3A07F; Tue, 13 Oct 2009 16:13:25 -0400 (EDT) From: Stefan Monnier To: Drew Adams Cc: 4708@debbugs.gnu.org, Message-ID: References: Date: Tue, 13 Oct 2009 16:13:25 -0400 In-Reply-To: (Drew Adams's message of "Mon, 12 Oct 2009 12:05:32 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3383=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-CrossAssassin-Score: 2 >>>>> "Drew" == Drew Adams writes: > emacs -Q > M-: (completion-try-completion "c:/some-dir/$HOMj" nil 16) > correctly returns: (c:/some-dir/$HOMEj" . 17) > M-: (completion-try-completion "c:/some-dir/$HOMj" nil 17) > returns: ("c:/some-dir/$$HOMj" . 18) > That doesn't seem correct. Is it correct to have $$ here? If so, can > you please explain it a bit (why)? File name entry assigns a special meaning to $ for envvars, but in order to be able to refer to the file "$HOME", it offers an escape system where you write "$$HOME". Since Emacs-21 or so, I've made this escape unnecessary in the case where the $ is used unambiguously (because there is no envvar of this name), so if you enter "$HOMj", Emacs know you don't refer to the file name contained in the envvar `HOMj', but to the file named $HOMj. The completion code need to do such unescape/reescaping in order to work properly and it currently re-escapes in a conservative way (i.e. it re-escapes $HOMj into $$HOMj even tho it's not strictly necessary). File name completion is designed to result a string appropriate for substitute-in-file-name, and indeed (substitute-in-file-name "c:/some-dir/$$HOMj") -> "c:/some-dir/$HOMj" > Also, if this is correct behavior, then please explain this in the doc > string of `completion-try-completion'. It can't be described there, because that function applies to any kind of completion, whereas the above only applies to completions using read-file-name-internal. Stefan From unknown Mon Aug 18 17:57:54 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj Reply-To: "Drew Adams" , 4708@debbugs.gnu.org Resent-From: "Drew Adams" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 13 Oct 2009 22:30:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4708 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125547249127575 (code B ref -1); Tue, 13 Oct 2009 22:30:04 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 13 Oct 2009 22:21:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, STOCKLIKE,SUBJMONEY autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9DMLT4G027572 for ; Tue, 13 Oct 2009 15:21:30 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MxpkG-0006rE-TK for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 18:21:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxpkC-0006mA-JD for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 18:21:28 -0400 Received: from [199.232.76.173] (port=46352 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxpkC-0006ls-Cr for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 18:21:24 -0400 Received: from acsinet11.oracle.com ([141.146.126.233]:17000) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MxpkB-0001GG-UG for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 18:21:24 -0400 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9DMLPEb008042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Oct 2009 22:21:26 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9DML5LC019815; Tue, 13 Oct 2009 22:21:06 GMT Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 20385643251255472438; Tue, 13 Oct 2009 15:20:38 -0700 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 15:20:37 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4708@debbugs.gnu.org>, References: Date: Tue, 13 Oct 2009 15:20:38 -0700 Message-ID: <9F5586021A3F42B0837D2F27AF4DC637@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpMQazZtCW01r8LSa+C7dmMC+RMmAADbUng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4AD4FD51.00C4:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) > > emacs -Q > > M-: (completion-try-completion "c:/some-dir/$HOMj" nil 16) > > correctly returns: (c:/some-dir/$HOMEj" . 17) > > M-: (completion-try-completion "c:/some-dir/$HOMj" nil 17) > > returns: ("c:/some-dir/$$HOMj" . 18) > > > That doesn't seem correct. Is it correct to have $$ here? If so, can > > you please explain it a bit (why)? > > File name entry assigns a special meaning to $ for envvars, > but in order to be able to refer to the file "$HOME", it offers > an escape system where you write "$$HOME". Since Emacs-21 or so, > I've made this escape unnecessary in the case where the $ is > used unambiguously (because there is no envvar of this name), > so if you enter "$HOMj", Emacs know you don't refer to the file > name contained in the envvar `HOMj', but to > the file named $HOMj. But there is no such file either. There is neither an envar that starts with `$HOMj' nor a file whose name starts with `$HOMj'. No matter how you look at it, there is no possible completion for `$HOMj'. Based on the doc string, I would expect nil, to indicate that there is no possible completion. > The completion code need to do such unescape/reescaping in > order to work properly and it currently re-escapes in a > conservative way (i.e. it re-escapes $HOMj into $$HOMj even > tho it's not strictly necessary). > > File name completion is designed to result a string appropriate for > substitute-in-file-name, and indeed > > (substitute-in-file-name "c:/some-dir/$$HOMj") -> > "c:/some-dir/$HOMj" > > > Also, if this is correct behavior, then please explain this > > in the doc string of `completion-try-completion'. > > It can't be described there, because that function applies to any kind > of completion, whereas the above only applies to completions using > read-file-name-internal. You describe some of the foibles of the implementation, but you don't really address the bug. It's not clear whether you intend to do that later or you are trying to say that there is in fact no bug. Code that calls `completion-try-completion' does not necessarily know what the value of the TABLE arg is (i.e. whether it is equivalent to `read-file-name-internal'), so it does not necessarily know whether this is file-name completion or not. `completion-try-completion' needs to have an unambiguous way to indicate that there is no completion possible for the given input, even if it is the TABLE arg that ultimately gives it that info. The doc says that nil is the way that no-possible-completion is indicated. But in this case nil is not returned. Instead, the return value can only be interpreted, based on the doc string, as indicating that there is one completion, "c:/some-dir/$$HOMj" (however that is to be intepreted: as a file name that includes two `$' or as a file name that includes one `$' followed by an env var). But there is in fact no legitimate completion. There is no way that "c:/some-dir/$$HOMj" is a valid completion for "c:/some-dir/$HOMj" - whether you regard the input as a file name that includes a `$' or you regard it as an attempt to complete an env var. There simply is no way that "c:/some-dir/$$HOMj" completes. You can decide where the bug is: `read-file-name-internal', `completion-try-completion', or somewhere else, but there is a bug if a value claimed to represent a successful completion is returned when there is no valid completion. Or else there must be some way to tell from that returned value that it in fact somehow represents "there is no completion" (the same as nil does). In that case, let me know what that way is, and I'll test the return value using it. And in that case the doc string also needs to document this how-to-tell info. IOW, either the return value is correct and somehow indicates that there is no completion - and in that case how to tell that? Or the return value is incorrect, because it indicates a completion when there is none. Either way, there is a bug. I don't know how to handle this return value. My code currently checks for nil as the (only) indicator of non-completion, and so it incorrectly interprets this as successful completion. From unknown Mon Aug 18 17:57:54 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj Reply-To: Stefan Monnier , 4708@debbugs.gnu.org Resent-From: Stefan Monnier Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 14 Oct 2009 02:45:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4708 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12554880231503 (code B ref -1); Wed, 14 Oct 2009 02:45:05 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 14 Oct 2009 02:40:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,STOCKLIKE,SUBJMONEY autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E2eLKW001499 for ; Tue, 13 Oct 2009 19:40:22 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mxtml-0005Dl-Ka for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 22:40:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mxtmg-00057r-5m for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 22:40:18 -0400 Received: from [199.232.76.173] (port=46976 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxtmf-00057b-Ml for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 22:40:13 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:26046 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mxtmf-0002UD-75 for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 22:40:13 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEABvX1EpMCqsb/2dsb2JhbACBUdc5gj+BbgSHag X-IronPort-AV: E=Sophos;i="4.44,555,1249272000"; d="scan'208";a="47523291" Received: from 76-10-171-27.dsl.teksavvy.com (HELO ceviche.home) ([76.10.171.27]) by ironport2-out.pppoe.ca with ESMTP; 13 Oct 2009 22:40:12 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 6E21CB40B9; Tue, 13 Oct 2009 22:40:12 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: <4708@debbugs.gnu.org>, Message-ID: References: <9F5586021A3F42B0837D2F27AF4DC637@us.oracle.com> Date: Tue, 13 Oct 2009 22:40:12 -0400 In-Reply-To: <9F5586021A3F42B0837D2F27AF4DC637@us.oracle.com> (Drew Adams's message of "Tue, 13 Oct 2009 15:20:38 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-CrossAssassin-Score: 2 >> File name entry assigns a special meaning to $ for envvars, >> but in order to be able to refer to the file "$HOME", it offers >> an escape system where you write "$$HOME". Since Emacs-21 or so, >> I've made this escape unnecessary in the case where the $ is >> used unambiguously (because there is no envvar of this name), >> so if you enter "$HOMj", Emacs know you don't refer to the file >> name contained in the envvar `HOMj', but to >> the file named $HOMj. > But there is no such file either. There is neither an envar that > starts with `$HOMj' nor a file whose name starts with `$HOMj'. > No matter how you look at it, there is no possible completion for > `$HOMj'. Based on the doc string, I would expect nil, to indicate > that there is no possible completion. Good point, I missed it, sorry. That try-completion will return nil when applied to "/foo/bar/$$HOMj", so basically the $HOMj -> $$HOMj is considered to be a form of completion. That decision is taken by read-file-name-internal. Can you try the patch below to see if it improves the behavior? >> > Also, if this is correct behavior, then please explain this >> > in the doc string of `completion-try-completion'. >> It can't be described there, because that function applies to any kind >> of completion, whereas the above only applies to completions using >> read-file-name-internal. > You describe some of the foibles of the implementation, but you don't > really address the bug. No it's not just a detail of the implementation. The completion is split into "completion code" and "completion tables". > It's not clear whether you intend to do that later or you are trying > to say that there is in fact no bug. There is no bug w.r.t the docstring of completion-try-completion not mentioning anything about $-escaping. > Code that calls `completion-try-completion' does not necessarily know > what the value of the TABLE arg is (i.e. whether it is equivalent to > `read-file-name-internal'), so it does not necessarily know whether > this is file-name completion or not. Code that calls completion-try-completion has to assume that if it returns a string, some expansion took place. It's as simple as that. > `completion-try-completion' needs to have an unambiguous way to > indicate that there is no completion possible for the given input, There is, it's the nil return value. Note that some completion tables may never be able to determine it and may hence never return nil. Note that a completion table might very well allow completion from /u to /usr/ even if none of the files in /usr/ are acceptable completion candidates. I.e. try-completion may sometimes return a string even if there is no real valid completion with that prefix. This is simply because it may be too costly for the function to verify it (e.g. having to traverse the whole /usr/ subtree). Stefan --- minibuffer.el.~1.84.~ 2009-09-24 10:49:09.000000000 -0400 +++ minibuffer.el 2009-10-13 22:36:42.000000000 -0400 @@ -1078,16 +1078,18 @@ ((null action) (let ((comp (file-name-completion name realdir read-file-name-predicate))) - (if (stringp comp) + (cond + ((stringp comp) ;; Requote the $s before returning the completion. - (minibuffer--double-dollars (concat specdir comp)) + (minibuffer--double-dollars (concat specdir comp))) + (comp ;; Requote the $s before checking for changes. (setq str (minibuffer--double-dollars str)) (if (string-equal string str) comp ;; If there's no real completion, but substitute-in-file-name ;; changed the string, then return the new string. - str)))) + str))))) ((eq action t) (let ((all (file-name-all-completions name realdir))) From unknown Mon Aug 18 17:57:54 2025 X-Loop: owner@emacsbugs.donarmstrong.com Subject: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj Reply-To: "Drew Adams" , 4708@debbugs.gnu.org Resent-From: "Drew Adams" Resent-To: bug-submit-list@lists.donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 14 Oct 2009 03:45:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-Emacs-PR-Message: followup 4708 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Received: via spool by submit@emacsbugs.donarmstrong.com id=B.125549140610957 (code B ref -1); Wed, 14 Oct 2009 03:45:05 +0000 Received: (at submit) by emacsbugs.donarmstrong.com; 14 Oct 2009 03:36:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.8 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,STOCKLIKE,SUBJMONEY autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E3aj5i010952 for ; Tue, 13 Oct 2009 20:36:46 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MxufM-00014q-Sj for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 23:36:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxufI-000146-CQ for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 23:36:44 -0400 Received: from [199.232.76.173] (port=45089 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxufI-000143-6C for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 23:36:40 -0400 Received: from rcsinet11.oracle.com ([148.87.113.123]:49345 helo=rgminet11.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MxufH-0001cU-Lz for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 23:36:39 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9E3bkrI015973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 03:37:47 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9E2vfIt000971; Wed, 14 Oct 2009 03:37:25 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 20387840691255491364; Tue, 13 Oct 2009 20:36:04 -0700 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 20:36:04 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4708@debbugs.gnu.org>, References: <9F5586021A3F42B0837D2F27AF4DC637@us.oracle.com> Date: Tue, 13 Oct 2009 20:36:08 -0700 Message-ID: <1BA03741DA0342379EBFBADC279839F8@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpMd6xbh3ux+B4QRhGlYp6RyBeIRgAAqNQw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4AD5473C.00C9:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) > That try-completion will return nil when applied to "/foo/bar/$$HOMj", > so basically the $HOMj -> $$HOMj is considered to be a form > of completion. Sorry, I don't follow that. Could you say it differently? And did you mean try-completion or completion-try-completion? Sorry, I don't know what you mean here. > That decision is taken by read-file-name-internal. Can you try the > patch below to see if it improves the behavior? Yes, it seems to fix the problem. Thanks. > Note that a completion table might very well allow completion > from /u to /usr/ even if none of the files in /usr/ are > acceptable completion candidates. I.e. try-completion may > sometimes return a string even if there is no real valid > completion with that prefix. This is simply because it may > be too costly for the function to verify it (e.g. having > to traverse the whole /usr/ subtree). I understand. The problem is not so much what is done and the given trade-offs chosen for a case like that. The problem is to keep users in control - at the very least giving them knowledge of what the story is. If the command in question tells users just what you said, then they can know what to expect and can act en connaissance de cause. What's not good is to surprise users or keep them guessing about what's happening and why. This is a problem with DWIM generally. It's no big deal for something inconsequential, but it can matter where user actions depend on the result. Users need to have a reasonable mental model of the behavior (which need not reflect how things are actually implemented, of course). Part of helping them in this respect is providing feedback. I've said before that partial completion can be surprising and confusing - that's nothing new. But what's worse is that we slip silently from one kind of completion attempt to another, and another. We don't say, "No prefix completions found. Do you want to try now for partial completions?". After running down an unknown number of completion methods under the covers, we don't even let the user know at the end which method was ultimately successful. The user has no way of knowing what kind of completion was actually used, which means no good way of determining how the result relates to his input. This can make him lose confidence in his mental model, his general understanding of the program, and ultimately himself. We should be empowering users, not making them feel like they're not in control or have no idea what's going on. Sure, sometimes it doesn't really matter. You don't need to know the details about how Google finds what it finds - as long as the results seem sensible to you most of the time. I believe that with the latest completion enhancements Emacs users are too often confused and surprised, and that we could do a better job of helping them understand - at least what happened and why. Anyway, this bug seems to have been fixed - thx. From unknown Mon Aug 18 17:57:54 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) X-Loop: owner@emacsbugs.donarmstrong.com From: help-debbugs@gnu.org (Emacs bug Tracking System) To: "Drew Adams" Subject: bug#4708 closed by Stefan Monnier (Re: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj) Message-ID: References: X-Emacs-PR-Message: they-closed 4708 X-Emacs-PR-Package: emacs Reply-To: 4708@debbugs.gnu.org Date: Wed, 14 Oct 2009 04:10:09 +0000 Content-Type: multipart/mixed; boundary="----------=_1255493409-15936-1" This is a multi-part message in MIME format... ------------=_1255493409-15936-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is an automatic notification regarding your bug report which was filed against the emacs package: #4708: 23.1; completion-try-completion adds an extra $: $$HOMj It has been closed by Stefan Monnier . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Stefan Monnier by replying to this email. --=20 4708: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D4708 Emacs Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1255493409-15936-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 4708-done) by emacsbugs.donarmstrong.com; 14 Oct 2009 04:02:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,HAS_BUG_NUMBER,SUBJMONEY autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.183]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E42O0K014289 for <4708-done@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 21:02:25 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEANvp1EpMCqsb/2dsb2JhbACBUdcqhC0Eh2o X-IronPort-AV: E=Sophos;i="4.44,555,1249272000"; d="scan'208";a="47525006" Received: from 76-10-171-27.dsl.teksavvy.com (HELO ceviche.home) ([76.10.171.27]) by ironport2-out.pppoe.ca with ESMTP; 14 Oct 2009 00:02:19 -0400 Received: by ceviche.home (Postfix, from userid 20848) id EE46EB40B9; Wed, 14 Oct 2009 00:02:18 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj Message-ID: References: <9F5586021A3F42B0837D2F27AF4DC637@us.oracle.com> <1BA03741DA0342379EBFBADC279839F8@us.oracle.com> Date: Wed, 14 Oct 2009 00:02:18 -0400 In-Reply-To: <1BA03741DA0342379EBFBADC279839F8@us.oracle.com> (Drew Adams's message of "Tue, 13 Oct 2009 20:36:08 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> That try-completion will return nil when applied to "/foo/bar/$$HOMj", >> so basically the $HOMj -> $$HOMj is considered to be a form >> of completion. > Sorry, I don't follow that. Just what I said: read-file-name-internal considered that changing "$HOMj" into "$$HOMj" is a form of completion. Just like hitting TAB might change Foo into FOO in some completion cases. > And did you mean try-completion or completion-try-completion? Makes no difference, it's done in the completion-table, i.e. at a lower level. Stefan ------------=_1255493409-15936-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by emacsbugs.donarmstrong.com; 12 Oct 2009 19:06:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.3 required=4.0 tests=AWL,FOURLA,STOCKLIKE, SUBJMONEY autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9CJ69rQ028877 for ; Mon, 12 Oct 2009 12:06:10 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MxQDg-0004sy-QE for bug-gnu-emacs@gnu.org; Mon, 12 Oct 2009 15:06:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxQDb-0004rN-I7 for bug-gnu-emacs@gnu.org; Mon, 12 Oct 2009 15:06:07 -0400 Received: from [199.232.76.173] (port=51847 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxQDb-0004rH-BG for bug-gnu-emacs@gnu.org; Mon, 12 Oct 2009 15:06:03 -0400 Received: from acsinet12.oracle.com ([141.146.126.234]:22977) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MxQDa-0002mu-PI for bug-gnu-emacs@gnu.org; Mon, 12 Oct 2009 15:06:03 -0400 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9CJ5sOr009709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Oct 2009 19:05:55 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9BMjkBo009511 for ; Mon, 12 Oct 2009 19:05:56 GMT Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 20355776511255374329; Mon, 12 Oct 2009 12:05:29 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Oct 2009 12:05:29 -0700 From: "Drew Adams" To: Subject: 23.1; completion-try-completion adds an extra $: $$HOMj Date: Mon, 12 Oct 2009 12:05:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpLbvis20jIokH4Tx+n6K5zCjDEyg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4AD37E13.012A:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) emacs -Q M-: (completion-try-completion "c:/some-dir/$HOMj" nil 16) correctly returns: (c:/some-dir/$HOMEj" . 17) M-: (completion-try-completion "c:/some-dir/$HOMj" nil 17) returns: ("c:/some-dir/$$HOMj" . 18) That doesn't seem correct. Is it correct to have $$ here? If so, can you please explain it a bit (why)? Also, if this is correct behavior, then please explain this in the doc string of `completion-try-completion'. The doc string currently says that STRING, in the return value of (STRING . NEWPOINT), is "the completed result string". But "result string" cannot be right, if we're talking about the result of completion. There is no completion that contains $$HOM. In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-29 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4)' ------------=_1255493409-15936-1--