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: Wed, 14 Oct 2009 08:59:47 -0700 Message-ID: References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com><662D8A34F24B4D73ABAD8A7BE21766CC@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 1255537122 26657 80.91.229.12 (14 Oct 2009 16:18:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2009 16:18:42 +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 18:18:31 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 1My6YR-00079P-UX for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 18:18:25 +0200 Original-Received: from localhost ([127.0.0.1]:51760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1My6YR-0002MN-CH for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 12:18:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1My6Nk-0000Mq-Vn for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 12:07:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1My6Ng-0000FH-5m for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 12:07:20 -0400 Original-Received: from [199.232.76.173] (port=35667 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1My6Nf-0000Ey-OG for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 12:07:15 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:52200) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1My6Ne-00027L-VN for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 12:07:15 -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 n9EG7BIW025003; Wed, 14 Oct 2009 09:07:11 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9EG5GP1024290; Wed, 14 Oct 2009 09:05:16 -0700 Resent-Date: Wed, 14 Oct 2009 09:05:16 -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 16:05:15 +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.125553600223011 (code B ref 4718); Wed, 14 Oct 2009 16:05:15 +0000 Original-Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 16:00:02 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9EG00e5022966 for <4718@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 09:00:01 -0700 Original-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 n9EG0B5E017091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 16:00:13 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9EE8SLT011775; Wed, 14 Oct 2009 15:59:51 GMT Original-Received: from abhmt002.oracle.com by acsmt356.oracle.com with ESMTP id 20399883581255535983; Wed, 14 Oct 2009 08:59:43 -0700 Original-Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Oct 2009 08:59:43 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpM0/XaZEanga5rQR+sa4J2JB19hgAD8Y2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4AD5F577.0018: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 12:07:20 -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:31929 Archived-At: > > 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. > > I disagree, the same problem exists for prefix completion. Maybe it's > less frequent, but it exists nevertheless. As I said a couple of times, this difference in degree leads to a qualitative difference. It's not much of a problem for prefix completion, in practice - for the reasons I gave. > Which brings us to the reason why we don't currently ask: > choosing the wrong name is harmless because C-h f does not > perform any dangerous operation that might lose you some work. No one claimed that it will start a thermonuclear explosion. The point is that we make it harder, not easier, for users currently. A user now has to really pay attention and double-check the name of the function at the top of *Help*. This is error-prone and a time-waster for users. That extra burden on users isn't necessary. Does that really happen? Well, I reported it just as it happened to me. It took me a while in fact to realize that I was studying the doc (args etc.) for the wrong function - one that is similarly named. And Juanma was of course right that that happened to me in this case because I had loaded dired.el but not dired-aux.el (normally, I load them both from the get-go). It's a good example of what can happen and how Emacs now throws obstacles our way instead of making things easier. My expectation was that I was providing the complete name of an existing function. In Emacs 22, Emacs would have told me there was no such function, and I would have immediately realized that I had not loaded dired-aux.el. In Emacs 23, Emacs silently substituted another function, and I wasted time studying the wrong thing. Will this problem cause a nuclear meltdown? Probably not. > >> 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. > > Reread what I wrote: I said "indirectly". It's related not > for its functionality but because if we want to be able > to accept non-existing functions, then RET can't perform > completion any more. I'm not arguing that RET should not perform completion anymore. In fact, I stated that it should. What I proposed is that it not silently accept a completion, without confirmation, unless it has the user's text as a prefix (modulo directory, $, etc., as I said). IOW, for prefix completion RET's behavior is not a problem, in practice. Let's solve the real problem, and not generalize to "fix" something that isn't broken. The problem is RET substituting a completion that you would never have guessed and then accepting that, without ever showing it to you. It is only in such cases that it would be good for RET to stop, show you what it is about to accept, and let you confirm or cancel. Can we recognize such cases? Maybe not in fine-tuned way, never erring one way or the other. But simply deciding that prefix completion is OK for RET to do what it's always done, and any other completion is a priori not OK, would help a lot. Even in the case of non-prefix completion, we could test if the particular completion did in fact have the user text as a prefix (meaning that the result was a prefix completion, even if the method used was not basic completion), and if so treat it as prefix completion (no confirmation in a case such as C-h f).