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 18:49:30 -0700 Message-ID: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> References: 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 1255486058 7598 80.91.229.12 (14 Oct 2009 02:07:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2009 02:07:38 +0000 (UTC) Cc: 4718@emacsbugs.donarmstrong.com To: "'Juanma Barranquero'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 14 04:07:27 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 1MxtGx-0006Sk-3B for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 04:07:27 +0200 Original-Received: from localhost ([127.0.0.1]:45362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxtGv-0005G2-Pv for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Oct 2009 22:07:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MxtGp-0005F2-SP for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 22:07:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxtGj-0005DM-TQ for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 22:07:18 -0400 Original-Received: from [199.232.76.173] (port=57702 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxtGj-0005DJ-KF for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 22:07:13 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:43649) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MxtGj-0006c5-06 for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 22:07: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 n9E27A71029012; Tue, 13 Oct 2009 19:07:11 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9E1t8Qp026627; Tue, 13 Oct 2009 18:55:08 -0700 Resent-Date: Tue, 13 Oct 2009 18:55:08 -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 01:55:08 +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.125548499725671 (code B ref 4718); Wed, 14 Oct 2009 01:55:08 +0000 Original-Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 01:49:57 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E1nuaO025665 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 18:49:57 -0700 Original-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 n9E1niQ3012964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 01:49:46 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 n9E1nl6m014900; Wed, 14 Oct 2009 01:49:48 GMT Original-Received: from abhmt003.oracle.com by acsmt358.oracle.com with ESMTP id 20387474901255484967; Tue, 13 Oct 2009 20:49:27 -0500 Original-Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 18:49:27 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpMZUQDmsckkRV8QRauK8bYge1yGAAANGhw 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.0A090203.4AD52E3B.0063: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 22:07: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:31896 Archived-At: > > emacs -Q > > C-h f dired-byte-compile RET > > M-x load-library dired > C-h f dired-byte => dired-do-byte-compile > => description for `dired-do-byte-compile', as expected. I didn't hit TAB. I hit RET: M-x load-library RET dired RET C-h f dired-byte-compile RET => description for `dired-do-byte-compile', NOT as expected. I entered one entire function name. Emacs didn't complain that there was no such function. Emacs instead silently gave me the doc for a different function. That's totally inappropriate. When I hit RET, Emacs should say `No match' and not accept my erroneous input, as it used to do in Emacs 22 and before. If there is no function whose name is `dired-byte-compile', then when I try to enter that name Emacs should tell me that immediately: no such function. In no case should Emacs go off and come back with the doc for some other function - and without even showing me that other function's name first! That's ridiculous. That is not user-friendly at all. Imagine if you paste a complete URL in your browser and you get a totally different Web site from what you request, the browser thinking that it is being helpful because it notices some similarity between your URL and another that it knew about. Can you imagine your Web experience in that case? Imagine if your browser does that each time you click a broken link: "helpfully" transforming the bad URL into a different one that "works" - but that corresponds to an unrelated Web site. The idea is not to maximize your chances of getting to some Web site, any old Web site. What you want is to be told that the URL is bad: `No such site'. Entering a complete URL is very different from (1) typing part of a URL, (2) asking the browser to help you find a relevant complete URL, and then (3) hitting RET to show your agreement with its proposal. It's also different if your browser first tells you that a complete URL you entered is bad and then asks if you want it to try to guess another URL. In that case (a) you are told there is no match and (b) you decide whether you want to go off on a wild goose chase. You are in control in that case, not the browser. I mention the browser analogy because everyone can relate to it. Its UI is straightforward and commonsensical. What we're doing in Emacs now is not. When you hit RET, you are telling Emacs, a browser, whatever: "This is what I want. If you don't have that, then just say so." 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). It's particularly problematic if the user's intention is that what s?he entered be considered already complete. And we cannot know that intention for sure; we can only suppose it because s?he chose to use RET, not TAB. `C-h f' should either (a) forego `completion-styles' and use basic (prefix) completion or (b) require confirmation when prefix completion fails and it moves on to more exotic attempts to find something that matches. [It is also unfriendly to users for Emacs TAB to perform such partial completion by default, but TAB is a different story from RET. The mystery and unexpectedness of the TAB behavior has already been documented as several other bugs, and will no doubt continue to cause unwitting users to file bugs. I got a mail from a user just yesterday who said with annoyance after discovering what was happening, "suddenly you get lots of completion results which seemingly no connection to what you've been typing". Indeed you do, indeed you do.]