From unknown Mon Aug 18 14:21:28 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#4708 <4708@debbugs.gnu.org> To: bug#4708 <4708@debbugs.gnu.org> Subject: Status: 23.1; completion-try-completion adds an extra $: $$HOMj Reply-To: bug#4708 <4708@debbugs.gnu.org> Date: Mon, 18 Aug 2025 21:21:28 +0000 retitle 4708 23.1; completion-try-completion adds an extra $: $$HOMj reassign 4708 emacs submitter 4708 "Drew Adams" severity 4708 normal thanks From drew.adams@oracle.com Mon Oct 12 12:06:10 2009 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)' From monnier@IRO.UMontreal.CA Tue Oct 13 13:13:44 2009 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, Subject: Re: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj 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 drew.adams@oracle.com Tue Oct 13 15:21:31 2009 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: Subject: RE: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj 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 monnier@iro.umontreal.ca Tue Oct 13 19:40:22 2009 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>, Subject: Re: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj 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 drew.adams@oracle.com Tue Oct 13 20:36:46 2009 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> Subject: RE: bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj 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 monnier@iro.umontreal.ca Tue Oct 13 21:02:26 2009 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 From unknown Mon Aug 18 14:21:28 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 11 Nov 2009 15:24:15 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator