From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#994: Processed: severity 994 wishlist Date: Mon, 29 Sep 2008 20:09:00 -0700 Message-ID: <003901c922a9$e2f16ca0$0200a8c0@us.oracle.com> References: <87k5culgm2.fsf@cyd.mit.edu><001101c9228c$728367b0$0200a8c0@us.oracle.com> <87ljxa1jil.fsf@cyd.mit.edu> Reply-To: Drew Adams , 994@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 1222745412 31484 80.91.229.12 (30 Sep 2008 03:30:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2008 03:30:12 +0000 (UTC) Cc: schwab@suse.de, 994@emacsbugs.donarmstrong.com, 'Emacs bug Tracking System' To: "'Chong Yidong'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 30 05:31:09 2008 connect(): Connection refused 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 1KkVx6-0006jm-Sm for geb-bug-gnu-emacs@m.gmane.org; Tue, 30 Sep 2008 05:31:09 +0200 Original-Received: from localhost ([127.0.0.1]:35536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KkVw3-0006vP-1i for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Sep 2008 23:30:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KkVvz-0006v7-Pc for bug-gnu-emacs@gnu.org; Mon, 29 Sep 2008 23:29:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KkVvy-0006uv-A7 for bug-gnu-emacs@gnu.org; Mon, 29 Sep 2008 23:29:58 -0400 Original-Received: from [199.232.76.173] (port=48043 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KkVvy-0006us-3q for bug-gnu-emacs@gnu.org; Mon, 29 Sep 2008 23:29:58 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:42235) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KkVvx-0006bJ-LH for bug-gnu-emacs@gnu.org; Mon, 29 Sep 2008 23:29:57 -0400 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 m8U3Tt7D008830; Mon, 29 Sep 2008 20:29:55 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m8U3F2GP005304; Mon, 29 Sep 2008 20:15:02 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 30 Sep 2008 03:15:02 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 994 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 994-submit@emacsbugs.donarmstrong.com id=B994.12227441554062 (code B ref 994); Tue, 30 Sep 2008 03:15:02 +0000 Original-Received: (at 994) by emacsbugs.donarmstrong.com; 30 Sep 2008 03:09:15 +0000 Original-Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m8U39BDj004056 for <994@emacsbugs.donarmstrong.com>; Mon, 29 Sep 2008 20:09:12 -0700 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id m8U38nqb021436; Mon, 29 Sep 2008 22:08:49 -0500 Original-Received: from acsmt701.oracle.com (acsmt701.oracle.com [141.146.40.71]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m8U38lvU002456; Mon, 29 Sep 2008 21:08:48 -0600 Original-Received: from dradamslap1 (/141.144.81.233) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Sep 2008 20:08:47 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ljxa1jil.fsf@cyd.mit.edu> Thread-Index: AckioLtYKMBKXQXHTlyEZr2+Aj3gVwAA3TVg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Resent-Date: Mon, 29 Sep 2008 23:29:58 -0400 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:20889 Archived-At: > > Why is this fodder for the wishlist? This bug is a regression! > > > > Stefan asked for a recipe to reproduce it, so no doubt this > > behavior is not intentional (not a design change). It is bad, > > bugged behavior, and it is new. > > > > Why on earth would such a bug report be classified as "wish > > list"? Perhaps you are simply wishing bugs away? ;-) > > Please don't make a separate CC to bug-gnu-emacs; that > creates a new bug entry. Just reply to NNN@emacsbugs.donarmstrong.com. I used Reply All. mea culpa. FYI, 994@emacsbugs.donarmstrong.com was not even in the list of recipients - I had to add it manually. So neither Reply nor Reply All does the job. > The bug in question is not a regression, unless you have a > rather broad definition of "regression". Of course it is a regression. What is your definition? * No such crazy completion occurred in Emacs 22 or 21 or 20 or 19 or 18. * And it is apparently not intentional behavior. * And it is bad behavior - no rationale has been given for it, and the developer was apparently surprised by it, asking for a recipe to reproduce it. Why would you call behavior that is new, unintentional, and bad anything BUT a regression? What would you call it? > It is neither obviously buggy nor new, Of course it is new. Repeat the same recipe in Emacs 22, 21, or 20 - you will not see anything like what I reported. How can you say that `read-file-name' completing (with an existing file `icicles-mcmd.el') the input `icicles-mcfoobar' to `icicles-mcicles-foobar' is correct? There is no such file. Emacs should signal that there are no completions. How can you say that completing the same input to `icicles-mcfoobaricles' is also correct? Again, there is no such file. Emacs should signal that there are no completions. Even if you adopt the point of view that only what is before point should be completed, ignoring what comes after point, the result must be a valid completion (existing file name). With that point of view, it might be correct to *replace* the text to the right of point and leave the completed file name `icicles-mcmd.el'. But there is no way that it makes sense to complete to `icicles-mcicles-foobar' or `icicles-mcfoobaricles'. Please think about it. This is totally silly. ------------8<---------------------- Newsflash - I just tried again, using this build: In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-09-18 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' And the bug is fixed in that build. I retested using the version I reported it in, just to be sure, and the bug does exist there, as reported: In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-09-03 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --no-opt --cflags -Ic:/g/include -fno-crossjumping' However, FWIW, the behavior now is not the same as in Emacs 22: In GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600) of 2008-03-26 on RELEASE Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' In Emacs 22.2 (I don't have 22.3, but I'm guessing it's the same): icicles-mcfoobar completes to icicles-mcmd.elfoobar, when point is on the m. When point is at the end (after the r), you get a [No match] message. In Emacs 23, you get a [No match] message in both cases. I'm OK with that, but see Andreas Schwab's reply - he might not be OK with it. In addition to these examples being fixed, the other example I gave, of first doing C-x C-f icicles-mc RET and then C-x C-v TAB seems also to be fixed - it now completes to icicles-mcmd.el. (This part of the original report was stated in terms of foo-bar.el, not icicles-mcmd.el.) So if nothing changes (;-)), I'm OK with closing this bug - it seems to be fixed. Thanks to whoever fixed it (probably Stefan). However, this does represent a change in design (intentional user-visible behavior change) wrt Emacs 22. I'm OK with this change, but it was not something that was discussed in emacs-devel@gnu.org. There have been a lot of changes to the completion behavior that were never discussed. That's not the right way to run things, IMHO.