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: Tue, 6 Jan 2009 14:36:32 -0800 Message-ID: <007301c9704f$3a550ef0$0200a8c0@us.oracle.com> References: <87r63gs1il.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 1231283024 11632 80.91.229.12 (6 Jan 2009 23:03:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Jan 2009 23:03:44 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: "'Juri Linkov'" , <1800@emacsbugs.donarmstrong.com>, Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 07 00:04:55 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 1LKKyg-0004Wq-4i for geb-bug-gnu-emacs@m.gmane.org; Wed, 07 Jan 2009 00:04:50 +0100 Original-Received: from localhost ([127.0.0.1]:56548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKKxQ-0006Kl-Sh for geb-bug-gnu-emacs@m.gmane.org; Tue, 06 Jan 2009 18:03:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKKxN-0006KS-OK for bug-gnu-emacs@gnu.org; Tue, 06 Jan 2009 18:03:29 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKKxL-0006Jy-2V for bug-gnu-emacs@gnu.org; Tue, 06 Jan 2009 18:03:29 -0500 Original-Received: from [199.232.76.173] (port=35830 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKKxK-0006Ju-Ur for bug-gnu-emacs@gnu.org; Tue, 06 Jan 2009 18:03:26 -0500 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:48227) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKKxK-0004dM-07 for bug-gnu-emacs@gnu.org; Tue, 06 Jan 2009 18:03:26 -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 n06N3Ouj006081; Tue, 6 Jan 2009 15:03:24 -0800 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id n06Mj474001438; Tue, 6 Jan 2009 14:45:04 -0800 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 06 Jan 2009 22:45:04 +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 1800-submit@emacsbugs.donarmstrong.com id=B1800.123128140032491 (code B ref 1800); Tue, 06 Jan 2009 22:45:04 +0000 Original-Received: (at 1800) by emacsbugs.donarmstrong.com; 6 Jan 2009 22:36:40 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id n06Mab80032485 for <1800@emacsbugs.donarmstrong.com>; Tue, 6 Jan 2009 14:36:38 -0800 Original-Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n06Mc0nA015865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Jan 2009 22:38:01 GMT Original-Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n06Mb2Vs015416; Tue, 6 Jan 2009 22:37:05 GMT Original-Received: from dradamslap1 (/141.144.88.99) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Jan 2009 22:36:24 +0000 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <87r63gs1il.fsf@jurta.org> Thread-Index: AclwNEl4SN53t1f5SFywv9+cF0RCBAAFp6ug 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.0A090208.4963DCEC.00BD:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Tue, 06 Jan 2009 18:03: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:23846 gmane.emacs.pretest.bugs:23641 Archived-At: > > The change to treat * as a wildcard is often a pain in the neck. > > Such changes should not be made without polling the users first. > > > > Please undo this change, poll the users, and redo the change > > if they generally want it. > > This is a nice feature, but I have the same problems with it. > Trying to switch to a killed buffer that had `*' at the beginning > of its name (e.g. *grep*) typing `* g TAB' displays a large list > of irrelevant buffer names. > > Regular expressions allow a backslash before `*' for a literal > character. So `\ * g TAB' could try completion literally > without interpreting `*' as a wildcard. But I think this would > be inconvenient. > > A better variant is to provide two-step completion. So when there is > no buffer matching `*g' literally then display a message like > [No match, type TAB again for * as a wildcard] I don't think we should start making special treatment here for buffer names. SM> Here's another option: only treat * as a wildcard if it doesn't match SM> anything existing. I.e. if you have buffers that start with "*", then SM> "*g" will not treat the * as a wildcard. To force the use of SM> a wildcard, we could let the user type "**g". And I don't think we should adopt the behavior that if there are no matches under some interpretation of the input then we should try another interpretation (and another,...). That's exactly the strategy behind the "annoyance". It can be useful to get feedback that your input doesn't match. To me, the thing to do is keep this new behavior as an optional feature, but not make it the default behavior. People who opt in for this will know what they're getting, and no one will be annoyed/surprised. In a future release, if people generally prefer the optional behavior, it could become the new default. It doesn't make sense to change the default behavior now to something that (a) not many users have even tried, (b) was never even discussed at emacs-devel, and (c) is hardly documented. (The novelty and sometime annoyance/surprise is the main disqualifier, of course, not the lack of adequate doc and discussion.)