From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: 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> References: <9F5586021A3F42B0837D2F27AF4DC637@us.oracle.com> Reply-To: Drew Adams , 4708@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1255492066 19674 80.91.229.12 (14 Oct 2009 03:47:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2009 03:47:46 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, 4708@emacsbugs.donarmstrong.com To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 14 05:47:35 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mxupp-0004g6-LQ for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 05:47:34 +0200 Original-Received: from localhost ([127.0.0.1]:36290 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxupp-0004eq-AW for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Oct 2009 23:47:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mxupa-0004Zl-Tq for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 23:47:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxupW-0004Yw-3Y for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 23:47:18 -0400 Original-Received: from [199.232.76.173] (port=60210 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxupV-0004Yg-UG for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 23:47:14 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:56704) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MxupV-0003IB-8G for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 23:47:13 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E3lAm2012290; Tue, 13 Oct 2009 20:47:11 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9E3j7Po011930; Tue, 13 Oct 2009 20:45:07 -0700 Resent-Date: Tue, 13 Oct 2009 20:45:07 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 14 Oct 2009 03:45:07 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4708 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4708-submit@emacsbugs.donarmstrong.com id=B4708.125549139810950 (code B ref 4708); Wed, 14 Oct 2009 03:45:07 +0000 Original-Received: (at 4708) by emacsbugs.donarmstrong.com; 14 Oct 2009 03:36:38 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E3abWF010943 for <4708@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 20:36:38 -0700 Original-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 Original-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 Original-Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 20387840691255491364; Tue, 13 Oct 2009 20:36:04 -0700 Original-Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 20:36:04 -0700 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, 2) Resent-Date: Tue, 13 Oct 2009 23:47:18 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:31904 Archived-At: > 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.