From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Date: Wed, 7 Jan 2009 08:48:26 -0800 Message-ID: <000c01c970e7$c3bb2d30$c2b22382@us.oracle.com> References: <87r63gs1il.fsf@jurta.org><007301c9704f$3a550ef0$0200a8c0@us.oracle.com><87sknwkov4.fsf@jurta.org><001a01c97089$b6902420$0200a8c0@us.oracle.com><873afvz5du.fsf@jurta.org> <000901c970e0$799e6a20$0200a8c0@us.oracle.com> Reply-To: Drew Adams , 1800@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 1231348443 14620 80.91.229.12 (7 Jan 2009 17:14:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Jan 2009 17:14:03 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, rms@gnu.org To: <1800@emacsbugs.donarmstrong.com>, "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 07 18:15:14 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 1LKbzc-0007IO-SV for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jan 2009 18:14:57 +0100 Original-Received: from localhost ([127.0.0.1]:43687 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKbyM-0000Ul-3d for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jan 2009 12:13:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKboX-0004Fc-KB for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 12:03:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKboW-0004Ea-40 for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 12:03:28 -0500 Original-Received: from [199.232.76.173] (port=42990 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKboV-0004EM-D8 for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 12:03:27 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:59784) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKboU-0008MM-Ml for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 12:03:27 -0500 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n07H3Ok5018673; Wed, 7 Jan 2009 09:03:24 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n07Gt3TR016349; Wed, 7 Jan 2009 08:55:03 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Wed, 07 Jan 2009 16:55:03 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 1800 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by submit@emacsbugs.donarmstrong.com id=B.123134694015109 (code B ref -1); Wed, 07 Jan 2009 16:55:03 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 16:49:00 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n07GmqCd015100 for ; Wed, 7 Jan 2009 08:48:54 -0800 Original-Received: from mx10.gnu.org ([199.232.76.166]:45408) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKbZE-0005Cs-JQ for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 11:47:40 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKbaN-00072B-9e for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 11:48:52 -0500 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:28680 helo=rgminet11.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKbaK-00071s-Kl; Wed, 07 Jan 2009 11:48:48 -0500 Original-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 n07Go9od032134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jan 2009 16:50:10 GMT Original-Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n07GmSGR027808; Wed, 7 Jan 2009 16:48:30 GMT Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jan 2009 16:48:27 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000901c970e0$799e6a20$0200a8c0@us.oracle.com> Thread-Index: Aclwxq1LTXzd4qfwQPmaXfpyIEWGFAAFjmagAAJw3aA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4964DCDF.022D:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-CrossAssassin-Score: 2 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Wed, 07 Jan 2009 12:03:28 -0500 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:23879 gmane.emacs.pretest.bugs:23652 Archived-At: > > >> So implementing a message "[No match, type TAB again for * as > > >> a wildcard]" will keep the traditional behavior just as you want. > > > > > > No, there are plenty of other annoyances/surprises for > > > users in this new behavior, besides the `*' buffer one. > > > I gave two good examples in the report for > > > bug #1512, neither involving wildcards or necessarily buffers. > > > > > > http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1512 > > > > Asking for another TAB before doing partial completion will solve > > both your problems. > > That is not the case today. The inappropriate completions are > presented immediately - exactly like RMS's case (but without > wildcards). Are you referring to your suggestion that the > implementation not try partial completion until the > user confirms with a second TAB? > > That suggestion seemed to depend on the presence of wildcards > (e.g. the message). Are you saying now that the implementation > should _always_ require a second TAB before performing partial > completion, when basic completion fails? > > If so, wouldn't that conflict with the desire by someone who > really wants this new feature - someone who wants p.c. to > happen automatically and immediately whenever traditional > completion fails? Or would you add an option to indicate > whether such confirmation is required? Required in all cases > or just some (e.g. wildcards)? > > Rather than try, now, in a discussion with only two or three > people, to redesign this new feature on the fly to counter > some of the annoyances already encountered, why don't we just > keep it as it is for now, but not make partial > completion part of the _default_ behavior? > > Let people try it as something optional. They will likely > have good suggestions, > if need be, about how to counter, inhibit, or prevent some of > the annoyances - > when and how best to do that. They will have the benefit of > experience, and > experience with lots of different use cases (and potential > annoyances/surprises). > > Honestly, I think that, _especially_ if you want this new > feature to be accepted, it makes more sense to keep as an > option for now, and let people discover its value (via > some doc - still missing) and spread that news by word > of mouth, than it does to impose it as the new default > behavior. Doing the latter is likely to bring more > resistance and bug reports - we've already seen a > few. Doing the former is likely to attract people to it as > something new and cool. > > Imagine if Kim had decided, as soon as he wrote Ido, that it > should become the new default behavior for Emacs (had he > alone been in a position to decide). Just add this new > feature as an option. Time will tell whether it should > become the default behavior. One more thing to keep in mind - This is not (necessarily) about partial completion. The new feature is that a list of completion methods is used, in order, to try to complete user input. That list is the value of `completion-styles', which by default is `(basic partial-completion)'. Hence it doesn't make sense to hard-code any interaction that depends on partial completion. For example, what is a wildcard for partial completion might not be for some other completion method that is an element of `completion-styles'.