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#4718: 23.1; C-h f gives doc for the wrong function Date: Tue, 13 Oct 2009 21:24:08 -0700 Message-ID: <662D8A34F24B4D73ABAD8A7BE21766CC@us.oracle.com> References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> Reply-To: Drew Adams , 4718@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 1255495656 26805 80.91.229.12 (14 Oct 2009 04:47:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2009 04:47:36 +0000 (UTC) Cc: 'Juanma Barranquero' , 4718@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 06:47:25 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 1Mxvlk-00009B-RH for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 06:47:25 +0200 Original-Received: from localhost ([127.0.0.1]:42673 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxvlk-0007Kw-FG for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 00:47:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mxvlf-0007Jr-Ci for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 00:47:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mxvla-0007Ib-1n for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 00:47:18 -0400 Original-Received: from [199.232.76.173] (port=50294 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxvlZ-0007IS-Sm for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 00:47:13 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:42362) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MxvlZ-0002rk-4z for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 00: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 n9E4lAaJ021410; Tue, 13 Oct 2009 21:47:11 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9E4U4uA018618; Tue, 13 Oct 2009 21:30:04 -0700 Resent-Date: Tue, 13 Oct 2009 21:30:04 -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 04:30:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4718 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4718-submit@emacsbugs.donarmstrong.com id=B4718.125549430317826 (code B ref 4718); Wed, 14 Oct 2009 04:30:04 +0000 Original-Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 04:25:03 +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 n9E4P1Z7017779 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 21:25:02 -0700 Original-Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9E4QA5J021913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 04:26:11 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9DJRl8i032520; Wed, 14 Oct 2009 04:24:49 GMT Original-Received: from abhmt003.oracle.com by acsmt356.oracle.com with ESMTP id 20389924351255494245; Tue, 13 Oct 2009 21:24:05 -0700 Original-Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 21:24:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpMfAb3dmJjsYx5T4m9GORPcJ90XwAA4vsw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4AD55295.0004:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 14 Oct 2009 00: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:31906 Archived-At: > emacs22 -Q > C-h f dolis RET > > will happily descrie the `dolist' function. So, no, this is > no strictly new behavior in this respect. I already said the same thing: >> Emacs has always allowed you, in some contexts (but >> not in others), to hit RET to both complete and enter >> the completed text. But that becomes less appropriate >> when the completion is not obvious from the input text >> (as is the case for partial completion). This change qualitatively alters what to expect from RET. Until now, you could pretty much be sure of what RET was going to give you - the only case for possible confusion was multiple names with the same prefix, and there you typically got some help from the `Complete but not unique' feedback. Now, you type `orange' and you find out afterward that you entered `apple'. Qualitatively, we're no longer in the same ballpark. > The partial completion in Emacs-23 does make it more likely > that completion will find some function rather than > return "no match". That's it. And for RET, especially, that can be quite confusing. With TAB, you see what you will get, at least. > If someone wants to make this function > use a `ask' for `require-match', as is done in M-x, I won't > object, tho I do not think it's a big deal. I hope someone will. I don't have the time now. It should have been done when we introduced `completion-styles' and partial completion as the default behavior. But we should not impose a regimental `ask' for this in general. The problem does not exist for prefix completion. We should show you the sole completion and ask for confirmation only when it does not correspond to prefix completion. Non-basic completion is the only case where there is really an element of surprise, confusion, and lack of understanding. > For what it's worth I have a local patch that indirectly changes this > behavior: it accepts any function name (even non-existing ones), > requires confirmation for non-existing ones, and then tries to guess > which file to load to find the function. The problem is not non-existing functions. In that case, the current code would still say `No match'. The problem is (a) treating additional patterns as matches when combined with (b) RET. As I said, with TAB it's one thing. With RET, you don't even get a chance to see what the completion is (until you see the *Help* buffer, and then you're unlikely to double-check the function name). I don't even think this is specific to `C-h f'. We should probably do the same thing most of the time: make RET confirm when the completion is not an obvious one (i.e. a suffix).