From unknown Tue Jun 24 22:35:36 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#1800 <1800@debbugs.gnu.org> To: bug#1800 <1800@debbugs.gnu.org> Subject: Status: 23.0.60; Changed meaning of * in buffer name completion Reply-To: bug#1800 <1800@debbugs.gnu.org> Date: Wed, 25 Jun 2025 05:35:36 +0000 retitle 1800 23.0.60; Changed meaning of * in buffer name completion reassign 1800 emacs submitter 1800 rms@gnu.org severity 1800 normal thanks From rms@gnu.org Tue Jan 6 04:32:27 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 12:32:28 +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=0.1 required=4.0 tests=FOURLA autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 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 n06CWPjJ006295 for ; Tue, 6 Jan 2009 04:32:26 -0800 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LKB5W-0007uA-Hw; Tue, 06 Jan 2009 07:31:14 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard M Stallman To: emacs-pretest-bug@gnu.org Subject: 23.0.60; Changed meaning of * in buffer name completion Reply-to: rms@gnu.org Message-Id: Date: Tue, 06 Jan 2009 07:31:14 -0500 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. In GNU Emacs 23.0.60.16 (mipsel-unknown-linux-gnu, GTK+ Version 2.12.11) of 2009-01-03 on lemote-yeeloong configured using `configure 'CFLAGS=-O0 -g -Wno-pointer-sign' 'mipsel-unknown-linux-gnu' 'build_alias=mipsel-unknown-linux-gnu' 'host_alias=mipsel-unknown-linux-gnu' 'target_alias=mipsel-unknown-linux-gnu'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Mail Minor modes in effect: gpm-mouse-mode: t tooltip-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: R e a s o n SPC a s SPC a SPC c r i m e C-n C-n C-n C-n DEL C-x o ESC v C-x o I SPC w i s h SPC I SPC c o u d SPC DEL DEL l d SPC g o SPC t o SPC y o u r SPC t a l , SPC DEL DEL k , SPC b u t SPC s i n c e SPC I SPC a m SPC n t SPC DEL DEL o t SPC i n SPC C a l i r o f DEL DEL DEL f o r n i a , RET I SPC c a n ' t . ESC q SPC SPC H a v e SPC y o u SPC w r i t t e n SPC a b o u t SPC t h i s ? RET RET I SPC w o u d SPC DEL DEL ESC DEL c o u l d SPC t r y SPC t o SPC f i g u r e SPC o DEL i t SPC o u t SPC f o r m SPC DEL DEL SPC m y s e l f , SPC b u t SPC I SPC a m SPC n o t s u r e RET C-u C-b C-b SPC C-n t h a t SPC w o u l d SPC b e SPC l a w f u l . RET C-u C-u C-p C-n C-n C-n C-o b c c : SPC r e s p w C-c C-c C-d m e m a c s C-g ESC x r e p o r t SPC e m a c s SPC b u g RET Recent messages: Sending... Wrote /home/rms/outgoing/out-36 Sending...done Expunging deleted messages...done Expunging deleted messages...done Mark set [2 times] Auto-saving...done Sending... Wrote /home/rms/outgoing/out-37 Sending...done Quit From juri@jurta.org Tue Jan 6 11:01:56 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 19:01: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=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n06J1rHK009725 for ; Tue, 6 Jan 2009 11:01:55 -0800 Received: from mx10.gnu.org ([199.232.76.166]:51403) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKHAQ-0000R6-On for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 14:00:42 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKHBX-0006CX-Ke for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 14:01:52 -0500 Received: from relay03.kiev.sovam.com ([62.64.120.201]:54217) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKHBX-0006CD-1b; Tue, 06 Jan 2009 14:01:51 -0500 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKHBU-000NHX-Uu; Tue, 06 Jan 2009 21:01:49 +0200 From: Juri Linkov To: rms@gnu.org Cc: 1800@debbugs.gnu.org, emacs-pretest-bug@gnu.org Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Organization: JURTA References: Date: Tue, 06 Jan 2009 21:00:34 +0200 In-Reply-To: (Richard M. Stallman's message of "Tue, 06 Jan 2009 07:31:14 -0500") Message-ID: <87r63gs1il.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 8abf2c83e696415c40c55866f9369f42 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 5467 [Oct 22 2008] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: white ip list X-SpamTest-Rate: 10 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > 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] -- Juri Linkov http://www.jurta.org/emacs/ From monnier@IRO.UMontreal.CA Tue Jan 6 14:14:38 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 22:14:38 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n06MEVAj026407 for ; Tue, 6 Jan 2009 14:14:32 -0800 Received: from mail.gnu.org ([199.232.76.166]:34181 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKKAp-0006eX-Vj for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 17:13:20 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKKBy-0008U3-09 for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 17:14:30 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:59288) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LKKBw-0008TK-AG; Tue, 06 Jan 2009 17:14:28 -0500 Received: from alfajor.home (vpn-132-204-232-85.acd.umontreal.ca [132.204.232.85]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n06MEpJk011703; Tue, 6 Jan 2009 17:14:51 -0500 Received: by alfajor.home (Postfix, from userid 20848) id 13B8F1C83E; Tue, 6 Jan 2009 17:14:10 -0500 (EST) From: Stefan Monnier To: Juri Linkov Cc: 1800@debbugs.gnu.org, rms@gnu.org, emacs-pretest-bug@gnu.org Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Message-ID: References: <87r63gs1il.fsf@jurta.org> Date: Tue, 06 Jan 2009 17:14:10 -0500 In-Reply-To: <87r63gs1il.fsf@jurta.org> (Juri Linkov's message of "Tue, 06 Jan 2009 21:00:34 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3183=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-CrossAssassin-Score: 2 > 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. [...] > [No match, type TAB again for * as a wildcard] Here's another option: only treat * as a wildcard if it doesn't match anything existing. I.e. if you have buffers that start with "*", then "*g" will not treat the * as a wildcard. To force the use of a wildcard, we could let the user type "**g". Stefan From drew.adams@oracle.com Tue Jan 6 14:36:56 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 22:36:56 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n06Mamrc032493 for ; Tue, 6 Jan 2009 14:36:50 -0800 Received: from mail.gnu.org ([199.232.76.166]:35046 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKKWP-0007Xc-8r for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 17:35:37 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKKXW-0002Jt-NR for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 17:36:47 -0500 Received: from acsinet11.oracle.com ([141.146.126.233]:52857) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKKXR-0002JE-OT; Tue, 06 Jan 2009 17:36:42 -0500 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 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 Received: from dradamslap1 (/141.144.88.99) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Jan 2009 22:36:24 +0000 From: "Drew Adams" To: "'Juri Linkov'" , <1800@debbugs.gnu.org>, Cc: References: <87r63gs1il.fsf@jurta.org> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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, 1) > > 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.) From rms@gnu.org Tue Jan 6 15:01:03 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 23:01: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=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham 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.13.8/8.13.8/Debian-3) with ESMTP id n06N10i5006036 for ; Tue, 6 Jan 2009 15:01:01 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKKuv-0004ss-4M for bug-gnu-emacs@gnu.org; Tue, 06 Jan 2009 18:00:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKKuu-0004sW-Kb for bug-gnu-emacs@gnu.org; Tue, 06 Jan 2009 18:00:56 -0500 Received: from [199.232.76.173] (port=43607 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKKuu-0004sS-GA for bug-gnu-emacs@gnu.org; Tue, 06 Jan 2009 18:00:56 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:42409) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LKKut-0004Gy-Tk for bug-gnu-emacs@gnu.org; Tue, 06 Jan 2009 18:00:56 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LKKtk-0008FG-Jp; Tue, 06 Jan 2009 17:59:44 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard M Stallman To: Juri Linkov , 1800@debbugs.gnu.org CC: bug-submit-list@donarmstrong.com, emacs-pretest-bug@gnu.org, 1800@debbugs.gnu.org, bug-gnu-emacs@gnu.org In-reply-to: <87r63gs1il.fsf@jurta.org> (message from Juri Linkov on Tue, 06 Jan 2009 21:00:34 +0200) Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Reply-to: rms@gnu.org References: <87r63gs1il.fsf@jurta.org> Message-Id: Date: Tue, 06 Jan 2009 17:59:44 -0500 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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] That is a good idea. It would provide the same benefit of the existing feature, but without the inconvenience. From juri@jurta.org Tue Jan 6 15:18:02 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 23:18: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=-1.4 required=4.0 tests=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n06NHxQr010463 for ; Tue, 6 Jan 2009 15:18:00 -0800 Received: from mx10.gnu.org ([199.232.76.166]:36344) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKLAF-0000Wr-7Z for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 18:16:47 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKLBL-0005hi-4H for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 18:17:57 -0500 Received: from relay02.kiev.sovam.com ([62.64.120.197]:59702) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKLBK-0005hS-K6; Tue, 06 Jan 2009 18:17:54 -0500 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKLBH-000Nyk-S5; Wed, 07 Jan 2009 01:17:52 +0200 From: Juri Linkov To: Stefan Monnier Cc: 1800@debbugs.gnu.org, rms@gnu.org, emacs-pretest-bug@gnu.org Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Organization: JURTA References: <87r63gs1il.fsf@jurta.org> Date: Wed, 07 Jan 2009 00:54:17 +0200 In-Reply-To: (Stefan Monnier's message of "Tue, 06 Jan 2009 17:14:10 -0500") Message-ID: <87fxjwnizs.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: c2436a487120708c9e0f2b31fdd4cc45 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 5467 [Oct 22 2008] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: white ip list X-SpamTest-Rate: 10 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) X-CrossAssassin-Score: 2 >> 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. > [...] >> [No match, type TAB again for * as a wildcard] > > Here's another option: only treat * as a wildcard if it doesn't match > anything existing. I.e. if you have buffers that start with "*", then > "*g" will not treat the * as a wildcard. To force the use of > a wildcard, we could let the user type "**g". It seems unlikely not to have a buffer that starts with "*". There are always such buffers as *scratch*, *Messages*, *Completions*. OTOH, "**g" will help, but it has the same drawback as using "\*g" for a literal character *, i.e. it is not as obvious as using a single *. -- Juri Linkov http://www.jurta.org/emacs/ From juri@jurta.org Tue Jan 6 15:18:04 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 6 Jan 2009 23:18: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=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n06NI1Q6010471 for ; Tue, 6 Jan 2009 15:18:03 -0800 Received: from mx10.gnu.org ([199.232.76.166]:36346) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKLAI-0000XA-Na for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 18:16:50 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKLBN-0005hs-4p for emacs-pretest-bug@gnu.org; Tue, 06 Jan 2009 18:18:01 -0500 Received: from relay01.kiev.sovam.com ([62.64.120.200]:3942) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKLBM-0005he-6m; Tue, 06 Jan 2009 18:17:57 -0500 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKLBM-00027y-Ku; Wed, 07 Jan 2009 01:17:56 +0200 From: Juri Linkov To: "Drew Adams" Cc: <1800@debbugs.gnu.org>, , Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Organization: JURTA References: <87r63gs1il.fsf@jurta.org> <007301c9704f$3a550ef0$0200a8c0@us.oracle.com> Date: Wed, 07 Jan 2009 01:12:43 +0200 In-Reply-To: <007301c9704f$3a550ef0$0200a8c0@us.oracle.com> (Drew Adams's message of "Tue, 6 Jan 2009 14:36:32 -0800") Message-ID: <87sknwkov4.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 3140350ce96b4815fe22a3a842dc7b15 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6671 [Jan 07 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: white ip list X-SpamTest-Rate: 10 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.8-5.1 (or MacOS X 10.2-10.3) X-CrossAssassin-Score: 2 > 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.) There is no harm in a feature if it has no annoyance/surprise. You said in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1757 With the traditional behavior, if there are no buffers with prefix `*', you are told so immediately: [No match]. With the new, partial-completion behavior, you are given possible completions that do not complete `*' in the normal way (as a literal prefix). So implementing a message "[No match, type TAB again for * as a wildcard]" will keep the traditional behavior just as you want. -- Juri Linkov http://www.jurta.org/emacs/ From drew.adams@oracle.com Tue Jan 6 21:35:27 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 05:35:27 +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=FOURLA,HAS_BUG_NUMBER, PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n075ZOq3007027 for ; Tue, 6 Jan 2009 21:35:25 -0800 Received: from mx10.gnu.org ([199.232.76.166]:48916) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKR3U-0001dq-74 for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 00:34:12 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKR4c-0006l1-JV for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 00:35:23 -0500 Received: from rcsinet11.oracle.com ([148.87.113.123]:32529 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 1LKR4a-0006kY-3N; Wed, 07 Jan 2009 00:35:20 -0500 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 n075aiB9017350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jan 2009 05:36:45 GMT 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 n075Z5Vn008444; Wed, 7 Jan 2009 05:35:06 GMT Received: from dradamslap1 (/24.5.134.5) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jan 2009 05:35:05 +0000 From: "Drew Adams" To: "'Juri Linkov'" , <1800@debbugs.gnu.org>, "'Stefan Monnier'" Cc: , References: <87r63gs1il.fsf@jurta.org> <87fxjwnizs.fsf@jurta.org> Subject: RE: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Date: Tue, 6 Jan 2009 21:35:14 -0800 Message-ID: <001b01c97089$b7a23060$0200a8c0@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: <87fxjwnizs.fsf@jurta.org> Thread-Index: AclwWKJZwzE/pk+2QAWsCIQs2DrkswAMAvlQ 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.0A09020B.49643F0B.00A6:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) > >> 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. > >> [No match, type TAB again for * as a wildcard] > > > > Here's another option: only treat * as a wildcard if it > > doesn't match anything existing. I.e. if you have buffers > > that start with "*", then "*g" will not treat the * as a > > wildcard. To force the use of a wildcard, we could let > > the user type "**g". > > It seems unlikely not to have a buffer that starts with "*". > There are always such buffers as *scratch*, *Messages*, *Completions*. > OTOH, "**g" will help, but it has the same drawback as using "\*g" > for a literal character *, i.e. it is not as obvious as using > a single *. I don't agree that this ad hoc escaping is a good solution, but I'm not going to argue about it here and now. This is the kind of thing that can be discussed rationally and by a larger group - after the release and with this in practice as an option, not as the new default. IOW, keep the default behavior as it has always been, add the new feature, and, after the release, discuss the possible problems it introduces and possibile solutions, with the added experience and input of a user base. From drew.adams@oracle.com Tue Jan 6 21:35:27 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 05:35:27 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n075ZORi007029 for ; Tue, 6 Jan 2009 21:35:25 -0800 Received: from mail.gnu.org ([199.232.76.166]:48917 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKR3U-0001dt-TG for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 00:34:13 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKR4d-0006lL-8d for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 00:35:23 -0500 Received: from acsinet11.oracle.com ([141.146.126.233]:22719) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKR4a-0006kW-3R; Wed, 07 Jan 2009 00:35:20 -0500 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 n075acJF022822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jan 2009 05:36:39 GMT 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 n075Z3we008396; Wed, 7 Jan 2009 05:35:05 GMT Received: from dradamslap1 (/24.5.134.5) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jan 2009 05:35:03 +0000 From: "Drew Adams" To: "'Juri Linkov'" Cc: <1800@debbugs.gnu.org>, , References: <87r63gs1il.fsf@jurta.org><007301c9704f$3a550ef0$0200a8c0@us.oracle.com> <87sknwkov4.fsf@jurta.org> Subject: RE: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Date: Tue, 6 Jan 2009 21:35:11 -0800 Message-ID: <001a01c97089$b6902420$0200a8c0@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: <87sknwkov4.fsf@jurta.org> Thread-Index: AclwVQjckdzXC4yoQxa48mY2YC+1VAAMkFRg 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.0A090203.49643F09.0129:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) > > 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.) > > There is no harm in a feature if it has no annoyance/surprise. > You said in > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1757 > > With the traditional behavior, if there are no buffers > with prefix `*', you are told so immediately: [No match]. > With the new, partial-completion behavior, you are given possible > completions that do not complete `*' in the normal way > (as a literal prefix). > > 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://debbugs.gnu.org/cgi/bugreport.cgi?bug=1512 Beyond the multiple possibilities of surprise or confusing behavior, what's the hurry? Why bend over backwards to force this upon users as the new default behavior? Even if we take as given that the new behavior is interesting and can be useful, why the need to suddenly switch to this behavior? What's wrong with offering this as an option? There already is a user option that controls this. All that's needed is to change the default value of that option to the singleton list '(basic), to keep the traditional behavior as the default. We can then also document well the possibility of the new behavior that combines basic with partial completion etc. - nothing wrong with advertizing this. What's wrong is to make it the default with no track record, no discussion, no poll. From juri@jurta.org Wed Jan 7 04:50:56 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 12:50:56 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n07CorJG019855 for ; Wed, 7 Jan 2009 04:50:54 -0800 Received: from mx10.gnu.org ([199.232.76.166]:37519) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKXqv-00079S-F9 for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 07:49:41 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKXs0-00089J-DD for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 07:50:52 -0500 Received: from relay01.kiev.sovam.com ([62.64.120.200]:4487) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKXrz-00088x-Sk; Wed, 07 Jan 2009 07:50:48 -0500 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKXrz-0008MR-4I; Wed, 07 Jan 2009 14:50:47 +0200 From: Juri Linkov To: "Drew Adams" Cc: 1800@debbugs.gnu.org, rms@gnu.org, emacs-pretest-bug@gnu.org Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Organization: JURTA References: <87r63gs1il.fsf@jurta.org> <007301c9704f$3a550ef0$0200a8c0@us.oracle.com> <87sknwkov4.fsf@jurta.org> <001a01c97089$b6902420$0200a8c0@us.oracle.com> Date: Wed, 07 Jan 2009 14:07:25 +0200 In-Reply-To: <001a01c97089$b6902420$0200a8c0@us.oracle.com> (Drew Adams's message of "Tue, 6 Jan 2009 21:35:11 -0800") Message-ID: <873afvz5du.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: b36477657b07eb27dc67b07df918f397 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6672 [Jan 07 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: white ip list X-SpamTest-Rate: 10 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.8-5.1 (or MacOS X 10.2-10.3) X-CrossAssassin-Score: 2 >> 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://debbugs.gnu.org/cgi/bugreport.cgi?bug=1512 Asking for another TAB before doing partial completion will solve both your problems. -- Juri Linkov http://www.jurta.org/emacs/ From drew.adams@oracle.com Wed Jan 7 07:58:15 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 15:58:15 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 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 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 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 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 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 Received: from dradamslap1 (/24.23.165.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jan 2009 15:56:16 +0000 From: "Drew Adams" To: "'Juri Linkov'" Cc: <1800@debbugs.gnu.org>, , 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> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > >> 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://debbugs.gnu.org/cgi/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. From drew.adams@oracle.com Wed Jan 7 08:49:00 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 16:49:00 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 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 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 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 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 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 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jan 2009 16:48:27 +0000 From: "Drew Adams" To: <1800@debbugs.gnu.org>, "'Juri Linkov'" Cc: , 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> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 > > >> 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://debbugs.gnu.org/cgi/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'. From juri@jurta.org Wed Jan 7 09:56:40 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 17:56:41 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n07HubYh032576 for ; Wed, 7 Jan 2009 09:56:39 -0800 Received: from mx10.gnu.org ([199.232.76.166]:48175) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKccm-00070C-QD for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 12:55:25 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKcdu-0006by-4j for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 12:56:34 -0500 Received: from relay01.kiev.sovam.com ([62.64.120.200]:1307) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKcdn-0006Zk-B3; Wed, 07 Jan 2009 12:56:28 -0500 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay01.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKcdk-000ClE-T2; Wed, 07 Jan 2009 19:56:25 +0200 From: Juri Linkov To: "Drew Adams" Cc: 1800@debbugs.gnu.org, emacs-pretest-bug@gnu.org, rms@gnu.org Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Organization: JURTA 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> <000c01c970e7$c3bb2d30$c2b22382@us.oracle.com> Date: Wed, 07 Jan 2009 19:43:28 +0200 In-Reply-To: <000c01c970e7$c3bb2d30$c2b22382@us.oracle.com> (Drew Adams's message of "Wed, 7 Jan 2009 08:48:26 -0800") Message-ID: <87mye3t5hz.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: dd5701c86360acb8383b46d8fd27d5ab X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6672 [Jan 07 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: white ip list X-SpamTest-Rate: 10 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.8-5.1 (or MacOS X 10.2-10.3) > 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)'. I think we should replace `partial-completion' in the default value of `completion-styles' with a new completion method, e.g. `confirm-partial-completion'. -- Juri Linkov http://www.jurta.org/emacs/ From drew.adams@oracle.com Wed Jan 7 10:06:01 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 18:06: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=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n07I5wFl003344 for ; Wed, 7 Jan 2009 10:05:59 -0800 Received: from mail.gnu.org ([199.232.76.166]:48818 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKclp-0007GO-6w for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 13:04:45 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKcmu-0007eT-7e for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 13:05:55 -0500 Received: from rcsinet13.oracle.com ([148.87.113.125]:28800 helo=rgminet13.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 1LKcmi-0007a4-KW; Wed, 07 Jan 2009 13:05:41 -0500 Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n07I64so030130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Jan 2009 18:06:06 GMT Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n07I5KgM026766; Wed, 7 Jan 2009 18:05:21 GMT Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Jan 2009 18:05:19 +0000 From: "Drew Adams" To: "'Juri Linkov'" Cc: <1800@debbugs.gnu.org>, , 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><000c01c970e7$c3bb2d30$c2b22382@us.oracle.com> <87mye3t5hz.fsf@jurta.org> Subject: RE: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Date: Wed, 7 Jan 2009 10:05:17 -0800 Message-ID: <004001c970f2$810f7440$c2b22382@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: <87mye3t5hz.fsf@jurta.org> Thread-Index: Aclw8VanGVmF1alOTgOlgtQxlTXGyQAAOQ6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4964EEE1.02D4:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-CrossAssassin-Score: 2 > > 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)'. > > I think we should replace `partial-completion' in the default > value of `completion-styles' with a new completion method, e.g. > `confirm-partial-completion'. Providing `confirm-partial-completion' as another alternative completion style is fine, but why make it the default behavior? What's wrong with the traditional behavior as default? From juri@jurta.org Wed Jan 7 11:34:03 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 19:34: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=-1.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 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 n07JY0D0024843 for ; Wed, 7 Jan 2009 11:34:01 -0800 Received: from mail.gnu.org ([199.232.76.166]:60388 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LKe91-0002BD-SY for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 14:32:47 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LKeAB-0008Gm-A8 for emacs-pretest-bug@gnu.org; Wed, 07 Jan 2009 14:33:59 -0500 Received: from relay03.kiev.sovam.com ([62.64.120.201]:64617) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LKeA8-0008G2-Lt; Wed, 07 Jan 2009 14:33:57 -0500 Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay03.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1LKeA6-000N9Z-5C; Wed, 07 Jan 2009 21:33:54 +0200 From: Juri Linkov To: "Drew Adams" Cc: 1800@debbugs.gnu.org, emacs-pretest-bug@gnu.org, rms@gnu.org Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Organization: JURTA 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> <000c01c970e7$c3bb2d30$c2b22382@us.oracle.com> <87mye3t5hz.fsf@jurta.org> <004001c970f2$810f7440$c2b22382@us.oracle.com> Date: Wed, 07 Jan 2009 21:30:14 +0200 In-Reply-To: <004001c970f2$810f7440$c2b22382@us.oracle.com> (Drew Adams's message of "Wed, 7 Jan 2009 10:05:17 -0800") Message-ID: <87fxjuncc9.fsf@jurta.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanner-Signature: 5389b9e13478507b5d7b23e4ed053241 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 6672 [Jan 07 2009] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: white ip list X-SpamTest-Rate: 10 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-CrossAssassin-Score: 2 >> > 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)'. >> >> I think we should replace `partial-completion' in the default >> value of `completion-styles' with a new completion method, e.g. >> `confirm-partial-completion'. > > Providing `confirm-partial-completion' as another alternative completion style > is fine, but why make it the default behavior? What's wrong with the traditional > behavior as default? More users will be able to use all the benefits of partial completion without its annoyances. -- Juri Linkov http://www.jurta.org/emacs/ From rms@gnu.org Wed Jan 7 12:10:27 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Jan 2009 20:10:27 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham 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.13.8/8.13.8/Debian-3) with ESMTP id n07KAOcN002925 for ; Wed, 7 Jan 2009 12:10:25 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKejQ-0007yS-7U for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 15:10:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKejP-0007xx-1o for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 15:10:23 -0500 Received: from [199.232.76.173] (port=52647 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKejO-0007xs-Ug for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 15:10:22 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:36712) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LKejO-0004zz-K1 for bug-gnu-emacs@gnu.org; Wed, 07 Jan 2009 15:10:22 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1LKeiD-0003vj-Vw; Wed, 07 Jan 2009 15:09:10 -0500 Content-Type: text/plain; charset=ISO-8859-15 From: Richard M Stallman To: Stefan Monnier , 1800@debbugs.gnu.org CC: juri@jurta.org, bug-submit-list@donarmstrong.com, emacs-pretest-bug@gnu.org, 1800@debbugs.gnu.org, bug-gnu-emacs@gnu.org In-reply-to: (message from Stefan Monnier on Tue, 06 Jan 2009 17:14:10 -0500) Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Reply-to: rms@gnu.org References: Message-Id: Date: Wed, 07 Jan 2009 15:09:09 -0500 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Here's another option: only treat * as a wildcard if it doesn't match anything existing. I.e. if you have buffers that start with "*", then "*g" will not treat the * as a wildcard. To force the use of a wildcard, we could let the user type "**g". That too would more or less solve the problem. From xma@gnu.org Mon Mar 9 14:26:34 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 9 Mar 2009 21:26:34 +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.5 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 n29LQV2w028794 for ; Mon, 9 Mar 2009 14:26:32 -0700 Received: from mx10.gnu.org ([199.232.76.166]:51833) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LgmzX-0005bT-5r for emacs-pretest-bug@gnu.org; Mon, 09 Mar 2009 17:26:31 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LgmzU-0004yG-Hx for emacs-pretest-bug@gnu.org; Mon, 09 Mar 2009 17:26:29 -0400 Received: from ded1.conovae.com ([88.191.52.166]:39897 helo=mf1.conovae.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LgmzT-0004y1-Pv; Mon, 09 Mar 2009 17:26:28 -0400 Received: by mf1.conovae.net (Postfix, from userid 10) id A072B26139E; Mon, 9 Mar 2009 22:24:14 +0100 (CET) Received: from zogzog.maillard.mobi (IDENT:1000@localhost [127.0.0.1]) by zogzog.maillard.mobi (8.14.3/8.13.8) with ESMTP id n29LPB7E006352; Mon, 9 Mar 2009 22:25:11 +0100 Received: (from xma@localhost) by zogzog.maillard.mobi (8.14.3/8.13.8/Submit) id n29LPBe0006351; Mon, 9 Mar 2009 22:25:11 +0100 Date: Mon, 9 Mar 2009 22:25:11 +0100 Message-Id: <200903092125.n29LPBe0006351@zogzog.maillard.mobi> From: Xavier Maillard To: Juri Linkov , 1800@debbugs.gnu.org CC: rms@gnu.org, emacs-pretest-bug@gnu.org, 1800@debbugs.gnu.org In-reply-to: message from Juri Linkov on Tue, 06 Jan 2009 21:00:34 +0200 Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Organization: GNU's Not UNIX! User-Agent: Rmail GNU emacs 23.0 on Slackware 12.2.0 Jabber-ID: xma01@jabber.fr Reply-to: Xavier Maillard References: X-UUCPssh-Information: Please contact the ISP for more information X-UUCPssh: Found to be clean X-UUCPssh-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 6, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-UUCPssh-From: xma@gnu.org X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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] By chance, did you install something in order to have this new and much appropriate completion ? I did not read anything about this bug report for weeks now and we are still annoyed by the current behaviour (at least I am). Xavier -- http://www.gnu.org http://www.april.org http://www.lolica.org From monnier@iro.umontreal.ca Mon Mar 9 18:05:57 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 10 Mar 2009 01:05: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=1.0 required=4.0 tests=HAS_BUG_NUMBER,PHONENUMBER, XIRONPORT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 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 n2A15spJ023113 for ; Mon, 9 Mar 2009 18:05:55 -0700 Received: from mail.gnu.org ([199.232.76.166]:45926 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1LgqPp-0008Q3-Ve for emacs-pretest-bug@gnu.org; Mon, 09 Mar 2009 21:05:54 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1LgqPl-00066R-6g for emacs-pretest-bug@gnu.org; Mon, 09 Mar 2009 21:05:52 -0400 Received: from ironport2-out.pppoe.ca ([206.248.154.182]:5360 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LgqPk-00065x-6Q; Mon, 09 Mar 2009 21:05:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAFABNatUnO+KDF/2dsb2JhbACBTs8rhAUGhCE X-IronPort-AV: E=Sophos;i="4.38,332,1233550800"; d="scan'208";a="34937801" Received: from 206-248-160-197.dsl.teksavvy.com (HELO ceviche.home) ([206.248.160.197]) by ironport2-out.teksavvy.com with ESMTP; 09 Mar 2009 21:05:47 -0400 Received: by ceviche.home (Postfix, from userid 20848) id BFFE3B403E; Mon, 9 Mar 2009 21:05:46 -0400 (EDT) From: Stefan Monnier To: Xavier Maillard Cc: 1800@debbugs.gnu.org, Juri Linkov , emacs-pretest-bug@gnu.org, rms@gnu.org, 1800@debbugs.gnu.org Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Message-ID: References: <200903092125.n29LPBe0006351@zogzog.maillard.mobi> Date: Mon, 09 Mar 2009 21:05:46 -0400 In-Reply-To: <200903092125.n29LPBe0006351@zogzog.maillard.mobi> (Xavier Maillard's message of "Mon, 9 Mar 2009 22:25:11 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-CrossAssassin-Score: 2 > and much appropriate completion ? I did not read anything about > this bug report for weeks now and we are still annoyed by the > current behaviour (at least I am). You don't need to suffer: just set completion-styles in your .emacs. Stefan From cyd@stupidchicken.com Sat Aug 15 15:26:09 2009 Received: (at 1800-done) by emacsbugs.donarmstrong.com; 15 Aug 2009 22:26:09 +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.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, PHONENUMBER autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n7FMQ7oH028696 for <1800-done@emacsbugs.donarmstrong.com>; Sat, 15 Aug 2009 15:26:09 -0700 Received: by cyd.mit.edu (Postfix, from userid 1000) id A0AF057E21C; Sat, 15 Aug 2009 18:27:06 -0400 (EDT) From: Chong Yidong To: 1800-done@debbugs.gnu.org Subject: Re: bug#1800: 23.0.60; Changed meaning of * in buffer name completion Date: Sat, 15 Aug 2009 18:27:06 -0400 Message-ID: <87skfslnlx.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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. This has been fixed for a while, so I'm closing this bug. From unknown Tue Jun 24 22:35:36 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, 13 Sep 2009 14:24:11 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator