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 07:56:15 -0800 Message-ID: <000901c970e0$799e6a20$0200a8c0@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> 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 1231345428 2473 80.91.229.12 (7 Jan 2009 16:23:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Jan 2009 16:23:48 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, rms@gnu.org, 1800@emacsbugs.donarmstrong.com To: "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 07 17:24:57 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 1LKbDA-0002uj-5t for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jan 2009 17:24:52 +0100 Original-Received: from localhost ([127.0.0.1]:57295 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKbBu-0008SL-EF for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jan 2009 11:23:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKbBp-0008RJ-SI for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 11:23:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKbBp-0008Qr-77 for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 11:23:29 -0500 Original-Received: from [199.232.76.173] (port=56625 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKbBo-0008Qh-Re for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 11:23:28 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:48217) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKbBo-0004gO-5b for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 11:23:28 -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 n07GNOud009114; Wed, 7 Jan 2009 08:23:24 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n07G56cn004475; Wed, 7 Jan 2009 08:05:06 -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:05:05 +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.12313438952311 (code B ref -1); Wed, 07 Jan 2009 16:05:05 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 15:58:15 +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 n07Fw8ur002305 for ; Wed, 7 Jan 2009 07:58:09 -0800 Original-Received: from mail.gnu.org ([199.232.76.166]:43546 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKam7-0003og-P2 for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 10:56:55 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKanF-0001xd-O9 for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 10:58:07 -0500 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:16729) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKanD-0001qa-SM; Wed, 07 Jan 2009 10:58:04 -0500 Original-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 n07FtoBx001432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jan 2009 15:55:52 GMT Original-Received: from acsmt706.oracle.com (acsmt706.oracle.com [141.146.40.84]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n07FuGwK005799; Wed, 7 Jan 2009 15:56:18 GMT Original-Received: from dradamslap1 (/24.23.165.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jan 2009 15:56:16 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <873afvz5du.fsf@jurta.org> Thread-Index: Aclwxq1LTXzd4qfwQPmaXfpyIEWGFAAFjmag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt706.oracle.com [141.146.40.84] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020B.4964D0A2.01BE: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 11:23:29 -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:23877 gmane.emacs.pretest.bugs:23651 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.