Processed: severity 994 wishlist

Processed: severity 994 wishlist

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> severity 994 wishlist
bug#994: 23.0.60; minibuffer completion should act on all minibuffer input
Severity set to `wishlist' from `normal'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#1055: Processed: severity 994 wishlist

[Drew Adams]

> From: Emacs bug Tracking System Sent: Monday, September 29, 2008 3:50 PM
> Processing commands for control@emacsbugs.donarmstrong.com:
> 
> > severity 994 wishlist
> bug#994: 23.0.60; minibuffer completion should act on all 
> minibuffer input
> Severity set to `wishlist' from `normal'

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? ;-)

bug#994: Processed: severity 994 wishlist

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> 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.

The bug in question is not a regression, unless you have a rather broad
definition of "regression".  It is neither obviously buggy nor new, so
I'd prefer it if people work on the other outstanding issues first.

But if it bugs you that much... patch welcome.  I don't want to waste
time debating bug classification.

bug#994: Processed: severity 994 wishlist

[Drew Adams]

> > 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.

bug#994: Processed: severity 994 wishlist

[Stefan Monnier]

> 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.

Indeed it looks like a bug to me.
But IIUC the rest of your message says that the bug is now gone, right?


        Stefan

bug#994: Processed: severity 994 wishlist

[Drew Adams]

> > 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.
> 
> Indeed it looks like a bug to me.
> But IIUC the rest of your message says that the bug is now 
> gone, right?

Yes, I believe so, at least in the version (2008-09-18) I mentioned.

Thanks.

bug#994: Processed: severity 994 wishlist

[Stefan Monnier]

> Yes, I believe so, at least in the version (2008-09-18) I mentioned.

Wonderful.  If it appears again, please file a new bug,


        Stefan

bug#994: Processed: severity 994 wishlist

[Drew Adams]

> > Yes, I believe so, at least in the version (2008-09-18) I mentioned.
> 
> Wonderful.  If it appears again, please file a new bug,

OK.

bug#1055: marked as done (Processed: severity 994 wishlist)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]


Your message dated Mon, 29 Sep 2008 21:59:14 -0400
with message-id <87ljxa1jil.fsf@cyd.mit.edu>
and subject line Re: Processed: severity 994 wishlist
has caused the Emacs bug report #1055,
regarding Processed: severity 994 wishlist
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
1055: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1055
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3476 bytes --]

From: "Drew Adams" <drew.adams@oracle.com>
To: "'Emacs bug Tracking System'" <don@donarmstrong.com>, "'Chong Yidong'" <cyd@stupidchicken.com>, <994@emacsbugs.donarmstrong.com>
Cc: "'Emacs Bugs'" <bug-gnu-emacs@gnu.org>
Subject: RE: Processed: severity 994 wishlist
Date: Mon, 29 Sep 2008 16:38:16 -0700
Message-ID: <001101c9228c$728367b0$0200a8c0@us.oracle.com>

> From: Emacs bug Tracking System Sent: Monday, September 29, 2008 3:50 PM
> Processing commands for control@emacsbugs.donarmstrong.com:
> 
> > severity 994 wishlist
> bug#994: 23.0.60; minibuffer completion should act on all 
> minibuffer input
> Severity set to `wishlist' from `normal'

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? ;-)





[-- Attachment #3: Type: message/rfc822, Size: 2214 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: "'Emacs bug Tracking System'" <don@donarmstrong.com>, <994@emacsbugs.donarmstrong.com>, 1055-done@emacsbugs.donarmstrong.com
Subject: Re: Processed: severity 994 wishlist
Date: Mon, 29 Sep 2008 21:59:14 -0400
Message-ID: <87ljxa1jil.fsf@cyd.mit.edu>

"Drew Adams" <drew.adams@oracle.com> writes:

> 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.

The bug in question is not a regression, unless you have a rather broad
definition of "regression".  It is neither obviously buggy nor new, so
I'd prefer it if people work on the other outstanding issues first.

But if it bugs you that much... patch welcome.  I don't want to waste
time debating bug classification.