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:12 -0700 Message-ID: <17D6900FABD34CCD8C893168EDC15E3F@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 1255495672 26832 80.91.229.12 (14 Oct 2009 04:47:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2009 04:47:52 +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 06:47:41 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 1Mxvlz-0000Tt-R1 for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 06:47:41 +0200 Original-Received: from localhost ([127.0.0.1]:45908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxvlz-0007VD-AR for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 00:47:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mxvlf-0007Jo-9w 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 1MxvlZ-0007IU-T1 for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 00:47:18 -0400 Original-Received: from [199.232.76.173] (port=50293 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxvlZ-0007IQ-Pw for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 00:47:13 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:42360) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MxvlZ-0002rg-2g 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 n9E4lAaH021410; 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 n9E4U71D018733; Tue, 13 Oct 2009 21:30:07 -0700 Resent-Date: Tue, 13 Oct 2009 21:30: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 04:30:07 +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.125549430517852 (code B ref 4718); Wed, 14 Oct 2009 04:30:07 +0000 Original-Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 04:25:05 +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 n9E4P22U017780 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 21:25:03 -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 n9E4PDwO010499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 04:25:15 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 n9DMukjK015116; Wed, 14 Oct 2009 04:24:54 GMT Original-Received: from abhmt003.oracle.com by acsmt356.oracle.com with ESMTP id 20388918791255494248; Tue, 13 Oct 2009 21:24:08 -0700 Original-Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 21:24:07 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpMfvyKKQxhlA2hQMOQDN20Pqbv8wAAoUhw 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.0A090206.4AD55295.019F: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:31907 Archived-At: > You're saying that you would rather it didn't work for `dolis' > either, then. No, I'm not saying that. I have no problem with the behavior of Emacs 22 and before. Letting RET complete using prefix completion is not problematic in the way that letting it do so with partial completion is. With only prefix completion, `dolis RET' can only complete to something that has `dolis' as a prefix. When there is only one such completion, it is not very hard to guess what that is. That is, with prefix completion the gap between what is known (the input) and what is unknown (the completion) is small and predictable. If you choose to hit RET, it's because you pretty much know what you're going to get. That's especially true, the longer the input. In the case I gave, `dired-byte-compile', the input is already quite long for a function name. That means both (a) it is unlikely that the sole completion would be much longer and therefore hard to guess and (b) it is not unreasonable for both the program and the user to consider the input as pretty much the whole function name. IOW, RET, with the meaning "this is what I want" fits well here. RET in that sense does not fit well with partial completion, where your input could complete to pretty much anything. You have very little knowledge of what the completions are. We've already seen bizarre examples of typing one thing and getting something totally unforeseen as a result. I don't think anyone denies that. The point is that that unknown is more or less controllable by users when TAB is involved. They see the result before entering it or cancelling. RET is another story altogether. You cannot have a good idea what will happen when you push that big red button. I suppose the end result will be that users will eventually learn to hit TAB RET systematically instead of RET. I would rather see the program make them jump through such a hoop (confirm) only when it's really needed. That is, only when using partial completion, since prefix completion has never posed a problem in this regard. That's one solution I see: not ask for confirmation except when the completion does not have the input as a prefix. (By input, I mean modulo directory name, $ for env vars, etc.) IOW, treat the problem only where it is - there is no problem for the classic prefix completion.