From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.bugs Subject: bug#4718: 23.1; C-h f gives doc for the wrong function Date: Wed, 14 Oct 2009 06:51:26 +0200 Message-ID: References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> <17D6900FABD34CCD8C893168EDC15E3F@us.oracle.com> Reply-To: Juanma Barranquero , 4718@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1255496858 29224 80.91.229.12 (14 Oct 2009 05:07:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2009 05:07:38 +0000 (UTC) Cc: 4718@emacsbugs.donarmstrong.com To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 14 07: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 1Mxw57-0006mu-65 for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 07:07:25 +0200 Original-Received: from localhost ([127.0.0.1]:56888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxw56-00019v-53 for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2009 01:07:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mxw50-00019Q-FX for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 01:07:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mxw4v-00018y-Iv for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 01:07:17 -0400 Original-Received: from [199.232.76.173] (port=42730 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxw4v-00018v-EM for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 01:07:13 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:56690) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mxw4u-0005iI-Ry for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2009 01: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 n9E57A78024925; Tue, 13 Oct 2009 22:07:11 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9E504Pg022927; Tue, 13 Oct 2009 22:00:04 -0700 Resent-Date: Tue, 13 Oct 2009 22:00:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Juanma Barranquero Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Wed, 14 Oct 2009 05:00: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.125549591322133 (code B ref 4718); Wed, 14 Oct 2009 05:00:04 +0000 Original-Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 04:51:53 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail-fx0-f207.google.com (mail-fx0-f207.google.com [209.85.220.207]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E4ppsV022130 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 21:51:53 -0700 Original-Received: by fxm3 with SMTP id 3so9474072fxm.44 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 21:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=nkcMWj2wuid+O/2rFTWmNxsqFEiUXXQDpufhnK+K3Fw=; b=CzYj7c61moM9JarwmkaPdD2UHBfxaGlBYpMfUau4+mrNxUjpdpktIAL23xkO4q00v8 gmCZYGpeze6Xukop0bagawE+Uj53AjeAcPMN+71XyLOBk3qOhVyeQg4bT5YiPaoL9o6M 5shxe2/nlUXYxeVcAcZfmvLRtYFdfKEnC2N6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Gq8RnlUg2GgQV0iRjhw4owUQ7czg0HztzOqUol6UmvKcLJ2aUh8s4ES9iNIkH54YKm c0w/zlyo9rBzWXTjV1WaPyeMm/q1DZ8dHR+UFy00OLKyoqCp7KdDn8jURgl2DbDRE//E rdg+Q8iofglc8H13LAWzzLkuJ9SqE64RS88H4= Original-Received: by 10.239.182.158 with SMTP id q30mr599700hbg.23.1255495906182; Tue, 13 Oct 2009 21:51:46 -0700 (PDT) In-Reply-To: <17D6900FABD34CCD8C893168EDC15E3F@us.oracle.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 14 Oct 2009 01:07:17 -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:31908 Archived-At: On Wed, Oct 14, 2009 at 06:24, Drew Adams wrote: > No, I'm not saying that. I have no problem with the behavior of Emacs 22 and > before. Aha. Sorry for misrepresenting your point. > 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. If you have cl loaded, C-h f defu => defun but it could also be `defun*'. > 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. I don't think so, because is also a form of completion: C-h f buffer-face => "buffer-face-" => "Possible completions are:" > 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. > 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. It's a matter of tastes, I think. > 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 :-) Juanma