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 23:25:14 -0700 Message-ID: <4F3D7E0BFD9747CD94D475D5A379825C@us.oracle.com> References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> <17D6900FABD34CCD8C893168EDC15E3F@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 1255503054 10535 80.91.229.12 (14 Oct 2009 06:50:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2009 06:50:54 +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 08:50:43 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 1Mxxh3-0001Ys-Hc for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 08:50:42 +0200 Original-Received: from localhost ([127.0.0.1]:43691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxxh3-0001mO-1O for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 02:50:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mxxgt-0001j5-DW for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 02:50:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mxxgo-0001ge-HY for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 02:50:31 -0400 Original-Received: from [199.232.76.173] (port=50037 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxxgo-0001gY-5X for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 02:50:26 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:3484) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mxxgm-0004bC-PL for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 02:50:25 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mxxgl-0006gE-Uu for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 02:50:24 -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 n9E6lARx006928; Tue, 13 Oct 2009 23:47:11 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9E6Z4qo004970; Tue, 13 Oct 2009 23:35:04 -0700 Resent-Date: Tue, 13 Oct 2009 23:35: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 06:35: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.12555015644093 (code B ref 4718); Wed, 14 Oct 2009 06:35:04 +0000 Original-Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 06:26:04 +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 n9E6Q26f004089 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 23:26:03 -0700 Original-Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9E6Pqxn023090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 06:25:53 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9E3toXc009676; Wed, 14 Oct 2009 06:26:29 GMT Original-Received: from abhmt007.oracle.com by acsmt357.oracle.com with ESMTP id 20391971431255501511; Wed, 14 Oct 2009 01:25:11 -0500 Original-Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 23:25:10 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpMigqREr4CCEH3S5KT00VNUbTwnwACTDag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4AD56EF2.01DF:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Resent-Date: Wed, 14 Oct 2009 02:50:30 -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:31913 Archived-At: > > 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. > > But there's not necessarily just one completion. I said, "When there is only one such completion." That's the case in question in this bug report. There is little problem when there are multiple completions - you see them, even for partial-completion. There is far less confusion with prefix completion, but there is no great problem even for partial-completion when there are multiple completions. For prefix completion, all of the completions have the same longest common prefix, which is what you see. Especially with longer input, the guess wrt the completions is a narrow gap; it is nothing like the case for partial completion, where the possible completions are all over the map. But even for partial completion, there is little problem when there are multiple completions. You can see them, even if you hit RET. The problem is when there is only one completion and you hit RET. For prefix completion, you can pretty much guess what the completion is, especially for long input. For partial completion you have no idea. > > 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. > > It is not unreasonable, of course. But neither it is unreasonable the > opposite: to understand RET as, "if there's only one completion, give > me that". I think it's useful. But you don't know what that one completion is. That is the problem. You haven't got a clue. So when you say "give me that one", you don't know what one it is that you're committing to. With prefix completion, there is really no comparison wrt the amount of knowledge you have about what you're accepting - you generally know what you will get. So yes, RET's completing behavior can be useful - with prefix completion. With a mix of completion styles, however, it's like playing darts in the dark. It is precisely the fact that it is useful with prefix completion that I do not want to see us simply institute a confirmation policy for RET in a blanket way. That is why I suggested that RET confirmation is called for only when the sole completion does not have the user's text as a prefix. IOW, only for the "surprising" partial-completion case. And again, the problem I'm reporting is particularly wrt a sole completion. > > That's one solution I see: not ask for confirmation except > > when the completion does not have the input as a prefix. > > That seems reasonable, though surely there's people who will feel as > strongly about it as you feel about the current default behavior :-) Well, there are always people who feel differently about everything in Emacs. We have options when there are important differences in approach for users. By default at least, Emacs users should not have to guess what's happening or feel inadequate and at a loss because they don't understand what's going on - why they get the results they get. Users should feel like they control Emacs. They shouldn't be uncomfortably surprised or wondering WTF. The new completion behavior is a WTF? behavior in many respects. The default behavior should be tamed to be less surprising. Anyone who comes to feel comfortable with getting an unknown, or who particularly likes playing darts in the dark, can choose another value for the option that would control this.