From drew.adams@oracle.com Tue Oct 13 16:51:33 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 13 Oct 2009 23:51:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9DNpWoq008306 for ; Tue, 13 Oct 2009 16:51:33 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mxr9P-0007WP-PW for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 19:51:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mxr9L-0007VX-BV for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 19:51:31 -0400 Received: from [199.232.76.173] (port=50034 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mxr9L-0007VU-2q for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 19:51:27 -0400 Received: from acsinet11.oracle.com ([141.146.126.233]:22157) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mxr9K-0004Tm-Ge for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2009 19:51:26 -0400 Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9DNpfn5017770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Oct 2009 23:51:42 GMT 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 n9DMYGrw015068 for ; Tue, 13 Oct 2009 23:51:55 GMT Received: from abhmt008.oracle.com by acsmt358.oracle.com with ESMTP id 20387137181255477775; Tue, 13 Oct 2009 18:49:35 -0500 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 16:49:34 -0700 From: "Drew Adams" To: Subject: 23.1; C-h f gives doc for the wrong function Date: Tue, 13 Oct 2009 16:49:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpMX9J3fG/2Bj00Sje8Orgs7wtOLA== 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.0A090202.4AD51279.017A:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) emacs -Q C-h f dired-byte-compile RET The doc for a different function, `dired-do-byte-compile', is shown instead. Similarly, for other functions that do not have doc strings. E.g., it shows the doc for `dired-compress-file' when you ask for `dired-compress'. This is silly. It was far better in Emacs 22 (21, 20, 19, 18,...), where Emacs told you clearly that there was no doc for the function requested. It is too easy not to notice that Emacs is in fact giving you the wrong thing - something different from what you requested. You assume that Emacs DTRT and that what you see is the doc you requested. Instead, you now need to pay close attention and double-check the function name at the top of the *Help* buffer. This makes life harder for users, not easier. If a user asks about oranges, it's inappropriate to tell him/her about apples, especially without even saying anything (We know nothing about oranges, would you like to know about apples instead?). This is a serious UI bug. In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-29 on SOFT-MJASON Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4)' From lekktu@gmail.com Tue Oct 13 17:28:39 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 00:28:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9E0ScZs014171 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 17:28:39 -0700 Received: by fxm3 with SMTP id 3so9306990fxm.44 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 17:28:32 -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=vEwMq8l/4h8h8OOOBQvU8P+MPQ9IjKrY2iHEAwihALs=; b=ewP3t+h5IGAcCf3sJv/eS25D7JS2NKICu9u8OIov1fAKXswx+2M26OJAT/Fq6sTms7 i6Lu4F/as0XFcO9boS3DapnoLgdXhcuPfNmRRJ0vG58BFAjzAUmkgu9Kl+jpZi/vc1KI eWDJoNAQgjI8XVvo5C+fdr3tFd+2Mc4nv623w= 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=KoC8v/2XYOQmDEWUefWIrhL+p1Xezb78a8pLc3nVMj4O/yCxnvrFLdvCy85j11tysP EwOoaP/C4cgp6dkVANGM4r6XNbC2AZGgKTAYT5wJNFuA6ZKNGtH1lUhJHSd4NYQJd3YW brECXvqojBJ8o2189LWN8JV33YFeZ6kEsFqDk= MIME-Version: 1.0 Received: by 10.239.181.167 with SMTP id m39mr548894hbg.169.1255480112134; Tue, 13 Oct 2009 17:28:32 -0700 (PDT) In-Reply-To: References: From: Juanma Barranquero Date: Wed, 14 Oct 2009 02:28:12 +0200 Message-ID: Subject: Re: bug#4718: 23.1; C-h f gives doc for the wrong function To: Drew Adams Cc: 4718@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 On Wed, Oct 14, 2009 at 01:49, Drew Adams wrote: > emacs -Q > > C-h f dired-byte-compile RET emacs -Q C-h f dired-byte-compile => [No match] M-x load-library dired C-h f dired-byte => dired-do-byte-compile => description for `dired-do-byte-compile', as expected. M-x load-library dired-aux C-h f dired-byte => dired-byte-compile => description for `dired-byte-compile', as expected. The difference being that `dired-do-byte-compile' is autoloaded, and `dired-byte-compile' is not. Which behavior were you expecting? Juanma From drew.adams@oracle.com Tue Oct 13 18:49:57 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 01:49:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.8 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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 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 Received: from abhmt003.oracle.com by acsmt358.oracle.com with ESMTP id 20387474901255484967; Tue, 13 Oct 2009 20:49:27 -0500 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 18:49:27 -0700 From: "Drew Adams" To: "'Juanma Barranquero'" Cc: <4718@debbugs.gnu.org> References: Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > > 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.] From monnier@iro.umontreal.ca Tue Oct 13 20:11:32 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 03:11:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.7 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E3BUif007080 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 20:11:32 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEACLe1EpMCqsb/2dsb2JhbACBUdc2hC0EgVuGDw X-IronPort-AV: E=Sophos;i="4.44,555,1249272000"; d="scan'208";a="47523989" Received: from 76-10-171-27.dsl.teksavvy.com (HELO ceviche.home) ([76.10.171.27]) by ironport2-out.pppoe.ca with ESMTP; 13 Oct 2009 23:11:25 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 417E5B40B9; Tue, 13 Oct 2009 23:11:25 -0400 (EDT) From: Stefan Monnier To: Drew Adams Cc: 4718@debbugs.gnu.org, "'Juanma Barranquero'" Subject: Re: bug#4718: 23.1; C-h f gives doc for the wrong function Message-ID: References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> Date: Tue, 13 Oct 2009 23:11:25 -0400 In-Reply-To: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> (Drew Adams's message of "Tue, 13 Oct 2009 18:49:30 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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. emacs22 -Q C-h f dolis RET will happily descrie the `dolist' function. So, no, this is no strictly new behavior in this respect. The partial completion in Emacs-23 does make it more likely that completion will find some function rather than return "no match". If someone wants to make this function use a `ask' for `require-match', as is done in M-x, I won't object, tho I do not think it's a big deal. 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. Stefan From lekktu@gmail.com Tue Oct 13 20:32:46 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 03:32:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n9E3WjVx010286 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 20:32:46 -0700 Received: by fxm3 with SMTP id 3so9432754fxm.44 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 20:32:39 -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=rFoElv3PAEk1d4y8jYr3urYCC63Fis8OC307MdFwARc=; b=u33EzkRLyx80HgOsiGrSK6lNn6+ueARUH/SPS4FEpnNF/H9fXT+freagBH5nh1C4Ad 4rFw92SilyBh+k2k4crN1XLWenStPG6iOhLoqZdnf0QgP12hmfPw2y3+f8CDu3xRSPxg aNvHAvOD11ulDUjov4IKql7yqgxEBXl9e1eg0= 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=coRkq19JvCv9wU+2ax3xKkbdIbI7vrd7S8yNtaxoE/T1uentchVd00V/E4fQCJyRE8 QB/amG1a4ufgjcvKwzOyah6EVbQy4dFBIdrw9BaYPmkTsS25lb1BUfP7bXiI8WVDjEiK tsAKaVCkW85mm3SB5YRRkvxPwayWdbTuz+aVg= MIME-Version: 1.0 Received: by 10.239.182.158 with SMTP id q30mr594507hbg.23.1255491159148; Tue, 13 Oct 2009 20:32:39 -0700 (PDT) In-Reply-To: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> From: Juanma Barranquero Date: Wed, 14 Oct 2009 05:32:19 +0200 Message-ID: Subject: Re: bug#4718: 23.1; C-h f gives doc for the wrong function To: Drew Adams Cc: 4718@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 On Wed, Oct 14, 2009 at 03:49, Drew Adams wrote: > I entered one entire function name. Emacs didn't complain that there was no such > function. In your example, you didn't even load dired, so I was trying to understand what you did. > 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. Stefan already has answered that: emacs 22 did in some cases, too. > 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. Irrelevant. URL completion in most browsers is not similar to Emacs completion. > 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. Navigating to an unexpected URL could have security implications; not so for symbol completion (at least, in most cases). > 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. You're saying that you would rather it didn't work for `dolis' either, then. You prefer to be asked. Fine. Personally, I kinda like the way it works now. Certainly does not strike me as user-unfriendly. Juanma From drew.adams@oracle.com Tue Oct 13 21:25:02 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 04:25:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9E4P1Z7017779 for <4718@emacsbugs.donarmstrong.com>; Tue, 13 Oct 2009 21:25:02 -0700 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9E4QA5J021913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 04:26:11 GMT 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 n9DJRl8i032520; Wed, 14 Oct 2009 04:24:49 GMT Received: from abhmt003.oracle.com by acsmt356.oracle.com with ESMTP id 20389924351255494245; Tue, 13 Oct 2009 21:24:05 -0700 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 21:24:04 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4718@debbugs.gnu.org>, "'Juanma Barranquero'" References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> Subject: RE: bug#4718: 23.1; C-h f gives doc for the wrong function Date: Tue, 13 Oct 2009 21:24:08 -0700 Message-ID: <662D8A34F24B4D73ABAD8A7BE21766CC@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpMfAb3dmJjsYx5T4m9GORPcJ90XwAA4vsw 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.0A090201.4AD55295.0004:SCFMA4539814,ss=1,fgs=0 > emacs22 -Q > C-h f dolis RET > > will happily descrie the `dolist' function. So, no, this is > no strictly new behavior in this respect. I already said the same thing: >> 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). This change qualitatively alters what to expect from RET. Until now, you could pretty much be sure of what RET was going to give you - the only case for possible confusion was multiple names with the same prefix, and there you typically got some help from the `Complete but not unique' feedback. Now, you type `orange' and you find out afterward that you entered `apple'. Qualitatively, we're no longer in the same ballpark. > The partial completion in Emacs-23 does make it more likely > that completion will find some function rather than > return "no match". That's it. And for RET, especially, that can be quite confusing. With TAB, you see what you will get, at least. > If someone wants to make this function > use a `ask' for `require-match', as is done in M-x, I won't > object, tho I do not think it's a big deal. I hope someone will. I don't have the time now. It should have been done when we introduced `completion-styles' and partial completion as the default behavior. 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. > 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. As I said, with TAB it's one thing. With RET, you don't even get a chance to see what the completion is (until you see the *Help* buffer, and then you're unlikely to double-check the function name). I don't even think this is specific to `C-h f'. We should probably do the same thing most of the time: make RET confirm when the completion is not an obvious one (i.e. a suffix). From drew.adams@oracle.com Tue Oct 13 21:25:04 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 04:25:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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 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 Received: from abhmt003.oracle.com by acsmt356.oracle.com with ESMTP id 20388918791255494248; Tue, 13 Oct 2009 21:24:08 -0700 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 21:24:07 -0700 From: "Drew Adams" To: "'Juanma Barranquero'" Cc: <4718@debbugs.gnu.org> References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > 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. From lekktu@gmail.com Tue Oct 13 21:51:53 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 04:51:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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= MIME-Version: 1.0 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> References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> <17D6900FABD34CCD8C893168EDC15E3F@us.oracle.com> From: Juanma Barranquero Date: Wed, 14 Oct 2009 06:51:26 +0200 Message-ID: Subject: Re: bug#4718: 23.1; C-h f gives doc for the wrong function To: Drew Adams Cc: 4718@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 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 From drew.adams@oracle.com Tue Oct 13 23:26:04 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 06:26:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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 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 Received: from abhmt007.oracle.com by acsmt357.oracle.com with ESMTP id 20391971431255501511; Wed, 14 Oct 2009 01:25:11 -0500 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Oct 2009 23:25:10 -0700 From: "Drew Adams" To: "'Juanma Barranquero'" Cc: <4718@debbugs.gnu.org> References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> <17D6900FABD34CCD8C893168EDC15E3F@us.oracle.com> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > > 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. From monnier@iro.umontreal.ca Wed Oct 14 06:32:05 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 13:32:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.6 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.183]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9EDW4H1001569 for <4718@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 06:32:05 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAK9v1UpMCqsb/2dsb2JhbACBUddnhC4Eh3U X-IronPort-AV: E=Sophos;i="4.44,557,1249272000"; d="scan'208";a="47537883" Received: from 76-10-171-27.dsl.teksavvy.com (HELO pastel.home) ([76.10.171.27]) by ironport2-out.pppoe.ca with ESMTP; 14 Oct 2009 09:31:58 -0400 Received: by pastel.home (Postfix, from userid 20848) id 228057F5B; Wed, 14 Oct 2009 09:31:58 -0400 (EDT) From: Stefan Monnier To: Drew Adams Cc: 4718@debbugs.gnu.org, "'Juanma Barranquero'" Subject: Re: bug#4718: 23.1; C-h f gives doc for the wrong function Message-ID: References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> <17D6900FABD34CCD8C893168EDC15E3F@us.oracle.com> <4F3D7E0BFD9747CD94D475D5A379825C@us.oracle.com> Date: Wed, 14 Oct 2009 09:31:58 -0400 In-Reply-To: <4F3D7E0BFD9747CD94D475D5A379825C@us.oracle.com> (Drew Adams's message of "Tue, 13 Oct 2009 23:25:14 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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. [ I'm not sure what/why we're still discussing, but anyway.. ] BTW, you may want to try icomplete-mode. Stefan From monnier@iro.umontreal.ca Wed Oct 14 06:40:58 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 13:40:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.6 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9EDeuon002979 for <4718@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 06:40:57 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAAdy1UpMCqsb/2dsb2JhbACBUddchC4Eh3U X-IronPort-AV: E=Sophos;i="4.44,557,1249272000"; d="scan'208";a="47538431" Received: from 76-10-171-27.dsl.teksavvy.com (HELO pastel.home) ([76.10.171.27]) by ironport2-out.pppoe.ca with ESMTP; 14 Oct 2009 09:40:51 -0400 Received: by pastel.home (Postfix, from userid 20848) id E67F87F5B; Wed, 14 Oct 2009 09:40:50 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: <4718@debbugs.gnu.org>, "'Juanma Barranquero'" Subject: Re: bug#4718: 23.1; C-h f gives doc for the wrong function Message-ID: References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> <662D8A34F24B4D73ABAD8A7BE21766CC@us.oracle.com> Date: Wed, 14 Oct 2009 09:40:50 -0400 In-Reply-To: <662D8A34F24B4D73ABAD8A7BE21766CC@us.oracle.com> (Drew Adams's message of "Tue, 13 Oct 2009 21:24:08 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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. 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. >> 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 don't even think this is specific to `C-h f'. We should probably do > the same thing most of the time: make RET confirm when the completion > is not an obvious one (i.e. a suffix). That's almost already the case: it's fairly rare for Emacs completion to use this kind of strong `require-match'. Stefan From drew.adams@oracle.com Wed Oct 14 08:50:54 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 15:50:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.9 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9EForGi022223 for <4718@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 08:50:54 -0700 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9EFpxB2016171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Oct 2009 15:52:02 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9E9wPug023324; Wed, 14 Oct 2009 15:51:39 GMT Received: from abhmt021.oracle.com by acsmt358.oracle.com with ESMTP id 20399858881255535429; Wed, 14 Oct 2009 10:50:29 -0500 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Oct 2009 08:50:27 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4718@debbugs.gnu.org>, "'Juanma Barranquero'" References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com><17D6900FABD34CCD8C893168EDC15E3F@us.oracle.com><4F3D7E0BFD9747CD94D475D5A379825C@us.oracle.com> Subject: RE: bug#4718: 23.1; C-h f gives doc for the wrong function Date: Wed, 14 Oct 2009 08:50:30 -0700 Message-ID: <4F504510FC89423BB343D391BF94DC0B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcpM0rb3EJ0eJ/nhQj6psyTfv3ExVwAEMWpQ 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.4AD5F351.019A:SCFMA4539814,ss=1,fgs=0 > > 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. > > BTW, you may want to try icomplete-mode. I do use icomplete-mode. Always have. I report the problem on behalf of Emacs and Emacs users, not especially on my behalf as a particular user. What I use personally is not very relevant. What I use wrt completion is in fact very different from vanilla Emacs, in any case. From drew.adams@oracle.com Wed Oct 14 09:00:01 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 14 Oct 2009 16:00:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 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 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 Received: from abhmt002.oracle.com by acsmt356.oracle.com with ESMTP id 20399883581255535983; Wed, 14 Oct 2009 08:59:43 -0700 Received: from dradamslap1 (/141.144.232.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Oct 2009 08:59:43 -0700 From: "Drew Adams" To: "'Stefan Monnier'" Cc: <4718@debbugs.gnu.org>, "'Juanma Barranquero'" References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com><662D8A34F24B4D73ABAD8A7BE21766CC@us.oracle.com> Subject: RE: bug#4718: 23.1; C-h f gives doc for the wrong function Date: Wed, 14 Oct 2009 08:59:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > > 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). From monnier@iro.umontreal.ca Wed Oct 14 20:14:09 2009 Received: (at 4718) by emacsbugs.donarmstrong.com; 15 Oct 2009 03:14:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.6 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.pppoe.ca (ironport2-out.teksavvy.com [206.248.154.181]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9F3E8cV029792 for <4718@emacsbugs.donarmstrong.com>; Wed, 14 Oct 2009 20:14:09 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEAN8v1kpMCqsb/2dsb2JhbACBUdgChC4Eh3U X-IronPort-AV: E=Sophos;i="4.44,563,1249272000"; d="scan'208";a="47597288" Received: from 76-10-171-27.dsl.teksavvy.com (HELO ceviche.home) ([76.10.171.27]) by ironport2-out.pppoe.ca with ESMTP; 14 Oct 2009 23:14:02 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 49E7EB4100; Wed, 14 Oct 2009 23:14:02 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Cc: <4718@debbugs.gnu.org>, "'Juanma Barranquero'" Subject: Re: bug#4718: 23.1; C-h f gives doc for the wrong function Message-ID: References: <4A14BB04EC704AE8AC77727C8363945A@us.oracle.com> <662D8A34F24B4D73ABAD8A7BE21766CC@us.oracle.com> Date: Wed, 14 Oct 2009 23:14:02 -0400 In-Reply-To: (Drew Adams's message of "Wed, 14 Oct 2009 08:59:47 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> 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. I understood what you said, but as written above I disagree: the same "confusing" behavior can happen at times with the old code. It's just a lot less frequent. So it's a question of frequency rather than a qualitative difference. >> 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. Obviously not, I have no idea why you take the idea that I think you said so. Stefan From cyd@stupidchicken.com Sat Oct 24 11:45:36 2009 Received: (at control) by emacsbugs.donarmstrong.com; 24 Oct 2009 18:45:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.4 required=4.0 tests=AWL,VALID_BTS_CONTROL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pantheon-po39.its.yale.edu (pantheon-po39.its.yale.edu [130.132.50.100]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9OIjYIc023221 for ; Sat, 24 Oct 2009 11:45:35 -0700 Received: from furry (dhcp128036014244.central.yale.edu [128.36.14.244]) (authenticated bits=0) by pantheon-po39.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id n9OIjT5G017847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 24 Oct 2009 14:45:29 -0400 Received: by furry (Postfix, from userid 1000) id 49ACCC070; Sat, 24 Oct 2009 14:45:28 -0400 (EDT) From: Chong Yidong To: control@debbugs.gnu.org Subject: tags 4718 + wontfix Date: Sat, 24 Oct 2009 14:45:28 -0400 Message-ID: <873a58fx6f.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) tags 4718 + wontfix thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 11 00:47:17 2011 Received: (at control) by debbugs.gnu.org; 11 Sep 2011 04:47:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2bwr-00087S-0x for submit@debbugs.gnu.org; Sun, 11 Sep 2011 00:47:17 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2bwp-00087L-50 for control@debbugs.gnu.org; Sun, 11 Sep 2011 00:47:15 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R2bsd-0001ZI-NU for control@debbugs.gnu.org; Sun, 11 Sep 2011 06:42:55 +0200 Date: Sun, 11 Sep 2011 06:39:55 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #4718 X-MailScanner-ID: 1R2bsd-0001ZI-NU X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1316320976.0237@Qm+dAzMtlOOzFJCkicbd9g X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) close 4718 From unknown Fri Aug 15 15:32:58 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 09 Oct 2011 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator